Alerting, Aria Operations, Aria Operations for Logs, vRLI, vROps

VMware Aria Operations for Logs Alerts as Symptoms in Aria Operations

As is likely known to everyone, the integration between VMware Aria Operations and Aria Operations for Logs involves forwarding alarms generated in Aria Operations for Logs to Aria Operations. If the integration has also established the link between the origin of the log message that triggered the alarm and the object in Aria Operations, the alarm in Aria Operations will be specifically “attached” to the correct object.

As seen in the following two images, the static field vmw_vr_ops_id ensures that the alarm triggered in Aria Operations for Logs appears as a Notification Event on the affected object in Aria Operations. In my case a virtual machine experiencing issues with an application.

Figure 01: Log messages in Aria Operations for Logs triggering a configured alert.
Figure 02: Notification Event in Aria Operations.

This functionality is completely sufficient for many use cases and helps to quickly detect problems and identify their root causes.

However, there are specific use cases that cannot be implemented with it. One such use case, for example, is the requirement to attach an Aria Operations Notification to such alarms, which in turn would trigger actions such as Webhooks. As of today, the configuration of Notifications does not allow Notification Events to be used as Alert Definitions under Category.

So, if we want to use Notifications for alarms coming from Aria Operations for Logs, we need to create an Alert Definition in Aria Operations, and for that, we need a Symptom. The task, therefore, is to build a Symptom from a Notification Event.

In my example, I want to build a Symptom from the Aria Operations for Logs Alarm, which arrives as a Notification Event in Aria Operations, as shown in the following image. As we can see, the name of the alarm in Aria Operations for Logs is tk-FailedESXiLoginAttempt on ${hostname}.

Figure 03: Alert definition in Aria Operations for Logs.

The Symptom in Aria Operations is based on a Message Event and has the Adapter, Object, and Event Types as depicted in the following image.

Figure 04: Message Event based Symptom definition in Aria Operations.

The details of the Symptom are shown in the following image. It is important to use contains as the condition here because Aria Operations for Logs replaces the field ${hostname} with the FQDN corresponding to the affected ESXi system. The string in the Contains condition is tk-FailedESXiLoginAttempt.

NOTE: This is part of the string as it is currently transmitted by Aria Operations for Logs at the time of writing this post.

Figure 05: Condition in the Symptom definition in Aria Operations.

Now, with this Symptom, an Alert Definition can be created in Aria Operations. The next images show the Alert Definition in my example.

Figure 06: Alert definition in Aria Operations.
Figure 07: Details of the Alert definition in Aria Operations.

With that, the Alert Definition can be further customized as usual, for example, by adding a Notification to it.

And this is how it looks in Aria Operations when someone attempts to log in to an ESXi host via SSH with an incorrect password.

Figure 08: Alarm in Aria Operations.

Stay safe.

Thomas –

Leave a Reply

Your email address will not be published. Required fields are marked *