Keep 全解析开源 AIOps 告警平台如何吞下 100 监控源【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨三点Prometheus 和 Datadog 同时弹出一百条告警值班工程师不知道先看哪一条。这就是 AIOps 告警管理要解决的问题而 Keep 这个开源平台正是为此而生它把 Prometheus、Datadog、CloudWatch 等 100 监控源统一接入再用 AI 自动关联、声明式工作流替你处理告警让你面对的是一条处理过的告警流而不是一片原始告警海洋。 能力全景Keep 替你接管了什么在拆解架构之前先看看 Keep 接过了值班流程里的哪几件事。Keep 接管了告警管理的四个环节。统一告警视图接完各个监控源之后所有告警落在同一个 Feed 里按严重度、状态、来源、负责人多维筛选排序重复告警靠指纹机制自动收敛。多源监控集成内置 100 个 Provider覆盖 Prometheus、Datadog、Zabbix 这类监控系统到 Jira、ServiceNow 这类工单系统而且是双向的——既能拉告警进来也能把告警状态推回去。工作流引擎一份声明式 YAML 就能定义告警触发后做什么从数据富化到开工单、发通知。AI 关联分析Transformer 模型自动给告警之间的相关性打分把相关的告警归成同一个事件辅助根因定位。Keep 告警 Feed多源告警统一进一张表支持 CEL 表达式过滤每一列都能排序 一条告警的完整旅程跟着一条从 Datadog 发出的告警走一遍它在 Keep 里的完整旅程。当这条告警到达 KeepKeep 用 Provider 机制接收告警。Provider 本质上是一套插件系统每个监控工具对应一个独立的 Python 模块实现统一的接口源码见 keep/providers/100 多个插件就排在那里。接入 Datadog 只需在配置里填上 API Key接入 Prometheus 则可以直接开启拉取模式让 Keep 定期去取。这条告警到达后先经过去重和富化Keep 根据告警字段生成指纹同一条告警第三次到达时不会当作新告警而是在原记录上更新状态和时间。随后它出现在统一视图中。你在 Feed 顶部的搜索框输入severity critical——这是一句 CELCommon Expression Language表达式同样可以写source.contains(kibana)或者组合时间窗、标签、严重度。这套表达式语言在工作流、规则引擎、视图筛选里通用一处学会处处可用。工作流触发、AI 关联与最终落地告警落库之后工作流引擎开始工作。一条工作流由三部分构成triggers 定义何时启动steps 做可选的数据处理actions 执行最终业务动作。仓库里的真实工作流长这样workflow: id: jira-create-ticket-on-alert triggers: - type: alert cel: severity critical steps: - name: enrich-context provider: type: prometheus with: query: up{jobpayments} actions: - name: create-ticket provider: type: jira config: {{ providers.JiraCloud }} with: summary: {{ alert.name }} - {{ alert.description }} issue_type: Bugtriggers 用 CEL 表达式判断critical 级告警一到就触发steps 顺手查一下支付服务的存活状态把结果富化进告警actions 创建 Jira 工单并把 ticket_id 写回告警。执行逻辑在 keep/workflowmanager/ 里全程不需要写代码改 YAML 保存即可也可以在界面里点Create a workflow从零开始配。工作流管理界面支持手动触发与告警触发内置 ServiceNow 开工单、自动修复 Kubernetes Pod 等模板工作流之外还有一层判断这条告警和别的告警相关吗这是 Keep 的 AI 关联分析告警关联分析出手的地方。Transformer 模型用每个租户自己的告警和事件数据训练给新告警与现有事件的相关性打分。分数超过关联阈值默认 0.4时新告警自动挂到对应事件下低于模型精度阈值默认 0.6时算法干脆不上线。执行日志会直接告诉你哪两条告警被归到了哪个事件比如HighCPUConsumption和DatabaseConnectionError同属一个事件。Transformers Correlation 配置页模型精度阈值、关联阈值、训练轮数都是可调滑块关联还可以结合拓扑。Keep 会画出基础设施拓扑数据库连接告警触发时系统沿拓扑找出受影响的下游服务把散落的连接超时高延迟网络抖动聚成一个事件呈现完整的故障传播链根因定位不再靠人肉翻聊天记录。拓扑视图展示受影响服务Kafka、Google Ads 等以及事件关联的提交记录最后处理完的告警被推给 Slack、PagerDuty 或 Jira 工单。值班工程师看到的是一条带上下文的事件而不是一百条零散通知。 架构拆解四个组件如何各司其职Keep 的后端拆成四个组件各自独立容器运行。FastAPI 后端gunicorn承载全部业务逻辑和 API 端点Next.js 前端承载你看到的所有页面Soketi WebSocket 服务负责实时推送——新告警出现在 Feed 里不用刷新页面持久化存储层支持 SQLite、PostgreSQL、MySQL、SQL Server大规模时再挂 Elasticsearch 和 Redis。这四者组合起来就是一套典型的 FastAPI 微服务架构接口、界面、实时通道、存储互不纠缠。组件之间怎么通信Kubernetes 部署里只有一个 NGINX Ingress 控制器负责路由/到前端/v2到后端 API/websocket到 Soketi。每个组件都能独立伸缩Helm chart 给前端、后端、WebSocket 各备了 HorizontalPodAutoscaler——页面卡就加前端副本告警洪峰就加后端副本互不影响。这套架构撑得住多大流量官方压测数据可以参考4 vCPU 8 GB 的后端处理 100 条/分钟的告警耗时约 0.5 秒挂上 Redis 队列后同配置降到 0.3 秒吞吐提升约 40%。工作流执行 10 条/分钟约 1 秒100 条/分钟约 3 秒接近线性。告警存量超过 10 万时数据库建议升到 8 vCPU 32 GB。 落地指南从开发环境到生产集群部署规模对号入座即可官方按告警存量分了三档。告警存量存储选型队列后端规格 1 万MySQL 或 PostgreSQL开发期可用 SQLite不需要1 vCPU / 2 GB1 万 ~ 10 万关系库扩容8 vCPU / 32 GB优化索引不需要4 vCPU / 8 GB 10 万Elasticsearch2~3 节点按文档存告警Redis ARQ摄入 1000 条/分钟时必开8 vCPU / 16 GB第一档用 docker-compose 或单集群 Kubernetes 部署就够了第二档的重心在数据库调优MySQL 场景里加 innodb_buffer_pool_size 是最常见操作第三档必须上 Elasticsearch并用 Redis ARQ 把告警接收与处理解耦——官方建议是摄入速率超过 1000 条/分钟、或感觉 API 成了瓶颈时就该开队列了。安全能力是内置的不用单独搭。认证支持 OAuth 2.0、JWT 和 API Key 三种Provider 凭据这类敏感数据走 secret manager 加密存储可对接 Vault 等企业级密钥服务权限按 RBAC 模型管理你给每个角色分配只读、确认告警、执行工作流等粒度告警创建、状态变更、工作流执行这些关键操作都会落进审计日志。 接下来Keep 正在走向哪里路线图可以概括为三件事预测性告警、自愈工作流、统一可观测性。预测性告警是基于历史数据建模在故障真正发生前发出预警自愈则让工作流不止于开工单而是直接执行修复动作——官方模板库里已经躺着自动修复 Kubernetes Pod这样的模板一键把不健康 Pod 恢复统一可观测性要把日志、指标、追踪拉进 Keep 一起分析让告警关联不再只依赖字段相似度。回到凌晨三点那个场景。Keep 部署之后你的电话依旧会响但打开电脑时只看到一个事件关联打分、受影响的服务链、已创建的工单、已发出的通知全都就位。你要做的只是看着那个事件开始处理。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考