企业监控需按基础设施→中间件→应用→业务四层收敛指标，每层只保留对上层有解释力的关键信号；告警治理强调降噪、归因、闭环；指标全生命周期需版本化管理；告警响应须固化为机器可执行SOP。
指标分层：从基础设施到业务价值逐层收敛
监控不是堆指标，而是建视角。企业级监控需按“基础设施 → 中间件/服务 → 应用逻辑 → 业务结果”四层组织指标，每层只暴露对上层有解释力的关键信号。
例如：CPU使用率（基础设施层）本身不直接说明问题，但当它持续 >90% 且伴随 JVM Full GC 频次突增（中间件层）、订单创建耗时 P95 上升 300ms（应用层）、支付失败率跳升 5%（业务层）——这组跨层指标联动，才能定位是数据库连接池耗尽引发的雪崩。
- 基础设施层：聚焦稳定性基线——磁盘IO等待、网络丢包率、内存页回收速率，避免采集所有/proc/stat字段
- 中间件层：关注组件健康契约——Redis连接数/最大连接数比值、Kafka consumer lag、Nginx 5xx比率
- 应用层：绑定代码路径——HTTP接口的status_code + handler_name + duration_ms三元组，禁用泛化指标如“API响应时间”
- 业务层：映射用户可感知结果——下单成功数/秒、搜索无结果率、首屏加载完成耗时，需与埋点系统对齐口径
告警治理：用“降噪-归因-闭环”替代“收告警-点链接-查日志”
80%的告警疲劳源于同一故障触发多层重复告警。治理核心是让告警自带上下文和处置指引，而非依赖人工串联信息。
- 降噪：在Prometheus中用absent()替代up == 0检测服务存活；对抖动型指标（如瞬时CPU飙升）加rate()窗口平滑，禁用点对点阈值告警
- 归因：告警规则内嵌labels传递根因线索——例如K8s Pod重启告警自动携带reason="OOMKilled"或reason="CrashLoopBackOff"
- 闭环：告警触发时自动执行预检脚本（如curl -I 检查健康端点），并将结果注入Alertmanager的annotations，避免值班人员重复验证
指标生命周期管理：从采集到归档的可控演进
指标不是越全越好，而是要像代码一样版本化管理。每个指标必须明确：谁定义、为什么存在、保留多久、下线条件。
- 新指标上线前需通过SLI影响评估表：是否支撑SLO计算？是否填补当前故障定位断点？
- 存量指标每季度扫描：连续30天无告警/无图表引用/无SLO关联的指标自动进入“待归档”状态
- 高基数标签（如user_id、request_id）默认禁用，确需调试时通过_debug后缀临时开启，并设置2小时自动关闭
告警响应SOP：把经验固化成机器可执行的动作
真正的治理终点不是减少告警数量，而是让每次告警触发都启动标准化响应链路。
- Alertmanager路由配置中，为不同严重级别绑定不同receiver：P1告警直连oncall群并触发runbook URL，P2仅发邮件并附带curl -X POST自愈命令示例
- 每个业务域维护runbook.md，包含：现象特征、影响范围判断指令、3步隔离操作、验证是否恢复的curl命令
- 告警关闭后自动触发postmortem check：检查关联指标是否回归基线、是否有残留异常日志，未通过则生成跟进工单
