Commvault software is an enterprise-level data platform used to back up, restore, archive, replicate, and search data. The software is available across cloud and on-premises environments, and a lot of customers are using this solution as part of their infrastructure. And in such situations the necessity arises to develop a solution for integrating COMMVAULT information in NetEye. In this article I’ll explain how to do just that.
Solution
In this section I’ll describe how NetEye integrates with COMMVAULT using its API and an ad-hoc script. The architecture of this integration plugin is laid out in this image:
The python script we developed manages communications between NetEye API/Tornado and CommVault API. Iterations between these two modules are performed in 5 steps in which the script:
- Step 1: requests the list of alerts and clients from CommVault
- Step 2: builds an Alarm ID composed of:
- * alertType * alertName * clientHostname
- The final result is: Job Managment – Aux copy job Failed – mycommvault.localdomain
- Step 3: gathers information about all services that are inside NetEye which are not in an “OK” status, and that belong to this host and are categorized as CommVault services (the last one by checking on the value of the created_by variable)
- Step 4: checks NetEye services are still active or that have been removed from Commvault, and then prepares a list of alerts that must be updated (either fired or cleared)
- Step 5: calls a dedicated Tornado Webhook that creates and/or updates the alarm linked to these services
How to run the script
The script can be run in this way:
cd /neteye/shared/monitoring/plugins/
./check_commvault.py -s <FQDN/IP> -u <USERNAME> -p <PASSWORD>In order to make everything work,the script creates within NetEye these entities:
- Command “check_commvault” via ad-hoc arguments/fields
- Active Service Template “generic-active-service-commvault”
- Passive Service Template “generic-passive-tornado-commvault”
- Important: Add the custom variable created_by set to commvault_api
- Add the service to the Commvault host and configure it
- Create a Tornado Webhook ../tornado_webhook_collector/conf/webhooks/commvault.json
- Create a Tornado Webhook ../tornado_webhook_collector/conf/webhooks/commvault.json
{
"id" : "commvault",
"token": "WEBHOOK_TOKEN",
"collector_config": {
"event_type": "commvault_event",
"payload": {
"data": "${@ajay-sharma
}
}
}
- Tornado Rule: creates an ad-hoc smart monitoring action that will dynamically create or update the services (if you need help with this, please contact us)
At the end, remember to set this hard-coded information:
WEBHOOK_TOKEN = "****" WEBHOOK_ID = "****" WEBHOOK_FQDN = "****" ICINGA_API_USER = "****" ICINGA_API_PASSWORD = "****" CREATED_BY = "****"
Conclusions
The final result will be a host with an active service used to define the COMMVAULT username, password, endpoint, and frequency.
Along with a set of services linked to the number of alarms fired by Commvault:
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix
Attilio Broglio
Author
