ARMS统一告警管理最佳实践

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

• 通过CloudMonitor对阿里云基础设施ECS和RDS进行监控，当资源出现异常时进行告警。

• 通过Prometheus对Kubernetes以及部署在Kubernetes上的Pod进行监控，当Kubernetes出现异常时进行告警。

• 通过ARMS对部署在Kubernetes上的应用进行监控，包括应用之间的调用链。当应用异常时进行告警。

• 通过SLS对应用产生的日志进行监控，当日志出现异常时进行告警。

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

• 不同系统产生的告警格式不同，接入成本高。

• 不同系统间的告警接入后由于格式不统一，难以统一处理逻辑。

• 不同告警系统对于告警等级的定义不同。

• 不同告警系统对于告警自动恢复的处理方式不同。有的告警系统支持自动恢复，有的不支持。

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

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

  参数	数据类型	说明
  alertName	String	报警名称。
  alertState	String	报警状态。根据实际情况返回以下三种状态中的一种： OK：正常 ALERT：报警 INSUFFICIENT_DATA：无数据
  curValue	String	报警发生或恢复时监控项的当前值。
  dimensions	String	发生报警的对象。示例： {userId=110803419679****, instanceId=i-8psdh7l6lphbn10l****}
  expression	String	报警条件。
  groupId	String	应用分组ID。
  instanceName	String	实例名称。
  lastTime	String	报警持续时间。单位：分钟。
  metricName	String	监控项名称。关于监控项名称，请参见云服务监控项中的Metric Name。
  metricProject	String	云服务名称。metricProject与namespace相同。关于云服务名称，请参见云服务监控项。
  namespace	String	云服务命名空间。namespace与metricProject相同。关于云服务命名空间，请参见云服务监控项。
  preTriggerLevel	String	上一次触发报警的级别。取值： CRITICAL：严重 WARN：警告 INFO：信息
  productGroupName	String	应用分组名称。
  rawMetricName	String	监控项ID。关于监控项ID，请参见云服务监控项中的Metric Id。
  regionId	String	地域ID。
  regionName	String	地域名称。
  ruleId	String	触发本次报警的报警规则ID。
  timestamp	String	触发本次报警的时间戳。
  transId	String	目标规则中资源从发生报警到恢复的ID。
  triggerLevel	String	本次触发报警的级别。取值： CRITICAL：严重 WARN：警告 INFO：信息
  unit	String	监控项的单位。关于监控项ID，请参见云服务监控项中的Unit。
  userId	String	用户ID。

• Zabbix告警数据格式：

  参数	数据类型	说明
  alertName	String	报警名称。
  alertState	String	报警状态。根据实际情况返回以下三种状态中的一种： OK：正常 ALERT：报警 INSUFFICIENT_DATA：无数据
  curValue	String	报警发生或恢复时监控项的当前值。
  dimensions	String	发生报警的对象。示例： {userId=110803419679****, instanceId=i-8psdh7l6lphbn10l****}
  expression	String	报警条件。
  groupId	String	应用分组ID。
  instanceName	String	实例名称。
  lastTime	String	报警持续时间。单位：分钟。
  metricName	String	监控项名称。关于监控项名称，请参见云服务监控项中的Metric Name。
  metricProject	String	云服务名称。metricProject与namespace相同。关于云服务名称，请参见云服务监控项。
  namespace	String	云服务命名空间。namespace与metricProject相同。关于云服务命名空间，请参见云服务监控项。
  preTriggerLevel	String	上一次触发报警的级别。取值： CRITICAL：严重 WARN：警告 INFO：信息
  productGroupName	String	应用分组名称。
  rawMetricName	String	监控项ID。关于监控项ID，请参见云服务监控项中的Metric Id。
  regionId	String	地域ID。
  regionName	String	地域名称。
  ruleId	String	触发本次报警的报警规则ID。
  timestamp	String	触发本次报警的时间戳。
  transId	String	目标规则中资源从发生报警到恢复的ID。
  triggerLevel	String	本次触发报警的级别。取值： CRITICAL：严重 WARN：警告 INFO：信息
  unit	String	监控项的单位。关于监控项ID，请参见云服务监控项中的Unit。
  userId	String	用户ID。

• Nagios告警数据格式：

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

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

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

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

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

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

• 互斥原则：指避免对同一个资源使用两个或以上的标签键。例如：如果已经使用了标签键service来标识业务，就不要再使用biz或业务等类似的标签键。

• 集体详尽原则：指所有资源都必须绑定已规划的标签键及其对应的标签值。例如：某公司有3个业务，标签键是service，则应至少有3个标签值分别代表这3个业务。

• 有限值原则：指为资源只保留核心标签值，删除多余的标签值。例如：某公司共有5个业务，那么应该有且仅有这5个业务的标签，方便管理。

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

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

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

  1. 登录ARMS控制台，在左侧导航栏选择告警管理 > 事件处理流，然后单击新建处理流。

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

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

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

  某自研告警系统中所有的主机都使用固定格式进行命名，命名格式为${env}-${biz}-${app}-${group}-${index} ，需要提取其中的biz字段作为业务标签。

  配置正确的触发条件后，使用分割内容操作，将hostname根据字符'-'进行分割，分割后的内容依次填充到env、service、 app、group字段。

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

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

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

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

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

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

  

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

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

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

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

• 参数：triggerLevel

• 数据类型：String

• 本次触发报警的级别。取值：

  • CRITICAL：严重

  • WARN：警告

  • INFO：信息

  • OK：正常

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

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

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

  

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

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

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

  

  ARMS控制台配置方式截图：

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

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

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