6.4 监控与容量规划

6.4 监控与容量规划

本节摘要：元数据平台的监控困境在于：它挂了没人喊，它病了没人知——用户对地图的容忍度是慢慢流失的。本节建立一套以业务健康为先的监控视图：五个黄金指标覆盖服务与事件链路，两类专属告警（一致性告警与新鲜度告警）对应元数据平台独有的故障形态，外加季度容量巡检的四条曲线。读完你应当能让平台的状态自己说话，而不是等用户流失后才复盘。本节承接 6.2 与 6.3，是运维体系的收口。

为什么照抄 Web 服务的监控会失灵

把 Web 服务的监控模板（QPS、错误率、P99 延迟）直接套过来，会发现指标常年一片祥和——元数据平台的查询量低，哪怕半残状态，这些指标也不报警。但平台的健康其实由另一组东西决定：数据够不够新（新鲜度）、各存储之间对不对得齐（一致性）、事件链路流不流得动（积压）。这三样全都不在传统模板里。

由此确立本节的原则：元数据平台的监控，业务健康指标优先于系统资源指标。资源指标（CPU、内存、磁盘）照常采集，但告警的语义要翻译成业务后果——磁盘告警不是"磁盘要满了"，而是"还有三天索引写入会失败"。

五个黄金指标

指标一：摄入成功率。每轮摄入任务的实体处理成功占比。跌破阈值说明接入链路有病——这是用户还没抱怨、地图已经开始变坏的第一信号。按数据源分维度统计，能直接定位是哪个源的连接器出了问题。

指标二：事件消费积压深度。消息队列里未消化的事件数与消费者的处理延迟。2.3 与 6.2 已确立它的地位：持续增长的积压是一致性恶化的前奏。阈值经验：持续增长半小时告警；处理延迟从秒级滑向分钟级即值得介入。

指标三：端到端新鲜度。从源系统发生变更到它出现在搜索结果里的时长。这是用户体感的直接度量，也是新鲜度告警的依据。采集方式：在源系统侧埋一个"变更哨兵"——定期对某个测试实体做一次小修改，记录修改时间与平台上可见时间的差值。哨兵模式的好处是把整条链路（摄入、校验、广播、索引）串起来测，任何一环变慢都会在数字上现形。

指标四：搜索质量信号。零结果搜索的占比与点击首条的占比。这不是技术指标而是产品指标，但运维应当把它放进同一块看板：搜索质量恶化通常对应内容运营停滞或索引异常，两边的团队都该看见。

指标五：资源水位三件套。主库连接数与存储容量、图库与索引的内存、队列磁盘占用。它们的告警阈值要换算成"还剩多少天"：按当前增长斜率，容量耗尽的预计天数低于一个采购或扩容周期时告警——这是 6.2 主库瓶颈预见的落地。

两类专属告警

一致性告警：定期抽样比对主库与派生视图——随机抽一批实体，比对主库状态与搜索索引中的文档是否一致。抽样比对每夜执行，不一致率超过阈值告警。它捕捉的是积压告警覆盖不到的静默丢失：事件丢了、消费者跳过了毒消息、索引部分损坏，这些情况下积压是零，但一致性已经破了。修复手段就是 6.2 的定向重放或全量重建。

新鲜度告警：按数据源监控"最后一次成功摄入"的距今时长。每个源有自己的节奏（日更的数仓、分钟级的流），告警阈值按各自节奏的两倍周期配置。它抓住的是 push 钩子断流、调度下线、凭证过期这类"没人改任何东西但链路死了"的静默故障——4.4 排错实录里那个"调度升级钩子失联"的案例，就是新鲜度告警比用户先发现的。

看板的一屏三层布局

指标定了，看板的组织方式决定值班效率。推荐一屏三层：顶层是业务健康——新鲜度哨兵读数、一致性抽样结果、各源最后成功摄入时间，这三个读数回答"地图还好吗"；中层是链路——摄入成功率、积压深度与消费者延迟，业务指标异常时从中层找原因；底层是资源——CPU、内存、磁盘水位，为中层异常提供物理证据。值班的第一反应永远是看顶层，多数时候到中层就结束，底层只在深挖时才看。

这套布局的反面是常见的"资源优先"看板：CPU 内存磁盘铺满首屏，业务健康藏在第二屏的角落。用那种看板值班，平台已经病了三天，仪表上还是一片绿。布局定稿后，给每个读数写一行"异常时下一步看哪"，看板从展示品升级为排障路径图——值班同学照着读数之间的箭头走，第一次遇到异常也不会迷路。

告警路由跟着分层走：顶层异常通知平台运维与数据负责人（业务后果型，值得打扰人）；中层异常进值班群（链路型，工作时间内处理）；底层异常走工单（资源型，按容量节奏消化）。三层两种打扰级别，与 5.4 的告警分级一脉相承。

季度容量巡检的四条曲线

季度巡检看四条曲线的斜率，而不是某个时点的绝对值。实体总量曲线：增长突然放缓可能不是好消息——接入停滞或摄入持续失败；陡增则要检查是不是某次批量导入失控。事件吞吐曲线：与实体增长的比例关系应大致稳定，比例漂移说明某些集成在写重复数据。主库容量与连接峰值：换算耗尽天数，进入预警期即启动 6.2 的扩容决策。图库与索引内存水位：血缘边数的增长快于实体数时（字段级血缘铺开期），图库内存的斜率要单独关注。

巡检的产出物是一页纸：四条曲线加各自的天数预估加建议动作。这页纸也是向管理层申请资源的最有力材料——容量是算出来的，不是吵出来的。

一个告警阈值的调参记录

阈值怎么定，空谈不如看一次真实调参。某平台上线监控的第一个月，积压告警设的是"积压超过一万条"，结果一周响了五次，每次到场都是批量摄入高峰的正常排队，运维很快把它静音了——静音期间一次真正的消费者故障持续了六个小时才被用户发现。复盘后把阈值改成"积压深度持续增长超过三十分钟"加"处理延迟超过六十秒"双条件，告警频率降到每月一两次，每次都对应真实问题。

这个记录里有两条普适经验。第一，阈值要描述趋势与后果，而不是某个绝对数值——一万条积压在批量摄入时是健康，在凌晨三点是事故，绝对数分不清这两种世界。第二，告警的每一次误报都在透支下一次真报的响应速度——调参的目标不是"别误报"，而是"每次响都值得人到场"。新鲜度告警的调参同理：按源节奏配置（日更源的两倍周期、小时级源的三倍周期），别用一把尺子量所有源。

💡 监控看板的最终检验是"值班的同学敢不敢静音"。如果告警常被静音，说明阈值与业务后果脱节——回到每个告警的回答"它响了意味着用户会经历什么"，重新定阈值。

本节要点回顾

• 监控原则：业务健康（新鲜度、一致性、积压）优先于资源指标；资源阈值换算成剩余天数。
• 五黄金指标：摄入成功率、积压深度、端到端新鲜度、搜索质量信号、资源水位三件套。
• 变更哨兵：在源侧定期改测试实体测端到端延迟，把整条链路串起来测。
• 两类专属告警：一致性抽样抓静默丢失，新鲜度按源节奏抓静默断流。
• 季度巡检：四条曲线看斜率，一页纸输出，容量是算出来的。

运维的眼睛装好了。最后一节收束全册：把认知、接入、应用、运维串成一张组织级路线图，并给每个阶段标出前三号陷阱。