面向多告警源，如何构建统一告警管理体系？-阿里云开发者社区

本文介绍告警统一管理的最佳实践，以帮助企业更好地处理异构监控系统所带来的挑战和问题。

背景信息

在云原生时代，企业IT基础设施的规模越来越大，越来越多的系统和服务被部署在云环境中。为了监控这些复杂的IT环境，企业通常会选择使用异构监控系统，例如Prometheus、Grafana、Zabbix等，以获取更全面的监控数据，以便更好地了解其IT基础设施的运行状况和性能表现。

然而，这种异构监控系统也带来了一些问题，其中最显着的是告警信息的分散。由于不同的监控系统可能会产生不同的告警信息，这些信息可能会分散在各个系统中，导致企业很难全面了解其IT系统的告警状况。这使得响应告警变得更加困难，同时也增加了人工管理的复杂性和工作量。

为了解决这些问题，企业需要一种更加统一和集中的告警管理方案，以确保告警信息能够及时到达正确的人员，以便他们能够快速采取必要的措施来应对潜在的问题。

告警管理的痛点

场景一：企业迁移上云后，云上产品的告警不统一

在一个典型的云原生业务应用部署架构中，通常会使用到如下产品 ACK、ECS、RDS，应用通过Kubernetes部署在阿里云的ECS上并访问云上的RDS。在这个架构中通常会用到如下监控产品来对系统进行监控。

通过CloudMonitor对阿里云基础设施ECS和RDS进行监控，当资源出现异常时进行告警。
通过Prometheus对Kubernetes以及部署在kubernetes上的Pod进行监控，当Kubernetes出现异常时进行告警。
通过ARMS对部署在Kubernetes上的应用进行监控，包括应用直接的调用链。当应用异常时进行告警。
通过SLS对应用产生的日志进行监控，当日志出现异常时进行告警。

在这样一个场景下由于用到了多个云产品对整个系统进行监控会导致使用者需要在多个产品上重复配置联系人、通知方式、值班等运维配置。且不同系统之间的告警无法产生有机结合，当一个问题出现时不能快速关联不同告警系统中的相关告警。

场景二：多云、混合云架构下，异构监控系统告警不统一

当企业的应用部署在多云环境或混合云环境下时，监控系统产生的告警可能会更加分散和复杂，给企业的运维工作带来很大的挑战。由于不同的云平台和私有云架构之间的差异，监控数据的采集和处理方式也可能不同，因此，不同监控系统产生的告警信息也可能表现出差异化，这会带来一系列的问题。

首先，不同监控系统产生的告警信息分散在不同的地方，运维人员需要耗费更多的时间和精力去处理这些信息。其次，不同系统产生的告警信息难以统一进行管理和分析，使得问题的诊断和解决更加困难。此外，因为不同系统的告警信息可能存在重复或冲突，管理和处理这些信息也会变得更加复杂。

场景三：自研监控系统、自定义事件告警接入

在应用开发运维过程中，随着系统规模的扩大和复杂度的提高，各个角落中的胶水代码逐渐增多。这些代码虽然是连接不同模块和系统的重要纽带，但一旦出现问题，由于分散在不同的地方，很难立即发现和处理。这就使得企业难以保证系统的高可用性和稳定性。如何灵活的低成本的接入这部分代码产生的告警也成为企业应用运维的痛点之一。

统一告警管理

在构建统一告警管理平台过程中，不同的监控系统对告警定义、处理流程都不一样，往往会存在下面问题：

不同系统产生的告警格式不同，接入成本高。
不同系统间的告警接入后由于格式不统一，难以统一处理逻辑。
不同告警系统对于告警等级的定义不同。
不同告警系统对于告警自动恢复的处理方式不同。有的告警系统支持自动恢复，有的不支持。

ARMS告警管理^[^1]设计的集成、事件处理流、通知策略等功能专门针对告警统一管理的场景，解决了统一管理过程中遇到的诸多问题。

ARMS告警管理如何接入不同格式的告警？

传统告警通常包括如下一些内容，这种结构化的告警通常只适用于单一告警源。当多个告警源的数据汇总到一起后通常会导致数据结构的冲突。因此ARMS使用了半结构化的数据来存储告警。

阿里云监控告警数据格式：

Zabbix告警数据格式：

Nagios告警数据格式：

半结构化的告警数据结构

[
  {
   "labels": {
    "alertname": "<requiredAlertNames>",
    "<labelnames>": "<labelvalues>",
    ...
   }, 
   "annotations": {
   "<labelnames>": "<labelvalues>",
   }, 
   "startsAt": "<rfc3339>",
   "endsAt": "<rfc3339>",
   "generatorURL": "<generator_url>"
  },
  ...
]

