Keep 告警管理完整指南从接入到AI降噪【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep 场景切入一个真实的告警风暴凌晨 3 点你的微服务集群一分钟内涌来 200 条告警一半是同一根因的重复另一半是级联反应的下游噪音分不清谁先谁后值班的人整晚都在陪跑。这正是 Keep 告警管理一个开源 AIOps 平台要解决的问题把多源告警聚合成一个视图用工作流自动化响应用 AI 帮你把根因找出来。 开箱即用的集成生态开源告警聚合从第一天开始第一天不是写代码而是接数据源。Keep 内置 130 多个 Provider覆盖三大类监控系统Prometheus、Datadog、CloudWatch、Zabbix、通知渠道Slack、Teams、PagerDuty、数据源MySQL、BigQuery、ClickHouse。接一个新源只需三步在 Providers 页面选中卡片、填入凭据和 endpoint、点测试连接状态变绿就算完成。凭据也可以走环境变量或配置文件注入敏感部分统一交给密钥管理器加密托管不会散落成一堆明文。三步接入一个监控源多数 Provider 支持双向工作告警既可以 webhook 推到 Keep也可以由 Keep 主动去源头拉取按你的工具特性选一种即可。告警接齐之后它们会落在一个可搜索、可筛选的统一页面上Provider 集成配置界面已连接与可添加的数据源聚合解决了看什么的问题看了之后怎么办则需要一套架构来兜底。 跑起来Keep 告警管理的架构拆解与关键路径不看组件清单跟着一条请求走。浏览器打到入口后NGINX ingress 按路径分流/交给 Next.js 前端渲染页面/v2交给 FastAPI 后端跑在 gunicorn 上/websocket交给 Soketi 服务——告警列表能实时刷新、不用手动 F5靠的就是它。数据侧谁负责什么很清晰告警和运行数据默认落关系型数据库SQLite、PostgreSQL、MySQL、SQL Server 都行规模上来后告警转成文档存 Elasticsearch 换取搜索性能频率过高时Redis ARQ 队列接管异步入库。去重、工作流调度、AI 关联这些业务逻辑都发生在后端核心代码在 keep/api/130 多个 Provider 在 keep/providers/。GKE 集群中部署的 Keep 实例告警进来了下一个问题是谁来接 告警到了之后工作流怎么接把一条告警的生命周期拆开触发、富化、判断、动作。触发器决定哪条告警进这个工作流富化步骤负责补上下文比如去 Datadog 查对应服务的信息判断步骤用 CEL 表达式过滤——它是一门评估告警属性的小型表达式语言写一句severity critical就够动作步骤执行最终操作建 Jira 工单、发 Slack 消息、重启 Pod。工作流配置的核心骨架长这样workflow: id: slow-api-response triggers: - type: prometheus id: high-latency steps: - name: enrich-context provider: type: datadog # ... with 与 actions查服务上下文、建 Jira 工单、发 Slack每个工作流实例有独立执行上下文能访问告警数据、系统变量和外部资源。界面上可以创建、手动触发、查执行历史与日志整个流程也能以 YAML 形式作为代码提交进仓库跟着 CI/CD 走。工作流管理界面模板与自定义工作流看和处理都有了但告警量本身爆炸时还需要更狠的一手。⚡ 当告警太多时AI关联与拓扑定位人在告警风暴里的瓶颈不是手速是关联200 条告警里哪 30 条属于同一件事Keep 的 AI 关联Transformers Correlation用 Transformer 模型分析你自己租户的告警与事件历史——时间模式、资源依赖、服务拓扑——给任意两条告警打一个关联度评分。逻辑是一条简单因果链评分超过关联阈值默认 0.4 附近的两条告警归入同一事件未归属的告警被自动聚类成新事件模型准确率掉到阈值默认 0.6以下时它干脆不跑宁缺毋滥。降噪就靠这一步你在事件列表里看到的是 3 个事件而不是 200 条告警每个事件还挂着涉及的服务。配合 Service Topology 把服务依赖图画出来某个服务挂掉时受影响面能顺着依赖链展开不用一条条翻告警。AI 关联插件阈值配置与关联执行日志告警量超过一定规模后第一件要担心的不是 AI而是底座撑不撑得住。 规模上去了怎么撑住部署与性能压测数据可以直接查三个量级的告警总量对应不同的存储、资源和队列策略告警总量推荐存储后端/数据库资源队列与扩展策略 1万条MySQL / PostgreSQL后端 1 vCPU、2GB RAM数据库 2 vCPU、8GB不需要 Redis不需要 ES1万~10万条关系型数据库 优化索引后端 4 vCPU、8GB RAM数据库 8 vCPU、32GB仍不需要 Redis / ES 50万条Elasticsearch 存告警文档后端 8 vCPU、16GB RAM数据库 8 vCPU、32GB分片Redis 4 vCPU、8GB ARQ 队列ES 2~3 节点 8 vCPU、32GB吞吐侧同样 4 vCPU / 8GB RAM 的配置每分钟 100 条告警直接入库一批约 0.5 秒走 Redis 队列后降到约 0.3 秒工作流每分钟跑 10 个约 1 秒到每分钟 100 个约 3 秒基本线性扩展。K8s 告警平台部署的两个要点部署侧抓住两点就够给后端、前端 Pod 挂 HPA按 CPU/内存使用率自动扩缩副本数据库成为瓶颈时上读写分离或给 Elasticsearch 加节点。安全也顺手交代了认证支持 OAuth 2.0、JWT 和 API Key 三种Provider 凭据由密钥管理器K8s Secret、Vault 等加密存储访问控制走 RBAC 角色权限关键操作都有审计记录可查。事件视图拓扑关联的服务与告警️ 下一步你的接入路线图如果你现在就想跑起来三步内就能见到第一条告警起服务git clone https://gitcode.com/GitHub_Trending/kee/keep在仓库根目录用 docker compose 启动整套服务栈小规模直接 SQLite 起步接第一个源在 Providers 页面选 Prometheus填 endpoint10 分钟内你集群的告警就会出现在告警列表里建第一个工作流从模板里挑一个或写一段上面那种 YAML——告警进来自动富化后推到 Slack。彩蛋130 多个 Provider 遵循同一套接口规范你的监控工具不在列表里可以自己写一个提交给社区这也是 Keep 生态一直在变厚的原因。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep 告警管理完整指南：从接入到AI降噪
Keep 告警管理完整指南从接入到AI降噪【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep 场景切入一个真实的告警风暴凌晨 3 点你的微服务集群一分钟内涌来 200 条告警一半是同一根因的重复另一半是级联反应的下游噪音分不清谁先谁后值班的人整晚都在陪跑。这正是 Keep 告警管理一个开源 AIOps 平台要解决的问题把多源告警聚合成一个视图用工作流自动化响应用 AI 帮你把根因找出来。 开箱即用的集成生态开源告警聚合从第一天开始第一天不是写代码而是接数据源。Keep 内置 130 多个 Provider覆盖三大类监控系统Prometheus、Datadog、CloudWatch、Zabbix、通知渠道Slack、Teams、PagerDuty、数据源MySQL、BigQuery、ClickHouse。接一个新源只需三步在 Providers 页面选中卡片、填入凭据和 endpoint、点测试连接状态变绿就算完成。凭据也可以走环境变量或配置文件注入敏感部分统一交给密钥管理器加密托管不会散落成一堆明文。三步接入一个监控源多数 Provider 支持双向工作告警既可以 webhook 推到 Keep也可以由 Keep 主动去源头拉取按你的工具特性选一种即可。告警接齐之后它们会落在一个可搜索、可筛选的统一页面上Provider 集成配置界面已连接与可添加的数据源聚合解决了看什么的问题看了之后怎么办则需要一套架构来兜底。 跑起来Keep 告警管理的架构拆解与关键路径不看组件清单跟着一条请求走。浏览器打到入口后NGINX ingress 按路径分流/交给 Next.js 前端渲染页面/v2交给 FastAPI 后端跑在 gunicorn 上/websocket交给 Soketi 服务——告警列表能实时刷新、不用手动 F5靠的就是它。数据侧谁负责什么很清晰告警和运行数据默认落关系型数据库SQLite、PostgreSQL、MySQL、SQL Server 都行规模上来后告警转成文档存 Elasticsearch 换取搜索性能频率过高时Redis ARQ 队列接管异步入库。去重、工作流调度、AI 关联这些业务逻辑都发生在后端核心代码在 keep/api/130 多个 Provider 在 keep/providers/。GKE 集群中部署的 Keep 实例告警进来了下一个问题是谁来接 告警到了之后工作流怎么接把一条告警的生命周期拆开触发、富化、判断、动作。触发器决定哪条告警进这个工作流富化步骤负责补上下文比如去 Datadog 查对应服务的信息判断步骤用 CEL 表达式过滤——它是一门评估告警属性的小型表达式语言写一句severity critical就够动作步骤执行最终操作建 Jira 工单、发 Slack 消息、重启 Pod。工作流配置的核心骨架长这样workflow: id: slow-api-response triggers: - type: prometheus id: high-latency steps: - name: enrich-context provider: type: datadog # ... with 与 actions查服务上下文、建 Jira 工单、发 Slack每个工作流实例有独立执行上下文能访问告警数据、系统变量和外部资源。界面上可以创建、手动触发、查执行历史与日志整个流程也能以 YAML 形式作为代码提交进仓库跟着 CI/CD 走。工作流管理界面模板与自定义工作流看和处理都有了但告警量本身爆炸时还需要更狠的一手。⚡ 当告警太多时AI关联与拓扑定位人在告警风暴里的瓶颈不是手速是关联200 条告警里哪 30 条属于同一件事Keep 的 AI 关联Transformers Correlation用 Transformer 模型分析你自己租户的告警与事件历史——时间模式、资源依赖、服务拓扑——给任意两条告警打一个关联度评分。逻辑是一条简单因果链评分超过关联阈值默认 0.4 附近的两条告警归入同一事件未归属的告警被自动聚类成新事件模型准确率掉到阈值默认 0.6以下时它干脆不跑宁缺毋滥。降噪就靠这一步你在事件列表里看到的是 3 个事件而不是 200 条告警每个事件还挂着涉及的服务。配合 Service Topology 把服务依赖图画出来某个服务挂掉时受影响面能顺着依赖链展开不用一条条翻告警。AI 关联插件阈值配置与关联执行日志告警量超过一定规模后第一件要担心的不是 AI而是底座撑不撑得住。 规模上去了怎么撑住部署与性能压测数据可以直接查三个量级的告警总量对应不同的存储、资源和队列策略告警总量推荐存储后端/数据库资源队列与扩展策略 1万条MySQL / PostgreSQL后端 1 vCPU、2GB RAM数据库 2 vCPU、8GB不需要 Redis不需要 ES1万~10万条关系型数据库 优化索引后端 4 vCPU、8GB RAM数据库 8 vCPU、32GB仍不需要 Redis / ES 50万条Elasticsearch 存告警文档后端 8 vCPU、16GB RAM数据库 8 vCPU、32GB分片Redis 4 vCPU、8GB ARQ 队列ES 2~3 节点 8 vCPU、32GB吞吐侧同样 4 vCPU / 8GB RAM 的配置每分钟 100 条告警直接入库一批约 0.5 秒走 Redis 队列后降到约 0.3 秒工作流每分钟跑 10 个约 1 秒到每分钟 100 个约 3 秒基本线性扩展。K8s 告警平台部署的两个要点部署侧抓住两点就够给后端、前端 Pod 挂 HPA按 CPU/内存使用率自动扩缩副本数据库成为瓶颈时上读写分离或给 Elasticsearch 加节点。安全也顺手交代了认证支持 OAuth 2.0、JWT 和 API Key 三种Provider 凭据由密钥管理器K8s Secret、Vault 等加密存储访问控制走 RBAC 角色权限关键操作都有审计记录可查。事件视图拓扑关联的服务与告警️ 下一步你的接入路线图如果你现在就想跑起来三步内就能见到第一条告警起服务git clone https://gitcode.com/GitHub_Trending/kee/keep在仓库根目录用 docker compose 启动整套服务栈小规模直接 SQLite 起步接第一个源在 Providers 页面选 Prometheus填 endpoint10 分钟内你集群的告警就会出现在告警列表里建第一个工作流从模板里挑一个或写一段上面那种 YAML——告警进来自动富化后推到 Slack。彩蛋130 多个 Provider 遵循同一套接口规范你的监控工具不在列表里可以自己写一个提交给社区这也是 Keep 生态一直在变厚的原因。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考