Monitoring Automation, or Orchestrating Your Monitoring over Your CMDB
In every Enterprise, that extra step you need to master for monitoring is always a bit problematic. Normally, the people doing monitoring or who are responsible for the monitoring infrastructure are different from those doing daily administrative work on the server infrastructure.
Most of the time, new servers are up and running much sooner than their monitoring is in place. And you already have the requirement to register all infrastructure in your CMDB. Why then would you want to register the same server in 2 different places?
So it seems quite natural that there should be some sort of interaction between the CMDB and Monitoring so that you only have to register the server once, and then all the entire orchestration for monitoring is done over the CMDB.
Most CMDBs for instance have the ability to notify of changes made to an asset via email. So the first thing to do is define the fields you will need to make monitoring interactions work. This consists of at least:
- An asset name
- An asset IP
- A field to specify which base monitoring profile should be needed. This should be just stuff like: Windows, Linux, Switch, Router, Database, etc.
- A list of monitoring roles. This means service-sets for special monitoring requirements, e.g., MSSQL-Server, Oracle-Server, and File-server. Thus each asset can have more than one role.
Having put all this information into the CMDB, it should be possible to send that information via email to the Monitoring System. Using a NetEye Server, it’s quite easy using the Eventhandler Module to intercept such an email and execute a local script to handle the object creation/update/delete.
In addition, information like downtime or maintenance windows could be sent over and handled by the monitoring system by setting downtime windows for the server in question.
In the real world I already implement interactions like this using CMDBs such as OmniTracker, or NetEye’s own AssetManagement GLPI. On the NetEye side, the Eventhandler module is responsible for intercepting the email notification and calling a script which uses the Icinga API to communicate with the Monitoring System.
Automation is a key factor in IT monitoring; without it, unnecessary duplication of tasks and human intervention would be required, slowing down IT support and operations teams worldwide. The more advanced the monitoring tool, the more automation it should provide. However there may be a tipping point when there’s too much automation present and human intervention would actually be preferable. It’s always wise to find a balance between total automation and manual intervention.
Juergen Vigna
Author