labels（标签）：告警元数据，一组标签唯一标识一个事件，所有标签均相同的事件为同一个事件，重复上报会进行合并，例如：alertname: 告警名称。
annotations（注释）：注释是告警事件的附加描述，注释不属于元数据。例如：message: 告警内容。不同时间点发生的同一个事件他们的标签是相同的，但是注释可以是不同的。比如告警内容的注释可能不同，例如：“主机i-12b3ac3*** CPU使用率持续三分钟大于75%，当前值82%”。
startsAt（告警开始时间）：告警事件开始时间。
endsAt（告警结束时间）：告警事件结束时间。
generatorUrl（事件URL地址）：告警事件URL地址。

如上述代码所示，ARMS参考开源Prometheus告警定义^[^2]，使用一个半结构化的数据结构来描述告警。通过高度可扩展的键值对来描述告警，这样就可以非常灵活的对告警内容进行扩展从而接入不同的数据源产生的告警。

任意JSON格式的自定义告警接入能力

ARMS告警提供了任意一种JSON格式接入的能力（自定义集成^[^3]）。只要告警数据结构满足JSON格式就能接入。如下图所示，自定义告警接入需要先将告警内的JSON数据上传到ARMS告警中心后，通过页面编辑字段映射的方式将告警内容中的关键信息映射到ARMS告警数据结构中。

ARMS定义了如alertname等关键字段，对于更多的扩展字段，用户可以在集成中通过新增扩展字段的方式进行配置。所有的扩展字段都可以运用到后面的告警处理逻辑中。以下图为例将原始告警报文中的hostname字段映射到扩展的hostname字段，hostip字段映射到扩展的hostip字段。

常用监控工具告警快捷接入能力

ARMS默认提供了云上云下多种监控系统的告警接入能力，可以参考集成概述^[^4]进行快速接入。

ARMS告警管理如何统一告警等级？

ARMS中将告警分为P1、P2、P3、P4四个等级。通过配置映射表，将多个不同类型的等级归一到P1-P4四个等级。如下图所示，将L1、Critical、严重告警这三种不同描述的告警等级都映射为P1告警，这样就可以统一不同系统中对于告警等级的不同定义。

ARMS告警管理对于不同格式的告警如何统一处理逻辑？

由于ARMS告警采用了半结构化的数据结构，可以通过标签来统一告警的处理逻辑。通常我们需要至少2个标签来统一告警的处理逻辑。一个标签用来决定这个告警应该通知给哪些人，比如业务标签（service,biz）。另一个标签用来决定这个告警应用通过什么样的方式进行通知和升级。如下表所示，通常使用告警等级（severity）来定义告警处理的SLA。

ARMS设计了通知策略和升级策略两种策略来满足不同等级的告警的处理要求，您可以参考通知策略最佳实践^[^5]来进行配置。

标签设计原则

当我们在设计用于告警处理的业务标签时需要满足如下原则：

互斥原则：指避免对同一个资源使用两个或以上的标签键。例如：如果已经使用了标签键service来标识业务，就不要再使用biz或业务等类似的标签键。
集体详尽原则：指所有资源都必须绑定已规划的标签键及其对应的标签值。例如：某公司有3个业务，标签键是service，则应至少有3个标签值分别代表这3个业务。
有限值原则：指为资源只保留核心标签值，删除多余的标签值。例如：某公司共有5个业务，那么应该有且仅有这5个业务的标签，方便管理。

除了业务标签也可以定义其他的标签来进行告警的管理，比如使用环境标签来区分开发和测试环境的告警。这些标签应该满足上述设计原则，这样可以简化告警管理配置的复杂度。

通过事件处理流给告警打标签（富化告警）

当我们设计好标签后如何对不同告警源的告警打标呢。在ARMS告警管理中设计了低代码方式的事件处理流^[^6]，通过拖拉拽的配置方式可以实现给告警打标签的能力（富化告警）。

场景一：匹配特定条件后给告警打标签

某xx业务使用了自研监控系统，通过自定义集成将自研的告警接入到ARMS告警管理中后，需要对这部分告警统一打上业务标签xx。事件处理流的配置如下：

a. 登录ARMS控制台^[^7]，在左侧导航栏选择告警管理，然后单击新建处理流。

b. 在弹出的面板创建事件处理流，编辑触发条件匹配自定义集成的名称为“xx自研监控系统”。

