ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

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

Keep 告警管理指南:一个入口完成告警聚合与根因定位 Keep 告警管理指南一个入口完成告警聚合与根因定位【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepKeep 是一个开源的 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多副本部署并开启认证与 SSOKeep 自身暴露了 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进