DevOps monitoring and its interrelationships
In the 20th century we were programmers. In the 21st century, developers. With the massification of telecommunications worldwide, operators began to help us in our work. That’s where the term DevOps (“developers” and “operations”) arose, which implies the concept of collaboration of both teams. But since change is the only constant, other practical considerations have forced us to see the entire forest instead of just a few trees. Put on your technological jackets and join us today!
The collaboration between these two is great; it only takes a little work for the developers to specify the parameters, and for the operations team, from this, to work on the physical and/or virtual infrastructure. At the same time, the operations team will take due note of the improvements that can be made, taking into account the hardware resources and/or virtual servers to improve the applications and/or systems, and will notify the team of developers regarding its recommendations. In this blog we have already talked about a DevOps architecture when we could foresee that DevOps monitoring would be added as a specialized work field, since this way operations will have a solid base to evaluate and compare improvements versus performance.
DevOps Monitoring became essential when the processes began to automatically mesh the Continuous Integration of Software and its fundamental pillars, the Continuous Integration, the Continuous Delivery and the Continuous Deployment, which has become abbreviated as CI/CD.
Scheme on monitoring DevOps
- System and/or application requirements.
- Writing: of the code and its continuous commits.
- Tests: first automated execution of the options added and intended for users, to then be checked by humans from time to time.
- Packaging: structure and organize the necessary files.
- Liberation: take an image to the repository in Docker, an ISO image, etc.
- Deployment: implement the system and/or application.
- Operation: area belonging to the users, its pure and simple use.
- Monitoring: collects the events and their records from the previous phase.
Just like DevOps have automated their work, the bad guys (or “crackers”) have not been left behind. We’ve already talked about botnets and although as users we should be aware of it, no DevOps would ever count on our word alone. That is why safety was added, thus coining the term DevSecOps.
- Requirements: essentially concepts, where we ask ourselves the questions: What are we building? What can go wrong? What would we do in those cases? Did we forget to include something else? At this point, too, the security team will analyse the scripts that will build the immutable infrastructure in search of security holes.
- Writing: raising the awareness of developers, teaching them the latest attack techniques so that, based on this, they can modify the writing. If necessary, the security team will teach the developers tools such as git-secrets, git-hound or even, if necessary, publish encrypted passwords and developer data, git-crypt. The group of operators shall be responsible for installation, configuration and commissioning.
- Tests: the security team will request to include execution routines that they consider appropriate to each module.
- Packaging: The security team will analyse new features and resources added to the project in search of vulnerabilities added by third parties. Some tools: bundler-audit, Dagda, Docker Bench, etc.
- Release: add checks based on the previous phase, search and verify that any element we have blocked and/or corrected reaches this point.
- Deployment: the security team will have test environments that emulate what the user receives and will apply the techniques it deems necessary, if you like, this is the playground of the security team.
- Operation: an independent external group but belonging to the security area will attempt to attack the infrastructure and will not warn. There are other complex tools encompassed as Chaos engineering.
- Monitoring: software like Pandora FMS; developers, security and operators ‘believe’ that they have centralized records, Pandora FMS only sees data in abundance that turns into information and then centralize in a web console.
DevOps monitoring does not know when or how it will be asked for information or help, but it is absolutely certain that its services will at some point be required. Moreover, it will inform by means of alerts to each one of the teams, both normal alerts and alerts specially requested by the security team.
- Requirements: the monitoring team will take general notes on the software they plan to use (programming environment, compilers, security tools, distribution tools, etc.) and on the target platforms (Unix/Linux, Windows, Mac, among others). It will also collect infrastructure vulnerability reports, penetration tests and/or automated assessments and their logs.
- Writing: collection of data from both approved and reformulated and rejected commits. It will collect records of git-secrets, git-hound, git-crypt, Jenkins and other operations. Monitoring provides timely warning of the exponential growth of databases as a result of constant attacks, and to coordinate with the operations team an environment of high availability and backup of monitoring data.
- Testing: explicitly focused on the additional routines included by the security team unless they explicitly prohibit it, which is very unlikely to happen (number of problems opened and/or resolved, number of failed unit tests, automated UI test reports).
- Packaging: monitoring of private network traffic, as at this point tests of connectivity and performance will be collected and placed in the repository(s).
- Liberation: this may be the stage where monitoring plays, if you like, a non-preponderant role; to mention but a few, it would be supervision of the external network traffic of the repositories.
- Deployment: as in the previous process, we can orient this towards the network traffic.
- Operation: for all the information collected towards the attacks made by the “red artillery”.
- Monitoring: in Pandora FMS we work to simplify monitoring or development of the assisted monitoring for the operations team, with new technologies like Pandora FMS Discovery.
Still want to know more about computer systems monitoring? Luckily, you’re in the right place to learn more. In this blog there are dozens of articles that can introduce you to this exciting world. Here you have a link to our homepage.
Or you can also contact our Pandora FMS team if you have more than 100 devices to monitor. Click here.
If you have a reduced number of devices to monitor you can download the Pandora FMS OpenSource version, here.
El equipo de redacción de Pandora FMS está formado por un conjunto de escritores y profesionales de las TI con una cosa en común: su pasión por la monitorización de sistemas informáticos.
Pandora FMS’s editorial team is made up of a group of writers and IT professionals with one thing in common: their passion for computer system monitoring.