Developers have been writing more code to help monitor the apps they create. But when they’re done with their work and ready to hand it off, operations teams often discover that they can’t use whatever monitoring the developers created because of incompatible tools, says Lars Rosen, Micro Focus Fellow, chief architect, member of the chief technology office cross-portfolio program.
In his article, How to do monitoring as code the DevOps way, he says you need to take a DevOps approach, where the dev and ops teams start collaborating before any monitoring code gets written. Specifically, your ops team should be defining different types of monitoring, including tools and processes, for different classifications of apps and their sub-components
A little background
The concept of monitoring as code first started trending in 2009. My original thought on the way to do monitoring as code was simply to have an application send monitoring data to a monitoring platform.
But IT Ops teams have told us that dev teams put monitoring in their applications and feed that data into their own tools. Ultimately, they decided they didn’t want to do 24x7 monitoring and asked IT Ops teams to do it. IT Ops teams didn’t want to manage more tools than they already had (According to Enterprise Management Associates, they have an average of 23 tools). The result was creating a way for Dev teams to pass their monitoring data to existing IT Ops tools. With this change, IT Ops could support 24 x 7 monitoring, and dev teams have access to the IT Ops system consoles to view their data at their leisure.
As Rossen says, you need programmatic ways to set up standard monitoring in addition to what the dev teams implement inside their applications. He likens it to the way infrastructure as code is implemented, and his thinking includes making monitoring a standard catalog item.
How Operations Bridge implements the expanded monitoring as code definition
There are two ways to start the process, one if the Dev team writes monitoring into the application and another for defining monitors. One follows the other, so let’s start with the Dev team.
The Dev writes into the code a way to output the metrics or events they want to monitor. Those metrics and events are sent to OpsBridge. Carol Park wrote a blog post covering this in detail - Easily collect custom metrics using Perl and visualize in OBM. This covers what I initially thought was monitoring-as-code.
You already know that OpsBridge can take monitoring data from an application. Let’s investigate other methods of doing monitoring as code. OpsBridge can automatically discover most of the IT environment. Typically, critical systems have an Operations Agent (OA) installed, and the agents discover what is running on the system, including applications running on those systems. Think of this method as bottoms-up. Monitoring policies are defined depending on what’s running on the system (ex: database), and those policies are applied. In addition to monitoring instructions, policies can include thresholds and define console views.
How other hybrid IT tools help the expanded monitoring as code definition
Hybrid Cloud Management (HCM) is our service fulfillment solution. Using HCM’s catalog, users can easily request and consume services. IT can create catalog options and use those to automatically tie catalog items (which represents e.g. an application) to OpsBridge’s monitoring, via Operations Orchestration (OO) – an engine that can automate end-to-end IT processes.
For discovery, OO will trigger our Universal Discovery tool to add the new configurations item (CI) into the uCMDB OpsBridge uses as another way to understand its environment. OpsBridge then knows about the new item and starts monitoring. The Universal Directory tool also has a component called Automatic Service Modeling which starts discovery at the user interface. This is the top-down method of discovery. If custom monitoring is needed, create a catalog item that tells OpsBridge what it needs to monitor by telling OpsBridge to use a different, or additional policy.
While these examples use our tools, we integrate with many other tools and technologies as well. For example, OpsBridge supports over 200 tools and technology integrations. This allows you to use what you have and implement advances without major disruption.
As with many efforts in IT, monitoring as code requires both technology and a change of process. Our hybrid IT tools – OpsBridge, HCM, and UD – can provide the technology you need, so you can focus on the process.
Join us for the next Micro Focus Virtual Universe, 19-21 May 2020
To get more information on AIOps and how customers are using Operations Bridge, we are happy to announce the following events:
On-demand – AIOps Summit
On-demand - Vivit Virtual Customer Days – ITOM
On-demand - What’s New in Operations Bridge Cloud Monitoring
See all the Micro Focus events Worldwide
Read all our news at the Operations Bridge blog.