I think the short answer would be "why not?". If we manage our IT services through our ITSM suites (as we should), and we integrate processes like change and CMDB, why would we not want to integrate and automate the control of monitoring our critical infrastructure as well?
Historically, the processes of monitoring and event management are separated from ITSM due to technology constraints. Vendors were unable to produce a single stable platform that could deal with high data volumes needed for monitoring on the same platform with easy to use form based workflow needed for traditional ITSM processes. So we were told by vendors that these processes were separate, and in most cases we even split up our teams to create separate antagonistic groups of "monitoring guys" and "ITSM guys".
Fast forward to now. These technology constraints are long gone. We have cloud. We have big data, and we even have a methodology called devops that insists we squash these processes together to better serve the customer. There is really no good reason to keep monitoring separated from ITSM processes.
Let's focus on two key reasons why co-locating monitoring on the ITSM platform makes sense, highlighting two requirements that we see at almost every customer.
Requirement 1: Automatic Provisioning of the Monitoring. Having been in the IT monitoring space for more than an decade, I have created countless scripts and solutions to automate the provisioning of monitoring. (haven't we all?) The requirement is simple, yet very hard to fulfill. When a device gets discovered and is added to the CMDB, it needs to be monitored using predefined standards after the change ticket has been approved. Custom scripts are hard to create and maintain, generally have a low level of integration functionality, and can be quite brittle.
Requirement 2: Time Sensitive Operations. Time matters. It is common to require a separate set of alerting thresholds for your monitoring metrics during a scheduled change window. For example, a nightly DB replication or a server backup job will send CPU and Disk IO through the roof, but that's expected behavior and should not create an alert. In almost all cases where there is some type of time sensitive rule to address this, it's manually configured by the monitoring admin. (Dynamic threshold methodologies also don't help here when the schedule can change without notice)
So what's the good news? The data we need to drive the automation of these requirements is right there within your ITSM suite. Since Evanios Monitoring is built as a ServiceNow application, that data is immediately available, and we can continuously leverage that data to make better decisions.
With Evanios Monitoring, both of these requirements can be automated right out of the box.
The following picture illustrates how the ServiceNow monitoring provisioning is implemented with Evanios Monitoring .
You can monitor servers, networks, or websites — and control it all through ServiceNow. Evanios Monitoring is a complete infrastructure monitoring solution that runs inside the ITSM platform, delivering an unprecedented level of integration with YOUR ITSM processes.
