真香！基于 Prometheus 的持久化存储，全是知识点？

admin 9 月 28, 2023 153 0

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 包含以下几个部分：


alert：告警规则名称，用于触发时告警标题展示


expr：告警规则定义，基于PromQL表达式


for：告警评估期，非必选，只有超过for时间系统才认定为真实有效告警。


labes：自定义标签，用于告警路由或者告警级别等方面定义


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 procedureCALL bootstrap();-- Drop the procedureDROP 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: v1kind: Servicemetadata:  name: mysql-dev  namespace: monitoringspec:  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 库呈现告警呈现。
核心呈现：告警触发总数与恢复总数统计，区间告警变化趋势图、告警级别统计、告警详情信息涉及告警名，告警开始时间、结束时间、持续时间、告警信息及其它相关标签信息等。


3 总结
本文通过对 prometheus 告警生态剖析，了解 alertmanager 告警机制，为满足历史告警查询需求提出 alertmanager+alertsnitch+mysql+grafana 告警持久化并做历史告警展现和统计方案，该方案能够满足一定生产级别需求，为 prometheus 开源生态告警持久化存储提供选择。

还不过瘾？还想了解更多从监控走向可观测性内容？GOPS 2023 · 上海站，10月26日-27日，还有知名券商带来云原生、持续测试、持续交付、DataOps、DevSecOps 等方面的精彩实践，扫码了解更多~

早鸟票9折限时优惠进行中
近期好文：
Prometheus 指标实践总结，搞定监控，注意啦~
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。





点个“在看”，一年不宕机