Prometheus 将基于告警规则生成的告警存储为时间序列，不会将 Alertmanager 的告警信息持久化存储，那么针对历史告警的检索、统计等需求就无法实现。

因此需要一种持久化机制用于存储历史告警信息，本文主要探究基于 alertmanager 告警的开源持久化方案。

1.告警触发机制

基于主机层面内存、CPU、磁盘、IO、网络等，数据层面的连接数、存活性等方面告警规则，Prometheus 按照预设周期，在已采集时序指标中通过告警规则轮询计算，达到先关门限值按照一定规则定义系统判定为一条告警，通过预设机制发送给指定接收者。

1.1 告警规则

如下为一条内存使用率告警示例：

groups:

- name: host_alert

  rules:

  - alert: 内存使用过高

    expr: 100 -(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85

    for: 5m 

    labels:

      severity: 一般

      type: 服务器

    annotations:

      summary: '{{$labels.mountpoint}} 内存使用率过高！'

      description: '{{$labels.mountpoint }} 内存使用大于85%(目前使用:{{ printf "%.2f" $value }}%)'

说明：根据实际情况，将一组相关规则的告警定义放在同一个 group 下面，同时每个 group 可定义多个 rule，每条 rule 包含以下几个部分：

1. alert：告警规则名称，用于触发时告警标题展示
2. expr：告警规则定义，基于PromQL表达式
3. for：告警评估期，非必选，只有超过for时间系统才认定为真实有效告警。
4. labes：自定义标签，用于告警路由或者告警级别等方面定义
5. annotations：描述告警的附加信息，详述告警相关信息

1.2 告警状态

如上针对内存使告警判定，如相应 expr 表达式值达到门限设定，告警从默认的 Inactive 变更为 Pending 状态，如果达到 for 等待评估时间，告警从 Pending 状态正式变更为 Firing 状态，即系统正式认定为产生一条有效告警它将按照告警配置信息将告警发送给指定接收者。

此条告警在后续轮询计算中 expr 值在门限下，则告警接触，状态重新变更为 Inactive，完成一条告警全生命周期过程。

1.3 收敛规则

1）抑制（Inhibition）

针对主机宕机、低中高级别告警定义等具有强关联性告警，为有效抑制告警风暴，减少无效告警，需要设置一定规则，当告警发生后，停止重复由此告警应发的其它告警机制。

如主机宕机告警触发后，通过抑制规则剔除进程掉线、数据库掉线等方面的关联告警，可以有效避免接收带大量与实际问题无关的告警通知信息。

2）静默（Silences）

针对特定场景如上线割接，停服等操作，屏蔽特定时间内告警，它可以根据匹配生效。

Alertmanager 接收到告警符合静默规则，它将不会发送告警通知，常用语系统维护窗口期。

3）路由（Route）

每个告警都会从顶级默认 route 进入路由树，每一个路由可以自行定义接收人和接收规则，默认情况下，告警进入到顶级 route 后会遍历所有的子节点，直到找到最深的匹配 route，并将告警发送到该 route 定义的 receiver 接收者中。

同时告警的匹配有字符串验证和正则表达式两种形式。

 route:

   group_by: ['alertname','instance','project']

   group_wait: 1m

   group_interval: 10m 

   repeat_interval: 4h

   receiver: default

   routes:

   - receiver: 'mysql'

     match_re:

       project: mysql

       severity: 紧急

   receivers:

   - name: 'whole'

     webhook_configs:

     - url: http://192.168.0.2:31102/webhook

       send_resolved: true

2. 告警持久化

技术栈：Prometheus+Alertmanager+Snitch+Grafana

开源组件alertsntich实现了一个 webhook 接口，通过接收 alertmanager 的告警并写入 MySQL 或 PG 库实现持久化存储，并通过 Grafana 可视化呈现告警统计信息。

1）持久化库环境

本案例采用MySQL 5.7进行持久化存储，需要两个初始化建表操作。

DROP PROCEDURE IF EXISTS bootstrap;
DELIMITER //
CREATE PROCEDURE bootstrap()
BEGIN
  SET @exists := (SELECT 1 FROM information_schema.tables I WHERE I.table_name = "Model" AND I.table_schema = database());
  IF @exists IS NULL THEN
    CREATE TABLE `Model` (
      `ID` enum('1') NOT NULL,
      `version` VARCHAR(20) NOT NULL,
      PRIMARY KEY (`ID`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    INSERT INTO `Model` (`version`) VALUES ("0.0.1");
  ELSE
    SIGNAL SQLSTATE '42000' SET MESSAGE_TEXT='Model Table Exists, quitting...';
  END IF;
END;
//
DELIMITER ;
-- Execute the procedure
CALL bootstrap();
-- Drop the procedure
DROP PROCEDURE bootstrap;


=================================================================


-- Create the rest of the tables


CREATE TABLE `AlertGroup` (
    `ID` INT NOT NULL AUTO_INCREMENT,
    `time` TIMESTAMP NOT NULL,
    `receiver` VARCHAR(100) NOT NULL,
    `status` VARCHAR(50) NOT NULL,
    `externalURL` TEXT NOT NULL,
    `groupKey` VARCHAR(255) NOT NULL,
    KEY `idx_time` (`time`) USING BTREE,
    KEY `idx_status_ts` (`status`, `time`) USING BTREE,
    PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `GroupLabel` (
    `ID` INT NOT NULL AUTO_INCREMENT,
    `AlertGroupID` INT NOT NULL,
    `GroupLabel` VARCHAR(100) NOT NULL,
    `Value` VARCHAR(1000) NOT NULL,
    FOREIGN KEY (AlertGroupID) REFERENCES AlertGroup (ID) ON DELETE CASCADE,
    PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

初始化表信息主要包含版本信息、告警信息、告警标签信息、告警级别信息、告警组信息等，根据实际统计需要进行关联聚合查询得到相应结果。

2）部署 alertsnitch 服务

容器环境下采用在 kubernetes 环境部署 alertsnitch 库服务

ALERTSNITCH_DSN环境配置信息为数据库连接信息，同时注意操作编码字符集等。

本实例以Nodeport形式暴露服务

apiVersion: v1

kind: Service

metadata:

  name: mysql-dev

  namespace: monitoring

spec:

  ports:

  - port: 3306

    targetPort: 3306

    protocol: TCP

    nodePort: 31102

  type: NodePort

采用 nodeport 服务暴露方式，暴露31102端口，使用集群中任何一节点时间对告警入库服务访问。

3）alertmanager配置alertsnitch接收信息

route:

      receiver: whole

      routes:

      #接收所有类型告警

      - receiver: whole

        continue: true

==================================================

    receivers:

    - name: 'whole'

      webhook_configs:

      - url: http://192.168.0.2:31102/webhook

        send_resolved: true

alertmanager 服务配置告警入库服务 alertsnitch，并重启 alertmanager 服务，实时告警信息就会通过 alertsnitch 服务推送到 MySQL 库中从而实现持久化存储。

4）可视化呈现

使用 Grafana 对接告警 MySQL 库呈现告警呈现。

核心呈现：告警触发总数与恢复总数统计，区间告警变化趋势图、告警级别统计、告警详情信息涉及告警名，告警开始时间、结束时间、持续时间、告警信息及其它相关标签信息等。