企业官网建设流程全解析

Keep 告警管理指南：一个入口完成告警聚合与根因定位

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

Keep 是一个开源的 AIOps 告警管理平台：把 Prometheus、Datadog、CloudWatch 等上百个监控工具的告警汇聚到一个入口，再做去重、关联与根因定位，最后用工作流自动执行处理动作。适合中小团队的 SRE 和运维，也适合想给现有 Prometheus 体系加一层聚合与自动化的工程师。

谁需要它

• 告警同时来自好几个监控工具，群里刷屏却分不清哪条是主因
• 同一个告警从多台实例各报一遍，通知被重复内容淹没
• 排查故障时要来回切面板，手工拼出"谁依赖谁、谁先挂的"

核心能力：告警从接收到闭环

收得全：多监控源怎么一个入口全接进来

Keep 的告警聚合靠 providers 体系完成：每个监控工具对应一个 provider，既能主动轮询拉取告警，也能接收对方的 webhook 推送。Prometheus、Datadog、CloudWatch、Sentry 等上百种数据源都走同一套配置界面和 API，新接入的源和老源在同一个列表里查询、过滤。实现上每个工具都是 providers 模块 下的一个独立子包，通过统一的基类接口注册，所以数据源可以按需叠加，互不影响。

理得清：关联与根因定位是怎么做到的

告警进入 Keep 后，先经过去重引擎处理：按指纹字段把同一告警的多实例合并成一条，避免"30 台主机同一告警"刷 30 遍。规则引擎再按你定义的条件——比如"severity 为 critical 且来源是 Prometheus"——把多条相关告警聚合成一个 incident 候选，incident 名称还能用{{ alert.labels.host }}这类模板变量动态生成，自动汇总涉及的主机、服务。根因定位因此从"翻聊天记录"变成"看一个 incident 下的告警链"，规则逻辑由 rulesengine 模块 执行。

看得见：服务拓扑图怎么看上下游

服务拓扑把各组件及它们之间的依赖关系画成节点和连线，异常节点会直接标在图上。它接入了 Datadog、ArgoCD、Cilium、Grafana 等数据源，依赖关系来自真实集成而不是手工维护的静态图，所以服务变更之后视图仍然可信。定位时先看上游找根因、再看下游评估影响面，不用再去翻文档或注册表。

动得快：自然语言写告警自动化工作流

Keep 的 AI 工作流助手用对话方式生成工作流 YAML：你用自然语言描述"告警出现时做某某事"，助手给出配置草稿，确认后才写入。底层工作流引擎由触发器、步骤和动作组成，触发方式支持告警条件、定时和手动，每个步骤可调用 providers 里的工具完成查询、建单、发通知等动作。仓库的 examples/workflows/ 目录里有 100 多个现成样例，照着改通常比从零写更快。

跑起来：5 分钟跑起 Keep

仓库自带 docker-compose.yml，默认包含 keep-frontend、keep-backend、keep-websocket-server 三个服务，另有带grafana的 profile 可以直接把 Prometheus、Grafana 拉起来做演示数据源。克隆后一条命令启动：

git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker-compose up -d

这样起的是最简配置：免认证、共享 state 目录持久化，本地浏览器打开前端页面即可用，不需要先准备任何外部依赖。

第一个监控源怎么接：以 Prometheus 为例，在 Providers 页面添加一个 Prometheus provider 只需填 server 地址（可选用户名密码），Keep 就会开始拉取告警；更推荐在 Alertmanager 里加一个 webhook 指向 Keep 的接收端点，告警产生即推送，不靠轮询：

receivers: - name: "keep" webhook_configs: - url: 'KEEP_BACKEND_URL/alerts/event/prometheus' send_resolved: true http_config: basic_auth: username: api_key password: {你的API密钥}

webhook 方式省掉了轮询间隔，send_resolved还会把恢复事件一并同步过来，告警的开启和关闭状态在 Keep 里才闭环。

接上数据源后，写第一条告警自动化工作流。下面这份从 alert 触发、带条件过滤、最后发 Slack 通知的写法与官方示例一致：

workflow: id: payment-error-alert description: 支付接口错误率告警通知 triggers: - type: alert filters: - key: name value: "PaymentErrorRateHigh" actions: - name: notify provider: type: slack config: "{{ providers.slack-prod }}" with: message: "支付接口告警: {{ alert.name }}"

过滤条件决定了哪些告警会触发这条流程，其余告警不受影响——这正是工作流比"告警群广播"好用的地方：不同来源可以走不同的处理路径。

进阶提示

• 想接一个新的监控源：参照 providers 模块 里任意一个子包实现标准 provider 接口即可，认证配置字段由接口声明，界面自动生成
• 工作流的条件判断支持 CEL 表达式，可以写多条件组合；步骤失败可配置重试，批量处理用 foreach 循环
• 噪音治理先调去重和关联规则再动手删告警，指纹字段选错是重复通知的常见原因，规则细节见 官方文档
• 部署路径：开发环境单实例 Docker Compose 起步，生产再迁移到 Kubernetes，多副本部署并开启认证与 SSO
• Keep 自身暴露了 Prometheus 格式的监控指标，可以把 Keep 接进你现有的 Prometheus + Grafana 监控栈做自监控

写在最后

Keep 把告警接入、去重聚合、拓扑关联、自动化工作流放进一个开源项目里，docker-compose 一条命令就能验证完整链路。建议的第一步很小：先用上面的 webhook 配置，把 Prometheus Alertmanager 的一条测试告警推到 Keep，跑通"收得到、理得清"之后，再接入第二个监控源和第一条工作流。

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