This topic describes the terms that are used in the alerting feature of Log Service.

Term Description
Logstore Log Service provides Logstores to store log data. You can use the SQL-92 syntax to query and analyze log data. Alert monitoring tasks are based on the query and analysis feature.
Metricstore Log Service provides Metricstores to store time series data. You can use the PromQL syntax and SQL-92 syntax to query and analyze time series data. Alert monitoring tasks are based on the query and analysis feature.
alert An alert indicates an alert event. If an alert is triggered based on a specific alert monitoring rule, the alert event is sent to the alert management system and then to the notification management system.

The alerting module of Log Service provides subsystems, features, entities, and submodules such as the alert monitoring system and alert monitoring rules.

alert monitoring system The alert monitoring system is a subsystem that triggers alerts. The alert monitoring system contains alert monitoring rules and resource data.

The alert monitoring system periodically monitors and evaluates query and analysis results based on alert monitoring rules. If an alert is triggered or cleared based on an alert monitoring rule, the alert monitoring system sends the alert or a recovery notification to the alert management system based on the monitoring rule orchestration.

alert management system The alert management system is a subsystem that denoises alerts and manages alert statuses. The alert management system contains alert policies, alert incidents, and alert dashboards.

The alert management system dispatches, suppresses, deduplicates, silences, and merges alerts based on alert policies, and then sends the processed alerts to the notification management system. The alert management system also allows you to switch incident phases and specify handlers for incidents.

notification management system The notification management system is a subsystem that manages notification methods and recipients. The notification management system contains action policies, alert templates, calendars, users, user groups, on-duty groups, and notification method quotas.

The notification management system sends notifications to specified recipients by using specified notification methods. Recipients can be users, user groups, or on-duty groups. The notification management system also allows you to escalate alerts and create custom alert templates.

alert ingestion system The alert ingestion system is a subsystem that ingests external alerts. The alert ingestion system contains alert ingestion services and alert ingestion applications.

Each alert ingestion application provides a webhook URL to ingest alerts from external services such as Zabbix or Prometheus. After an external alert is ingested, the alert ingestion system processes the alert and then sends the alert to the alert management system. Recovery notifications can also be ingested.

Alert monitoring system

Alerts are triggered in the alert monitoring system. The alert monitoring system contains alert monitoring rules and resource data. The following figure shows the architecture of the alert monitoring system.

Alert monitoring system
Term Description
alert monitoring rule An alert monitoring rule includes the settings that are configured to monitor data, such as query statements, objects that are queried and analyzed, and the related monitoring rule orchestration. The objects that are queried and analyzed include Logstores, Metricstores, and resource data. For more information, see Create an alert monitoring rule for logs.
resource data Log Service provides an independent, modifiable, and tabular storage structure to store various resource configurations and custom data. You can use resource data to perform union queries. For example, you can use resource data to monitor blacklists and whitelists.

For more information, see Create resource data.

alert severity An alert severity is a non-identifying attribute of an alert. Alert severities include critical, high, medium, low, and report. For more information, see Specify alert severities.

After external alerts are ingested into the alert ingestion system, Log Service uses the keywords of the alerts to match severities based on application protocols. If no severity matches the keyword of an alert, Log Service considers medium as the severity of the alert.

group evaluation When you create an alert monitoring rule, you must specify the Group Evaluation parameter. When the alert monitoring system calculates query and analysis results, it can group the results based on specified fields. The results in each group are evaluated based on the specified trigger condition. If the results in a group meets the trigger condition, an alert is triggered. You can use an alert monitoring rule to monitor multiple groups of query and analysis results at the same time. You can manage alerts and incidents for each group. For more information, see Group evaluation.
evaluate expression Evaluate expressions support specific syntax. Log Service can check whether the specified trigger condition is met and evaluate the severity of an alert based on the result of an evaluate expression.

To perform logical comparisons and calculations, you can use the fields of query and analysis results in an evaluate expression. If the result of an evaluate expression is true, the query and analysis results match the evaluate expression. For more information, see Syntax of evaluate expressions.

