企业官网建设流程全解析

Keep:聚合100+监控工具的开源告警管理平台

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep

Prometheus、Datadog、CloudWatch 各自独立发告警，一次故障可能同时涌入几十条，值班工程师要人工判断哪条才是根因，哪条只是连带噪音。Keep 是一个开源的 AIOps 与告警管理平台，它把各监控工具的告警汇聚到统一视图里，用去重、规则关联和自动化工作流压缩噪音、缩短响应时间。

传统做法 vs Keep：差异在哪

有一个取舍要心里有数：Keep 是架在你现有监控工具前面的一层，所有告警都要先流进它，所以它本身成为新的依赖，需要被监控；关联效果的好坏，则取决于你维护的拓扑与指纹数据是否准确。

🔍 告警管理平台的三个核心能力

指纹去重：把同源告警压成一条

先做去重。Keep 的每个提供商（provider，即一个监控工具集成）都声明了一组指纹字段（FINGERPRINT_FIELDS），告警进来时按这些字段算指纹，指纹相同的告警被聚合为一条，只更新状态和最近接收时间。比如同一个服务反复上报"数据库连接超时"，你在列表里只看到一条，但内部保留着完整的触发次数和最后时间。

在这之上还有"完全去重"模式：除忽略字段外全部相同的重复事件直接丢弃，防止坏掉探针每分钟刷屏。每个提供商都自带一套预置去重规则，你也可以自定义指纹字段。实际收益很直接：通知量降一个数量级，oncall 不用再扫视几十条同义告警。

用 CEL 规则把散落告警关联成事件

再谈关联。Keep 的规则引擎（rules engine）允许你用 CEL（通用表达式语言）写关联条件，例如"同一服务同时有 3 条以上 firing 告警时，创建一个 incident"。新告警到达后，引擎让它与所有规则做匹配，命中后按指纹创建或更新 incident，并把关联的告警挂进去。incident 是比单条告警更高一级的对象，它有一组告警列表、状态和时间线。

这意味着电话响起时，十五条告警可能已经变成"一个事件、一条告警清单"。规则是数据库里的一段文本，在线修改不用重启，具体逻辑可以看规则引擎源码。

服务拓扑：看清谁影响谁

第三个能力是拓扑。Keep 可以把你的服务间依赖关系建模成图，并在图上实时标出当前处于异常状态的节点。结合 AI 关联能力，平台会用大语言模型分析告警文本与历史模式，自动建议哪些告警应该归入同一 incident——这个过程可以全自动，也可以是半自动：AI 给出分组建议，你确认后再落库。

收益在于：故障发生后，"哪个服务是根因、哪些只是被波及"这个问题有了图可依，而不是靠值班同学对架构图的肌肉记忆。

走一条真实任务线：告警触发自动建工单

以"生产告警触发后自动建 Jira 工单"为例，仓库 examples 目录里就有现成样例，核心配置如下：

triggers: - type: alert cel: status == "firing" actions: - name: jira-action if: "not '{{ alert.ticket_id }}'" provider: type: jira config: "{{ providers.JiraCloud }}" with: summary: "{{ alert.name }} - {{ alert.description }}" enrich_alert: - key: ticket_id value: results.issue.key

这段配置在解决什么问题？关键在两处。if条件先检查告警是否已有 ticket_id，没有才去建工单；enrich_alert则把工单号回写到告警字段上。两者配合，同一个告警反复 firing 也不会重复开工单——"只执行一次"的保证不写在工单系统里，而是写在告警数据自己身上。

工作流引擎（workflow manager）的定位，相当于给你的监控栈装了一个"GitHub Actions"：任何满足条件的告警都能触发建工单、发消息、跑命令这些动作。写 YAML 有门槛的话，可以用 AI 工作流助手，用自然语言描述需求，由它生成配置草稿再人工调整。执行链路的实现见工作流管理器。

⚙️ 值得细看的两个实现细节

提供商插件架构。100 多个监控工具走同一套接口。新增一个工具时，继承 BaseProvider、声明指纹字段、实现推送和查询两个方法即可，去重、富化、入库由框架统一处理：

class BaseProvider: FINGERPRINT_FIELDS = [...] # 声明哪些字段判定"同一告警" def notify(...): ... # 处理工具推给 Keep 的告警 def query(...): ... # 主动查询工具的指标或日志

扩展点固定、新代码不动核心链路，这是集成列表能快速扩张而互不干扰的原因，基类设计细节见提供商基类。

规则求值循环。一批新告警到达时，引擎对"规则 × 告警"做遍历求值，命中即按指纹归入 incident：

for rule in rules: for event in new_events: if cel.evaluate(rule.definition, event): incident = get_or_create(calc_fingerprint(event, rule)) incident.attach(event)

这个设计朴素但务实：单条告警求值抛异常只会记日志并跳过，一条写错的规则不会阻塞整批处理；规则存数据库、在线可改。

🚀 落地建议与常见坑

• 先用 docker-compose 起后端、前端、数据库、Redis，2C4G 起步够用
• 接入顺序建议先 Prometheus 这类拉取式集成，见效最快
• 关联质量依赖指纹和拓扑数据准确性，定期复查一次
• CEL 规则写错不会报错，只记 warning，上线前留意日志

部署配置项与环境变量说明，参考仓库内的部署文档。

回到开头的痛点：告警仍然由各监控工具发出，但"翻五十条告警找根因"的活交给了去重与规则关联，"建工单、发通知"交给了工作流。Keep 承担的是值班链路中的一环——把原始告警变成少数几个可操作的事件，判断和处理仍然在你手里。

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep