夜莺监控

夜莺监控（Nightingale）是面向 Prometheus 生态和多数据源环境的开源监控告警平台，重点在统一查询、规则、通知、事件和权限。它不会凭空生成完整指标：采集器、时序数据库、标签质量和保留策略仍由团队规划，夜莺负责把这些数据转成可治理的告警流程。

先让数据源说同一种“标签语言”

接入 Prometheus、VictoriaMetrics 等数据源前，统一 cluster、env、service、instance 的含义。选择一项服务验证即时值、历史曲线和查询权限。标签缺失会导致告警无法路由，高基数标签则会推高时序存储压力；不要在实例标签中放用户 ID 或请求 ID。

一条规则必须描述症状和影响

以接口错误率为例，规则写清数据源、查询表达式、触发阈值、持续时间、恢复条件和适用环境，附加信息中放服务所有者、仪表盘和处理手册。先用历史数据回放阈值是否过敏，再制造可控错误验证。单个采集点短暂缺失与业务整体不可用应使用不同规则。

通知规则决定事件发给谁

夜莺将告警事件与通知规则分开管理，可按标签、等级和团队选择电话、短信、邮件、飞书、钉钉或企业微信等媒介。值班路由应有主负责人、升级人和时间窗口，通知模板必须展示对象、环境、当前值、开始时间和操作入口。凭据、费用及发送额度也要纳入运维。

用四次演练检查降噪是否真实

1. 让指标短暂抖动，确认持续时间能过滤瞬时噪声；
2. 保持故障，确认同一对象不会按采集频率重复轰炸；
3. 恢复服务，确认恢复事件与原告警关联；
4. 停用主通知媒介，确认失败记录和备用路线可见。

屏蔽、静默和订阅都应有到期时间与操作人，避免维护窗口结束后告警长期失声。

区分“没采到”和“业务真的正常”

为关键服务同时监控业务指标与采集链路：目标消失、查询报错、数据延迟和指标为零应是不同状态。若 Prometheus 或远端数据源不可用，夜莺查询无结果不能自动解释为服务恢复。单独设置数据新鲜度或采集心跳，并让通知模板明确写出“数据缺失”还是“阈值恢复”，避免值班人员做出相反判断。

事件复盘反向修改规则

平台自身、时序数据库和通知组件也要被独立监控。采用前分别核对社区版、当前版本和 Flashcat 商业服务边界，不把产品支持范围等同于内部已有采集覆盖。