Keep 告警平台优化指南：万级到五十万告警的三档配置

Keep 告警平台优化指南万级到五十万告警的三档配置【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep告警一小时涌进几百条Keep 告警列表刷个五秒搜索框一点就转圈——问题多半不在你部署错了而在规格和配置没跟上告警量。Keep 本身把调优开关都备齐了只是散落在环境变量和部署文件里没人给你串起来。这篇文章只做一件事把 Keep 从页面转圈、入库掉线调成查询秒开、入库不丢、工作流按时跑全程照抄表格即可。先定档、再抄方、后查症。图 1Keep 优化后的告警列表页来自仓库 docs/images/ 目录定档先看告警量你的告警流属于哪一档Keep 的资源消耗几乎只由三个数决定累计告警总数、入库速率、触发的工作流数量。定档规则很简单——两个数同时达标才算低档任一超标就升一档。档位累计告警总数入库速率典型场景档 1 试用档1 万以内每天几百条单服务试用、PoC2 vCPU 小机器档 2 生产档1 万 ~ 10 万每天几千条多服务生产环境独立数据库档 3 大流量档10 万以上每天 5000 条以上全公司告警汇聚中心 两分钟自测我现在是哪一档看存量打开告警列表页看总数或直接查数据库告警表行数落在哪个区间就是哪一档的底。看速率翻最近一小时的告警算峰值每分钟进多少条持续超过 1000 条/分钟直接进档 3 讨论。看工作流每条告警平均触发几个工作流。工作流比告警还多的团队按高一档配因为执行开销全在后端。定档规则存量和速率取高的一档。比如存量 5 万但日均 3000 条按档 2 配不能按档 1 省资源。 前置依赖Docker Compose 环境可用、MySQL 或 PostgreSQL 就绪即可全部配置走环境变量不改一行代码。仓库未克隆的话执行git clone https://gitcode.com/GitHub_Trending/kee/keepcompose 文件和部署文档都在里面。三档配置参数表照抄即可上手三档共用一个入口docker-compose里 backend 服务的environment段。改完重启 backend 容器生效参数名以下表为准与 配置文档 一一对应。档 1 试用档参数表目标2 vCPU 小机器上页面秒开位置参数取值数据库引擎MySQL 或 PostgreSQL别用 sqlite 存生产数据数据库规格2 vCPU / 8 GB后端容器规格1 vCPU / 2 GB后端环境变量LOG_LEVELINFO默认值保持后端环境变量DATABASE_POOL_SIZE5默认值保持后端环境变量DATABASE_MAX_OVERFLOW10默认值保持后端环境变量KEEP_STORE_RAW_ALERTSfalse默认不存原始告警载荷后端环境变量WATCHER_LAPSED_TIME60秒告警复查间隔默认值为什么这样设1 万条以内告警瓶颈根本不在 Keep 而在数据库引擎sqlite 扛不住并发写入换 MySQL/PostgreSQL 是这一档唯一值得动的地方。其余参数保持默认就是最优解——KEEP_STORE_RAW_ALERTS关掉能省掉每份原始 JSON 的落盘换来告警详情里少了原始字段这一条代价试用阶段完全感知不到。档 2 生产档参数表目标10 万告警内查询和入库都不掉链子位置参数取值数据库规格8 vCPU / 32 GB数据库缓冲池MySQLinnodb_buffer_pool_size/ PGshared_buffers数据库容器内存的 50% ~ 70%后端容器规格4 vCPU / 8 GB后端环境变量DATABASE_POOL_SIZE20后端环境变量DATABASE_MAX_OVERFLOW30后端环境变量KEEP_WORKERS4后端环境变量LOG_LEVELWARNING后端环境变量KEEP_STORE_RAW_ALERTSfalse为什么这样设告警表过 1 万行后查询时间被数据库 I/O 主导把缓冲池喂到内存的 50%~70%热数据全在内存里查询延迟直接降一个量级代价只是数据库容器要多占内存。DATABASE_POOL_SIZE从默认 5 提到 20是允许并发打满数据库的连接数翻四倍峰值入库时不再排队KEEP_WORKERS提到 4 让 API 进程并行翻倍换掉告警风暴时页面集体转圈。LOG_LEVEL降档到WARNING省掉大量日志写盘开销排查问题那天临时调回DEBUG再降回来即可。图 2Keep 工作流管理页工作流数量多时后端执行开销是升档依据来自仓库 docs/images/ 目录档 3 大流量档参数表目标50 万告警、千条级/分钟入库也不崩位置参数取值后端容器规格8 vCPU / 16 GBRedis规格4 vCPU / 8 GBElasticsearch规格8 vCPU / 32 GB2 ~ 3 节点数据库规格8 vCPU / 32 GB后端环境变量REDIStrue入库走 ARQ 队列后端环境变量ELASTIC_ENABLEDtrue后端环境变量ELASTIC_HOSTS你的 ES 集群地址后端环境变量KEEP_WORKERS4起后端环境变量KEEP_USE_LIMITERtrue后端环境变量KEEP_LIMIT_CONCURRENCY1000/minute默认100/minute后端环境变量ARQ_KEEP_RESULT3600秒默认值为什么这样设10 万条以后关系库的搜索已经强弩之末把告警以文档形式落进 Elasticsearch查询速度回到毫秒级代价是多一个组件要运维。REDIStrue之后告警入库从API 进程同步干活变成丢进队列、ARQ 工人慢慢消化仓库的 启动脚本 会自动把 ARQ 工人和 API 进程拆成两组 gunicorn 分别跑——风暴进来 API 不塌代价是告警从入库到列表可见多了一跳队列延迟通常百毫秒级。开启限流并把阈值从默认的每分钟 100 提到 1000是防止某个接入方脚本失控时把整条管道打挂正常流量根本碰不到这条线。掉帧查不掉的病症状速查表参数抄完还不对劲按从上到下的顺序对照这张表多数情况第一行就命中症状可能原因对应操作告警列表翻页、搜索变慢数据量超出关系库能力开ELASTIC_ENABLEDtrueELASTIC_HOSTS指向集群风暴时 API 500、告警积压单进程消化不过来REDIStrue走 ARQ 队列KEEP_WORKERS加到 4 以上数据库报连接超时、连接数打满连接池太小DATABASE_POOL_SIZE提 20、DATABASE_MAX_OVERFLOW提 30磁盘越涨越快原始告警载荷全量落库确认KEEP_STORE_RAW_ALERTSfalse并清理过期告警告警接口返回 429限流阈值低于真实流量KEEP_LIMIT_CONCURRENCY调大如1000/minute工作流不按时触发调度器被关或复查窗口过短确认SCHEDULERtrueWATCHER_LAPSED_TIME保持 60日志刷爆磁盘、启动变慢日志级别停在了 DEBUGLOG_LEVEL调回WARNINGAI 类任务超时、结果丢失队列作业过期太早ARQ_EXPIRES与ARQ_KEEP_RESULT都提到3600⚠️ 每次只改一个参数并重启 backend 容器验证批量改参是排障大忌改坏了你不知道是哪个的锅。进阶选读可跳过官方规格表和按操作类型的实测耗时都写在 压测文档 里每 100 条告警摘要约 0.5 秒这类数字可以直接拿来对表验收。完整环境变量清单见 配置文档上表每一项都能在对应小节找到出处。大流量部署不用自己拼 compose仓库自带 docker-compose-with-arq.ymlRedis ARQ 队列含 worker 端口与超时默认值和 elk/docker-compose-elk.ymlElasticsearch Kibana Filebeat直接 extends 现有 compose 即可。Kubernetes 部署的扩容策略和架构图在 docs/deployment/kubernetes/ 目录下Helm 之外手动写 Deployment 也能照抄。定档、抄方、查症三件事做完Keep 的性能问题九成可以清零。环境变量对版本敏感新版本可能改默认值或加新开关升级前先翻一眼发版说明再重启。仍跑不满的话带上你的档位、告警速率和整套参数表去官方社区问别人能一次帮你定位到具体哪个开关。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考