By: Bekah Suttner, Blue Medora
Alerts are a key feature of VMware vRealize Operations Manager (vROps). While third-party management packs usually provide pre-defined alerts out of the box, custom alerts are a must for comprehensive monitoring. In this blog, I’ll be creating a custom alert for MySQL monitoring needs.
Figure 1 – Alert definitions from Blue Medora’s vROps Management Pack for MySQL
For this particular MySQL system, I’d like an alert to be triggered when my database reaches 75% used capacity. Before creating a new alert from scratch, it’s worth checking to see if any pre-defined alerts are nearly suited to your needs. It is possible to edit the existing alert definitions to better suit your needs, rather than creating an entirely new alert. To do this, navigate to the Content panel and select Alert Definitions. From here, select the alert that most closely suits your needs and click on the edit pencil icon. You can edit the definition as you see fit to best suit your environment’s needs.
If none of the existing alerts fit your use case, you will need to create a new alert. Under Content->Alert Definitions, click on the green plus sign. Give your alert a name and an optional description. Here, I will name my alert “MySQL 75% Capacity Reached” and add a short description to my alert. Next, I’ll select the object that will trigger the alert, a MySQL instance.
Figure 2 – Defining alert impact in vRealize Operations
The next step is to define the alert impact, as seen above in Figure 2. First, choose how your alert will be classified: health, risk, or efficiency. In this case, I chose to classify my alert as an efficiency issue. Next, I set the criticality of my alert. The next dropdown asks you to choose an alert type and subtype, which groups the alert with similar alert types, making it easier for me to share my alert with appropriate teams if it is triggered.
Next, I’ll choose my wait cycle, which allows me to choose how many data cycles are collected before the alert is triggered. In this case, I chose four cycles. If a situation allows less urgent response, I can set the wait cycle to a larger number to be sure that my problem is persistent before an alert is triggered. The final number in this step is the cancel cycle, or the number of data cycles that must pass with the metric below the alert threshold before the alert is cancelled. For this alert, I set the cancel cycle to four.
Figure 3 – Adding a symptom definition
Finally, you will want to add symptom definition to your alert. These definitions allow you to define one or more situations in which your alert should be triggered. Symptoms can be defined based on metrics and properties, message events, fault events, metric events, or smart early warnings. If a symptom definition does not suit your need, click the green plus sign to create a definition suited to your need, as I did in Figure 2 above. After this, you can optionally add recommendations to your alert, in case other administrators will be viewing the alerts and are unsure of the best way to resolve the alert.
Figure 4 – The new alert, listed amongst all other alert definitions
For more information on creating custom alerts, visit the VMware Documentation Center. For more information on management packs for vRealize Operations, visit Blue Medora’s website.
