尧图网站建设 
Keep 告警平台调优指南一张总参数表从跑起来到大促不崩的三个目标【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨三点监控端一口气打进来 300 条告警Keep 的告警页转了十几秒才出数据工作流还卡了一半没跑。第一反应是代码不行多半不是。卡住你的通常是三个东西后端 worker 数、数据库连接池、有没有把重活挪进队列。这篇按 Keep开源 AIOps 与告警管理平台的真实部署链路给你三个可验证的结果先跑起来、高峰不崩、百万级还能查。参数都收在一张总表里直接抄。① 给机器建档先量四行再谈调参调参之前先给机器做个体检。Keep 的重活不在前端在后端 Python worker 和数据库这两处所以体检卡只记四行。体检项怎么查记什么CPU 物理核服务器执行nproc看核心一栏别看逻辑核物理核数内存free -h看 total8GB / 16GB / 32GB 各是哪一档存储lsblk看磁盘类型数据库盘是 SSD 还是机械盘部署形态单台 Docker 还是 Kubernetes 多副本单机单机调参集群另算副本数定档规则一句话核心数 × 内存同时达标才算高配。2 核 8GB 按轻量建档4 核 16GB 按中量建档8 核 32GB 以上按大量建档。8 核机器配 8GB 内存只能按轻量上限走因为 Keep 的数据库才是吃内存的大户。② 先把地基打平五件事没做完调参白调这些前置项散在仓库里这里统一收口成一张清单。全部勾完再往下走。拉代码git clone https://gitcode.com/GitHub_Trending/kee/keep用最新版旧版参数名可能对不上起服务仓库根目录docker compose up -d确认 3000前端、8080后端、6001WebSocket三个端口都通数据库默认落在sqlite:////state/db.sqlite3能跑但扛不住量生产指向 MySQL 或 PostgreSQLDATABASE_CONNECTION_STRING持久化./state目录挂卷保存数据库和密钥都在里面容器一删全丢认证AUTH_TYPE默认 NOAUTH生产环境至少改成 DB 认证并换掉默认账号密码看一眼 docker-compose.yml 和 docker-compose-with-arq.yml知道你现在起的是哪套后面抄表才抄得对③ 三个目标三种药先想清楚你在赌什么不按机器高低配分按你要的结果分。每个目标先说思路参数统一放第④节的总表。目标一先跑起来——第一条告警进来列表能看到工作流能触发。赌的是默认值够用放弃的是吞吐量。单机 SQLite 级别的部署数据量上去之后查询会越来越慢这是拿未来的流畅换今天的一分钟。适合先验证流程、确认告警源接得对。目标二高峰不崩——每天几千到几万条告警页面响应不塌工作流不排队。赌的是把重活搬出 API 进程告警消费交给 Redis ARQ 队列数据库内存给够。放弃的是部署简单——多一个 Redis 容器多一套队列要盯着。这是多数生产部署该有的样子官方压测口径里 10,000 到 100,000 条总量的建议规格就落在这档。目标三百万级还能查——告警总量超过 10 万搜索、审计、跨时间段取数都要快。赌的是把告警存成文档扔给 Elasticsearch 检索。放弃的是运维复杂度一个额外的集群、索引要维护、迁移不是关个开关就完事。总量没过 5 万条别碰它关系库还撑得住提前引入纯属自找麻烦。④ 抄这张总表三个目标一行一个参数三列对应三个目标从下往上抄你自己的那一列。数值都是环境变量或容器参数改完重启后端生效。参数目标一先跑起来目标二高峰不崩目标三百万级还能查后端容器规格1 vCPU / 2GB4 vCPU / 8GB8 vCPU / 16GBgunicorn worker 数--workers24默认值物理核数8 核给 8KEEP_EVENT_WORKERS事件处理线程池5默认值1020DATABASE_POOL_SIZE连接池5默认值1020DATABASE_MAX_OVERFLOW池外溢出10默认值2040数据库实例规格2 vCPU / 8GB8 vCPU / 32GB8 vCPU / 32GB 索引优化REDIS队列开关falsetruetrueARQ_EXPIRES任务过期秒数3600默认值1800600ELASTIC_ENABLEDfalsefalsetrueKEEP_USE_LIMITERKEEP_LIMIT_CONCURRENCYfalse默认关true100/mintrue按实测告警峰值上浮为什么这么设分目标说目标一全部走默认只把 worker 数降到 2因为 2 核机器上 4 个 worker 抢核反而互相拖慢。这一档的意义是确认链路通不是为了快。目标二worker 拉回 4KEEP_EVENT_WORKERS从 5 提到 10让同一批告警能两条线程并行处理而不是排成一列。开 Redis 队列是把收告警和处理告警拆开——API 收到就丢进队列立刻返回处理慢也不会把页面拖死ARQ_EXPIRES收到 1800 是为了让烂掉的旧任务更快出清不占队列。连接池 5 → 10因为页面请求和消费任务会同时占池默认值在高峰期不够分。限流打开防某一个 provider 风暴把入口打穿。目标三连接池 20 溢出 40支撑 8 个 worker 各自要连接KEEP_EVENT_WORKERS到 20处理线程跟 worker 数大致 1:1ARQ_EXPIRES压到 600百万级队列里过期的僵尸任务必须快速出局。上 Elasticsearch 换查询路径关系库按行扫ES 按倒排索引查总量一大差距是数量级的。规格数字不是拍的对齐官方压测口径原始表格在 docs/deployment/stress-testing.mdx环境变量全集在 docs/deployment/configuration.mdxworker 默认值 4 写死在 docker/Dockerfile.api 的启动命令里。⚠️ 一次只改一个参数重启后端验证再改下一个。两个一起改出了效果你分不清是谁的功劳出了问题也分不清回退哪个。⑤ 翻车急救从上往下问问中哪条走哪条排障别撒网按下面的判断句从上往下对问中一条执行那条的第一步动作。问一告警页打不开或 500最可能原因数据库连接池被占满请求排队到超时。 第一步DATABASE_POOL_SIZE从 5 提到 10重启后端再压一轮看是否缓解。问二告警都进来了工作流就是不动最可能原因消费线程池太小或者队列 worker 没起来。 第一步确认 ARQ worker 容器在跑且日志正常看keep-arq-redis连接然后KEEP_EVENT_WORKERS从 5 提到 10。问三只有某个 provider 的告警明显慢最可能原因入口被限流或该 provider 的拉取节奏慢。 第一步查KEEP_USE_LIMITER是否开着开了就临时把KEEP_LIMIT_CONCURRENCY从 100/min 放宽到 300/min 试一天看是不是限流卡的你。问四总量一大搜索和导出就卡最可能原因还在用关系库做全文检索行扫描扛不住。 第一步这是迁移不是开关——评估总量是否过 5 万条过了再按 elk/docker-compose-elk.yml 的路子接 ES设ELASTIC_ENABLEDtrue加对应连接变量。问五内存只涨不降最可能原因原始告警全量落库或 DEBUG 日志在刷。 第一步确认KEEP_STORE_RAW_ALERTSfalse、LOG_LEVELINFO重启后观察 24 小时内存曲线。问六跑得越久越慢最可能原因数据库还在机械盘上SQLite 的写放大在机械盘上是灾难。 第一步把数据库盘迁到 SSD这一条的收益通常比调任何参数都大。⑥ 选读与收尾可跳过的深水区可跳过再往深里走的三件事拆 API 与消费worker 多到一台机器塞不下时把 API 服务和 ARQ worker 拆成两组进程各自扩容官方压测文档把这列为首要微调项见 docs/deployment/stress-testing.mdx 的 Fine Tuning 一节。限流范围KEEP_USE_LIMITER只作用于告警入口的 POST 端点不是全站限流放宽前先看 docs/deployment/configuration.mdx 里的适用范围说明。观测docker compose -f docker-compose-with-otel.yaml up挂上 OpenTelemetry调参之前先看 trace哪个环节慢一查一个准。最后两句。Keep 迭代快环境变量会加会改你抄的这张表半年后可能有一格对不上升级前翻一遍 CHANGELOG.md 和配置文档。去社区提问时带上三样东西你的体检卡第①节那四行、你抄的是哪一列、实际卡住的症状一句话。信息齐了别人才能一次把你定位到位。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep 告警平台调优指南：一张总参数表，从跑起来到大促不崩的三个目标
Keep 告警平台调优指南一张总参数表从跑起来到大促不崩的三个目标【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep凌晨三点监控端一口气打进来 300 条告警Keep 的告警页转了十几秒才出数据工作流还卡了一半没跑。第一反应是代码不行多半不是。卡住你的通常是三个东西后端 worker 数、数据库连接池、有没有把重活挪进队列。这篇按 Keep开源 AIOps 与告警管理平台的真实部署链路给你三个可验证的结果先跑起来、高峰不崩、百万级还能查。参数都收在一张总表里直接抄。① 给机器建档先量四行再谈调参调参之前先给机器做个体检。Keep 的重活不在前端在后端 Python worker 和数据库这两处所以体检卡只记四行。体检项怎么查记什么CPU 物理核服务器执行nproc看核心一栏别看逻辑核物理核数内存free -h看 total8GB / 16GB / 32GB 各是哪一档存储lsblk看磁盘类型数据库盘是 SSD 还是机械盘部署形态单台 Docker 还是 Kubernetes 多副本单机单机调参集群另算副本数定档规则一句话核心数 × 内存同时达标才算高配。2 核 8GB 按轻量建档4 核 16GB 按中量建档8 核 32GB 以上按大量建档。8 核机器配 8GB 内存只能按轻量上限走因为 Keep 的数据库才是吃内存的大户。② 先把地基打平五件事没做完调参白调这些前置项散在仓库里这里统一收口成一张清单。全部勾完再往下走。拉代码git clone https://gitcode.com/GitHub_Trending/kee/keep用最新版旧版参数名可能对不上起服务仓库根目录docker compose up -d确认 3000前端、8080后端、6001WebSocket三个端口都通数据库默认落在sqlite:////state/db.sqlite3能跑但扛不住量生产指向 MySQL 或 PostgreSQLDATABASE_CONNECTION_STRING持久化./state目录挂卷保存数据库和密钥都在里面容器一删全丢认证AUTH_TYPE默认 NOAUTH生产环境至少改成 DB 认证并换掉默认账号密码看一眼 docker-compose.yml 和 docker-compose-with-arq.yml知道你现在起的是哪套后面抄表才抄得对③ 三个目标三种药先想清楚你在赌什么不按机器高低配分按你要的结果分。每个目标先说思路参数统一放第④节的总表。目标一先跑起来——第一条告警进来列表能看到工作流能触发。赌的是默认值够用放弃的是吞吐量。单机 SQLite 级别的部署数据量上去之后查询会越来越慢这是拿未来的流畅换今天的一分钟。适合先验证流程、确认告警源接得对。目标二高峰不崩——每天几千到几万条告警页面响应不塌工作流不排队。赌的是把重活搬出 API 进程告警消费交给 Redis ARQ 队列数据库内存给够。放弃的是部署简单——多一个 Redis 容器多一套队列要盯着。这是多数生产部署该有的样子官方压测口径里 10,000 到 100,000 条总量的建议规格就落在这档。目标三百万级还能查——告警总量超过 10 万搜索、审计、跨时间段取数都要快。赌的是把告警存成文档扔给 Elasticsearch 检索。放弃的是运维复杂度一个额外的集群、索引要维护、迁移不是关个开关就完事。总量没过 5 万条别碰它关系库还撑得住提前引入纯属自找麻烦。④ 抄这张总表三个目标一行一个参数三列对应三个目标从下往上抄你自己的那一列。数值都是环境变量或容器参数改完重启后端生效。参数目标一先跑起来目标二高峰不崩目标三百万级还能查后端容器规格1 vCPU / 2GB4 vCPU / 8GB8 vCPU / 16GBgunicorn worker 数--workers24默认值物理核数8 核给 8KEEP_EVENT_WORKERS事件处理线程池5默认值1020DATABASE_POOL_SIZE连接池5默认值1020DATABASE_MAX_OVERFLOW池外溢出10默认值2040数据库实例规格2 vCPU / 8GB8 vCPU / 32GB8 vCPU / 32GB 索引优化REDIS队列开关falsetruetrueARQ_EXPIRES任务过期秒数3600默认值1800600ELASTIC_ENABLEDfalsefalsetrueKEEP_USE_LIMITERKEEP_LIMIT_CONCURRENCYfalse默认关true100/mintrue按实测告警峰值上浮为什么这么设分目标说目标一全部走默认只把 worker 数降到 2因为 2 核机器上 4 个 worker 抢核反而互相拖慢。这一档的意义是确认链路通不是为了快。目标二worker 拉回 4KEEP_EVENT_WORKERS从 5 提到 10让同一批告警能两条线程并行处理而不是排成一列。开 Redis 队列是把收告警和处理告警拆开——API 收到就丢进队列立刻返回处理慢也不会把页面拖死ARQ_EXPIRES收到 1800 是为了让烂掉的旧任务更快出清不占队列。连接池 5 → 10因为页面请求和消费任务会同时占池默认值在高峰期不够分。限流打开防某一个 provider 风暴把入口打穿。目标三连接池 20 溢出 40支撑 8 个 worker 各自要连接KEEP_EVENT_WORKERS到 20处理线程跟 worker 数大致 1:1ARQ_EXPIRES压到 600百万级队列里过期的僵尸任务必须快速出局。上 Elasticsearch 换查询路径关系库按行扫ES 按倒排索引查总量一大差距是数量级的。规格数字不是拍的对齐官方压测口径原始表格在 docs/deployment/stress-testing.mdx环境变量全集在 docs/deployment/configuration.mdxworker 默认值 4 写死在 docker/Dockerfile.api 的启动命令里。⚠️ 一次只改一个参数重启后端验证再改下一个。两个一起改出了效果你分不清是谁的功劳出了问题也分不清回退哪个。⑤ 翻车急救从上往下问问中哪条走哪条排障别撒网按下面的判断句从上往下对问中一条执行那条的第一步动作。问一告警页打不开或 500最可能原因数据库连接池被占满请求排队到超时。 第一步DATABASE_POOL_SIZE从 5 提到 10重启后端再压一轮看是否缓解。问二告警都进来了工作流就是不动最可能原因消费线程池太小或者队列 worker 没起来。 第一步确认 ARQ worker 容器在跑且日志正常看keep-arq-redis连接然后KEEP_EVENT_WORKERS从 5 提到 10。问三只有某个 provider 的告警明显慢最可能原因入口被限流或该 provider 的拉取节奏慢。 第一步查KEEP_USE_LIMITER是否开着开了就临时把KEEP_LIMIT_CONCURRENCY从 100/min 放宽到 300/min 试一天看是不是限流卡的你。问四总量一大搜索和导出就卡最可能原因还在用关系库做全文检索行扫描扛不住。 第一步这是迁移不是开关——评估总量是否过 5 万条过了再按 elk/docker-compose-elk.yml 的路子接 ES设ELASTIC_ENABLEDtrue加对应连接变量。问五内存只涨不降最可能原因原始告警全量落库或 DEBUG 日志在刷。 第一步确认KEEP_STORE_RAW_ALERTSfalse、LOG_LEVELINFO重启后观察 24 小时内存曲线。问六跑得越久越慢最可能原因数据库还在机械盘上SQLite 的写放大在机械盘上是灾难。 第一步把数据库盘迁到 SSD这一条的收益通常比调任何参数都大。⑥ 选读与收尾可跳过的深水区可跳过再往深里走的三件事拆 API 与消费worker 多到一台机器塞不下时把 API 服务和 ARQ worker 拆成两组进程各自扩容官方压测文档把这列为首要微调项见 docs/deployment/stress-testing.mdx 的 Fine Tuning 一节。限流范围KEEP_USE_LIMITER只作用于告警入口的 POST 端点不是全站限流放宽前先看 docs/deployment/configuration.mdx 里的适用范围说明。观测docker compose -f docker-compose-with-otel.yaml up挂上 OpenTelemetry调参之前先看 trace哪个环节慢一查一个准。最后两句。Keep 迭代快环境变量会加会改你抄的这张表半年后可能有一格对不上升级前翻一遍 CHANGELOG.md 和配置文档。去社区提问时带上三样东西你的体检卡第①节那四行、你抄的是哪一列、实际卡住的症状一句话。信息齐了别人才能一次把你定位到位。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考