Using the adapter instance in Aria Operations notifications

When building a new VMware SDDC it takes some time before you can hand over management duties to an existing team. In the meantime you want to get notified when something breaks using tools which are already in place. In this blog post I will explain how to use the adapter instance in Aria Operations so you can easily filter notifications.

In a previous blog post I explained how I used webhooks to send notifications to Opsgenie. I aim to build upon that knowledge by leveraging the adapter instance name in Aria Operations as an extra property, enabling the targeted routing of notifications.

Now as most of you will probably know when you add a resource to Aria Operations you can give it a name that is meaningful to you. This name is called the adapter instance name. In most cases I’ve seen people simply use the FQDN, but you can choose anything you want. In this case I will add the purpose of the adapter instance to its name. This allows me to identify all resources under this adapter instance including things like ESXi hostnames, datastores etcetera.

Now the adapter instance name contains something which can be used to filter notifications it is time to add this information to the alert payload templates. When using the Opsgenie API you have the ability to send extra properties in the form of key-value pairs using the ‘details’ field. In this case I use the alert criticality and adapter instance name as extra properties. You need to add this field to both the new and update API calls.

{
"message": "[vROPS]Alerton${RESOURCE_NAME}:${ALERT_DEFINITION}",
"alias": "${ALERT_ID}",
"description": "New alert was generated at date${CREATE_TIME}:\nInfo:${RESOURCE_NAME}${RESOURCE_KIND}isactingabnormallysince${CREATE_TIME}andwaslastupdatedat${UPDATE_TIME}\n\nAlertDefinitionName:${ALERT_DEFINITION}\nAlertDefinitionDescription:${ALERT_DEFINITION_DESCRIPTION}\nObjectName:${RESOURCE_NAME}\nObjectType:${RESOURCE_KIND}\nAlertImpact:${ALERT_IMPACT}\nAlertState:${ALERT_CRITICALITY}\nAlertType:${ALERT_TYPE}\nAlertSub-Type:${ALERT_SUBTYPE}\nObjectHealthState:${OBJECT_HEALTH_STATE}\nObjectRiskState:${OBJECT_RISK_STATE}\nObjectEfficiencyState:${OBJECT_EFFICIENCY_STATE}\nControlState:${CONTROL_STATE}\nSymptoms:\n${SYMPTOMS}\nRecommendations:${ALERT_RECOMMENDATIONS}\nNotificationRuleName:${NOTIFICATION_RULE_NAME}\nNotificationRuleDescription:${NOTIFICATION_RULE_DESCRIPTION}\nAlertID:${ALERT_ID}\nVCOpsServer-${HOST_NAME}",
"entity": "${RESOURCE_NAME}",
"source": "${HOST_NAME}",
"details": {
"vrops_alert_criticality": "${ALERT_CRITICALITY}",
"vrops_adapter_instance": "${ADAPTER_INSTANCE}"
}

When you receive an alert with the adapter instance it will look something like this.

Within Opsgenie you navigate to your team and configure the on-call routing rules. In this example I created a rule that sends all notifications for project adapter instances to a separate team.

Keep in mind that the adapter instance does not only contain the instance name. So I made sure to write the routing rules with the ‘starts with’ operator. Alternatively you can also use the RegEx operator.

With all this in place you can make sure that for the duration of a project you can easily route any alerts to a temporary team. When you hand over management duties you can simply remove the routing rule and the default routing will take effect.

Happy monitoring guys!