An alert is a notification generated by the system based on a set of conditions. An alert must be set for a specific resource such as an App service. Alerts can be associated with an Action of sending out a Notification to the user via email or a webhook API whenever the condition is true.
Different conditions can be set for triggering an alert. Depending on what alert notification user is looking for, the user can either set a single alert condition or multiple conditions based on the requirement.
Alerts have the following components:
Alert audience profile: You can create any number of alert profiles or Actions. Each profile or Action provides customized notifications to audience. When creating an Alert, these audience profiles or existing Actions can be added to Alert definition.
Alert channel: A channel is a messaging medium over which alerts are sent. For example, email or Webhook. The following image shows how audience profiles or Actions can be created with a combination of email IDs or webhooks.
Alert trigger: Alerts are raised underlying conditions are met. These conditional policy triggers work on metrics or strings. For more information, refer to Triggers. When defining an Alert, a Trigger must be associated with the alert.
Alert Resource Instance: Triggers are policy templates and need to be associated with a resource instance to be able to generate an alert. Resources are App Services such as VIPs, FW rulesets, and CGN technologies, and Service resources such as NAT Pools, FW Rules, Clusters, Device, or Partitions. Each such instance has a unique global ID or name.
Alert rules enable you to define the policy violations for which you want to trigger alerts. When you create an alert rule, this provides you with flexibility in how you manage alerts and ensures that compliance to the administrative boundaries you defined. You can create a single alert rule that alerts on multiple policy rules or you can define granular alert rules that send very specific sets of alerts for resources.