alert label An alert label is an identifying attribute of an alert. Labels are formatted in key-value pairs. You can add a label when you configure an alert monitoring rule. If an alert is triggered based on the rule, the label is added to the alert as an alert attribute. Labels can be referenced in alert templates. When you manage alerts and configure action policies, you can specify labels as alert attributes.
  • If you group query and analysis results of data in Metricstores based on labels and monitor the results by group, Log Service uses the labels as alert attributes.
  • If you group query and analysis results of data in Logstores based on fields and monitor the results by group, Log Service uses the key-value pairs of the fields as alert attributes.

For more information, see Labels.

alert annotation An alert annotation is a non-identifying attribute of an alert. Annotations are formatted in key-value pairs. You can add an annotation when you configure an alert monitoring rule. If an alert is triggered based on the rule, the annotation is used as an alert attribute. Annotations can be referenced in alert templates. When you manage alerts and configure action policies, you can specify annotations as alert attributes. For more information, see Annotations.
recovery notification Recovery notifications are special alert notifications. In a recovery notification, the alert status is Resolved. In a normal alert notification, the alert status is Firing. For example, the recovery notification feature is enabled in an alert monitoring rule. If an alert is triggered in the last check, and the trigger condition is not met in the current check, a recovery notification is sent. If you configure multiple monitoring tasks, we recommend that you enable the recovery notification feature. This way, you can receive notifications at the first opportunity after alerts are cleared. For more information, see Recovery notifications.

Alert management system

The alert management system denoises alerts and manages alert statuses. The alert management system contains alert policies, alert incidents, and alert dashboards. The following figure shows the architecture of the alert management system.

Alert management system
Term Description
alert policy Alert policies are configuration entities of the alert management system. You can configure alert policies when you ingest external alerts and configure alert monitoring rules. After the alert management system receives alerts and recovery notifications, it denoises and merges the alerts based on alert policies. Then, the alert management system sends merge sets to the notification management system and the notification management system sends alert notifications.
alert fingerprint The alert management system calculates a fingerprint for each alert. Alerts with the same fingerprint are considered as the same alert. Fingerprints are calculated based on the identifying attributes of alerts. The identifying attributes include the Alibaba Cloud accounts to which alerts belong, projects in which alerts reside, IDs of monitoring rules, and labels. For more information, see Deduplicate alerts based on fingerprints.
alert silence You can configure a silence policy when you configure an alert policy. If an alert is triggered during the silence period and the alert matches the specified conditions, no alert notification is sent. For more information, see Silence policies.
alert suppression You can configure a suppression policy when you configure an alert policy. If the alert management system receives an alert that matches the conditions in the suppression policy, the alert is suppressed. For example, if a Kubernetes cluster triggers a critical alert and you want to suppress non-critical alerts, you can create a suppression policy. For more information, see Suppress alerts.
route consolidation policy You can configure a route consolidation policy when you configure an alert policy. If the alert management system receives alerts that match the conditions of a route consolidation policy, the alert management system groups the alerts into different merge sets based on the route consolidation policy. Then, the alert management system delays and deduplicates the merge sets based on the route consolidation policy and sends them to the notification management system. For more information, see Merge alerts.
merge set A merge set stores alerts that are merged and grouped. Each merge set can have one or more fingerprints. The alert management system delays and deduplicates merge sets based on a route consolidation policy and sends them to the notification management system.
alert incident After alerts are sent to the alert management system, the alerts are grouped into different merge sets based on a route consolidation policy. An incident is automatically created for each merge set. You can switch incident phases and specify incident handlers in the Log Service console. Incident statuses include confirmed, resolved, ignored, and pending evaluation. For more information, see Switch an incident phase.

Log Service can automatically update incident statuses and escalate alerts. For example, if an alert is triggered again for an alert incident that is in the resolved state, the status of the alert incident automatically changes to pending evaluation. If a recovery notification is received for an alert incident that is in the confirmed state, the status of the alert incident automatically changes to resolved.

Notification management system

The notification management system manages the notification methods and recipients of alert notifications. The notification management system contains action policies, alert templates, calendars, users, user groups, on-duty groups, and notification method quotas. The following figure shows the architecture of the notification management system.