c. 添加设置业务标签动作，将"xx"设置为业务（service）标签值。

场景二：切割字符串，提取标签

某自研告警系统中所有的主机都使用固定格式进行命名，命名格式为env−env−{env}-{biz}-app−app−{app}-{group}-${index} ，需要提取其中的biz字段做为业务标签。配置正确的触发条件后，使用分割内容操作，将hostname根据字符'-'进行分割，分割后的内容依次填充到env、service、 app、group字段。

场景三：通过查询Excel表格富化告警

某应用监控平台，在发生告警时仅通知了应用ID，需要根据Excel表格关联到应用名称、应用责任人等信息。

a. 创建Excel数据源，并上传app_cmdb.xlsx文件。

b. 配置事件处理流，添加字段丰富操作，选择数据源为第一步创建的数据源。编辑匹配字段为appId，将Excel表中其他字段分别填充到appName、owner、ownerPhone扩展字段中。

场景四：通过Serverless（FunctionCompute）调用外部服务富化告警

同上述场景三，当告警中缺失的数据需要从CMDB等外部系统获取时，可以通过API类型的数据源来进行告警富化。

a. 创建函数计算应用^[^8]，开发一个HTTP服务，接收入参为appId，返回出参为appName、owner、ownerPhone等参数。如下截图仅为示例代码。

b. 创建API类型的数据源，URL地址为第一步中开发的函数。

c. 配置事件处理流，添加字段丰富操作，选择数据源为上一步创建的数据源。编辑匹配字段为appId，将Excel表中其他字段分别填充到appName、owner、ownerPhone扩展字段中。

ARMS告警管理如何配置告警自动恢复？

不同的监控系统对告警自动恢复的处理逻辑大不相同。如Prometheus告警不会发送特定格式的恢复告警，仅通过告警时间来标识告警是否结束。阿里云云监控^[^9]中告警是否恢复的状态合并到了告警等级中，如下所示。

参数：triggerLevel
数据类型：String
本次触发报警的级别。取值：

CRITICAL：严重
WARN：警告
INFO：信息
OK：正常

不同场景下的告警在处理是否恢复的逻辑可能也会有所区别。如阈值类型的告警，当监控值不满足阈值条件时期望立即恢复告警。但是对于事件类型的重要告警，告警发生只在一瞬间，并没有恢复的过程。需要运维人员人工确认事件产生的影响已经消除后才能恢复告警。

场景一：针对不会恢复的告警，配置自动恢复时长，告警按照时间自动恢复

针对事件类型的告警，通常需要人工确认事件的影响范围后再处理告警。这时告警自动恢复可能会导致需要被处理的事件没有被人工处理。针对这种情况需要在接收到告警后不进行自动恢复或者至少在一个长周期内不自动恢复，给处理人员一定的时间来确认该告警的影响。

ARMS自定义集成配置告警自动恢复时间截图：

场景二：配置恢复告警字段，接收到恢复事件后恢复告警

在ARMS的告警集成中，可以通过配置告警恢复字段，当告警内容中某个字段的值满足条件时，视为恢复告警。根据该告警的其他字段的内容寻找对应的告警进行恢复。告警主动恢复的示意图如下所示：

ARMS控制台配置方式截图：

告警恢复需要满足如下2点，才能正确的恢复对应的告警。

如果没有定义去重字段，那么告警和恢复告警的标签需要完全一致才能正确恢复告警。
如果定义了去重字段，那么告警和恢复告警的去重字段需要完全一致才能正确恢复告警。

说明：当配置了某个字段如（status）做完告警恢复字段时，请不要将这个字段添加到告警的映射规则中。通常会导致告警与恢复告警字段不匹配，从而恢复失败。

补充信息

FunctionCompute示例代码：

# -*- coding: utf-8 -*-
import logging
import json
def handler(environ, start_response):
    context = environ['fc.context']
    request_uri = environ['fc.request_uri']
    body_str = get_request_body(environ)
    id = json.loads(body_str).get('appId')
    # 这一行为伪代码，示例通过查询cmdb获取应用详细信息, 获取到的app格式如下
    # {"appId":"b38cdf95-2526-4d7a-9ea9-ffe7b32*****", "appName": "iot-iam", "owner":"王五", "ownerPhone": "130xxxx1236"}
    app = cmdb.getApp(id)
    ret = json.dumps(app)
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [ret.encode('utf-8')]
def get_request_body(environ):
    try:
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))
    except (ValueError):
        request_body_size = 0
    request_body = environ['wsgi.input'].read(request_body_size)
    return request_body