Action policy
Term Description
action policy Action policies are configuration entities of the notification management system. After alerts and recovery notifications are grouped into different merge sets based on route consolidation policies, the merge sets are sent to the notification management system. Then, the notification management system sends alert notifications to specified recipients by using specified notification methods. The recipients can be users, user groups, or on-duty groups. The notification management system can escalate incidents that are not handled in time.

You can specify conditions to escalate alerts when you configure an action policy.

For information about how to configure an action policy, see Create an action policy.

webhook integration The webhook integration feature is used to manage the webhook notification methods. When you configure an action policy, you can use the webhooks that you created. Log Service supports DingTalk webhooks, Enterprise WeChat webhooks, Lark webhooks, Slack webhooks, and universal webhooks. For more information, see Create a webhook.
alert escalation If an alert incident remains unconfirmed or uncompleted for a long period of time, the incident is processed based on the action policy that is specified on the Second Action Policy tab. This way, the incident can be handled at the earliest opportunity. For more information, see Escalate alert incidents.
alert template Log Service sends alert notifications based on the content that is specified in alert templates. You can specify text content for each notification method in an alert template. You can also reference template variables to specify alert attributes. If you send alert notifications by using webhooks, you can specify notification formats based on specific protocols. For example, you can specify a content format to meet the requirements of Enterprise WeChat. For more information, see Create an alert template.
calendar The notification management system provides calendars. You can use the global default calendar or a custom calendar.
  • The global default calendar provides information such as time zones, holidays, business days, and business hours.

    The period of time during which alert notifications are sent is based on the settings of the global default calendar, such as business days, non-business days, business hours, and non-business hours.

  • Only on-duty groups can use a custom calendar to specify business days and holidays.
user Users are recipients who receive alert notifications. The information of a user includes the user ID, username, phone number, and email address. When you configure action policies, you can specify users as recipients of alert notifications. You can specify users to handle incidents when you manage incidents.

For information about how to create a user, see Create a user.

user group A user group is a configuration entity that represents users. The information of a user group includes the user group ID, user group name, and users. Each user group contains one or more users. When you configure action policies, you can specify user groups as recipients of alert notifications.

For information about how to create a user group, see Create a user group.

on-duty group An on-duty group is a configuration entity that represents users and user groups. The information of an on-duty group includes the on-duty group ID, on-duty group name, rotating shifts, substitute shifts, and calendar settings. Each on-duty group contains one or more users or user groups. When you configure action policies, you can specify on-duty groups as recipients of alert notifications.

For information about how to create an on-duty group, see Create an on-duty group.

rotating shift You can configure a rotating shift for users or user groups in an on-duty group. You can add multiple rotating shifts to an on-duty group. You can configure a rotating shift based on the days that you specify on the calendar. You can also configure a rotating shift for non-consecutive hours.

For more information, see Rotating shifts and substitute shifts.

substitute shift You can configure a substitute shift for users or user groups in an on-duty group. You can add multiple substitute shifts to an on-duty group.

For more information, see Rotating shifts and substitute shifts.

notification method quota Log Service allows you to specify a daily quota on alert notifications that are sent to specified recipients by using SMS messages, voice calls, or emails. If the number of alert notifications sent to a recipient by using a specified notification method reaches the quota, the recipient can no longer receive alert notifications by using the notification method. You can specify a quota for alert notifications that a recipient can receive every day.

For more information, see Configure notification quotas.

Alert ingestion system

The alert ingestion system ingests external alerts. The alert ingestion system contains alert ingestion services and alert ingestion applications.

Term Description
alert ingestion application An alert ingestion application provides a specific protocol and webhook URLs for an external service, such as Grafana or Prometheus, to ingest alerts into Log Service. By default, alerts can be ingested over a LAN or the Internet in all regions. The HTTP and HTTPS protocols are supported. After Log Service receives alerts from a third-party service, Log Service manages the alerts by using the preset alert policy.
alert ingestion service An alert ingestion service is a container or a namespace for ingestion applications. An alert ingestion service can contain multiple alert ingestion applications. For example, if an O&M team wants to receive alerts from Grafana and Prometheus, the team can create two alert ingestion applications whose protocols are Grafana and Prometheus in an alert ingestion service.