Logs / Metrics / Traces、SLI/SLO、告警、值班、容量、故障演练与可靠性治理 (2025-2026)
| 上层 | 依赖的下层 | 关系说明 |
|---|---|---|
| 看板与告警 | 信号采集 | 没有稳定采集链路，再漂亮的监控面板也只是空壳。 |
| SLO 与错误预算 | 语义统一 | 没有统一标签、服务边界和指标定义，SLO 很难真正映射到业务体验。 |
| 值班与应急响应 | 告警质量 | 告警如果噪音过大、归因不清，值班体系只会把人耗尽，而不是提升可靠性。 |
| 容量与发布治理 | 运行时数据 | 没有流量、延迟、饱和度和错误趋势数据，就无法对扩容、降级和发布做出可靠判断。 |
| 复盘与平台化 | 全链路证据 | 没有高质量日志、链路、告警历史和变更记录，复盘很容易退化成“事后猜测”。 |
| SRE 文化 | 工程闭环 | SRE 不是一套工具清单，而是把可观测、可恢复、可度量和可改进做成日常交付标准。 |
指标适合看趋势、容量和系统健康，回答“哪里开始不对劲了”。QPS、错误率、延迟和饱和度通常是第一层信号。
日志更适合看离散事件和详细上下文，回答“具体发生了什么”。没有结构化字段的日志，后期检索成本会很高。
链路追踪适合看跨服务调用路径，回答“一个请求经过哪些组件、卡在哪里、重试了几次”。
三者不是替代关系，而是互补关系。指标负责发现，链路负责定位，日志负责解释细节。
真正让可观测失效的，往往不是“没采到”，而是服务名混乱、标签不一致、环境字段缺失、版本信息对不上。
OTel 把采集 SDK、Collector、语义约定和导出协议统一起来，降低了语言和厂商之间的割裂成本。
先把服务边界、请求上下文、版本、租户、区域、实例这些关键元数据打通，再去谈高级分析和智能告警。
SLI 是可靠性的可测量指标，比如请求成功率、P95 延迟、任务完成率、消息处理时延。
SLO 是对用户体验的工程承诺，不应该只来自技术团队偏好，而要和业务价值、用户容忍度和成本约束一起定义。
错误预算不是为了“容忍故障”，而是帮助团队在发布速度和稳定性之间做显式权衡，避免所有讨论都变成抽象争论。
能明确指出影响范围、严重级别、初步归因方向和可执行动作的告警，才算真正有用。
值班的重点不是“谁接电话”，而是有没有清晰升级路径、Runbook、应急权限、回滚能力和跨团队协作机制。
噪音告警、告警风暴、阈值拍脑袋、没有归并、没有静默策略，是值班体验恶化的主要来源。
容量评估要同时看流量、饱和度、依赖服务瓶颈、冷启动、缓存命中率、队列积压和错误恢复时间。
灰度发布、自动回滚、金丝雀验证都建立在高质量信号之上。没有可靠观测，灰度发布只是更慢地冒险。
好的复盘不是追责会议，而是把组织性的薄弱点变成具体行动项：补指标、改告警、加隔离、修流程、做演练。
| 类别 | 主流项目 | 定位 | 适用场景 | 关键考量 |
|---|---|---|---|---|
| 指标 | Prometheus / VictoriaMetrics / Thanos / Mimir | 时序指标采集与查询 | 基础监控、SLO、容量趋势 | 保留周期、基数和查询成本 |
| 日志 | Loki / ELK / OpenSearch | 日志汇聚、检索与分析 | 问题排查、审计、事件解释 | 索引成本、结构化程度、长期留存 |
| 链路追踪 | Tempo / Jaeger / Zipkin | 跨服务链路可视化 | 慢请求、错误传播、根因定位 | 采样策略、上下文传播、存储成本 |
| 采集与中转 | OpenTelemetry Collector / Fluent Bit / Vector | 统一采集、处理、转发 | 多信号接入、格式转换、路由 | 语义统一与管道稳定性 |
| 可视化 | Grafana / Kibana | 看板、探索、联动分析 | 日常运维、值班、业务观测 | 看板治理与权限控制 |
| 值班与告警 | Alertmanager / PagerDuty / Opsgenie / 自研平台 | 告警路由、聚合、升级 | 值班响应与事件管理 | 告警噪音和升级路径设计 |
| 方案 | 优点 | 短板 | 适合谁 |
|---|---|---|---|
| 开源自建 | 可控性高、可定制、成本结构透明 | 维护复杂、需要平台能力 | 中大型技术团队 |
| 商业可观测平台 | 开箱即用、体验成熟、联动完整 | 成本高、厂商绑定更强 | 想快速落地且预算充足的团队 |
| 混合模式 | 关键链路自控，外围能力借力平台 | 数据模型和操作习惯容易割裂 | 需要兼顾速度和控制力的组织 |
| 等级 | 典型条件 | 响应要求 | 目标 |
|---|---|---|---|
| P1 | 核心服务全量不可用、资金链路中断 | 立即拉齐核心负责人，按预案应急 | 先止损，再恢复 |
| P2 | 部分关键能力退化、错误率快速上升 | 值班接入，必要时升级 | 快速定位并控制扩散 |
| P3 | 单点异常、容量水位接近阈值 | 工作时段处理或自动化处置 | 避免演化成更高等级事件 |
| P4 | 优化类或信息类事件 | 沉淀到改进清单 | 减少未来噪音和隐患 |
把日志规范、指标模板、链路透传、告警路由、发布验证、错误预算看板、事件管理和复盘模板做成组织级通用能力，而不是要求每个业务团队从零搭一次。
不是做一个“监控门户”，而是让团队用最少额外心智获得可观测、可报警、可回滚、可复盘的常规工程能力。
| 类别 | 推荐工具 | 说明 |
|---|---|---|
| 指标 | Prometheus / VictoriaMetrics / Thanos / Mimir | 采集、存储和查询时序指标 |
| 日志 | Loki / ELK / OpenSearch / Vector / Fluent Bit | 结构化日志采集与检索分析 |
| 链路 | OpenTelemetry / Tempo / Jaeger | 跨服务追踪、上下文透传、性能定位 |
| 可视化 | Grafana / Kibana | 看板、探索、告警联动、排障面板 |
| 告警与值班 | Alertmanager / PagerDuty / Opsgenie | 路由、聚合、升级和值班管理 |
| 压测与演练 | k6 / JMeter / Chaos Mesh / Litmus | 容量验证、故障注入与恢复演练 |
| 平台集成 | Argo Rollouts / Flagger / Backstage | 发布验证、看板集成和平台化入口 |
OpenTelemetry 继续巩固语义层位置: 多语言、多平台、多厂商环境下，统一采集和语义会越来越重要。
SLO 驱动治理继续深化: 团队会逐步从“看 CPU 和内存”转向“看用户体验与错误预算”。
可靠性平台化: 观测、告警、值班、回滚和复盘模板会更多沉淀成组织级基础设施。
eBPF 可观测增强: 内核级网络、延迟和安全观测能力会继续向平台通用能力演进。
AI 辅助排障: 告警聚类、异常解释、复盘辅助会越来越常见，但仍需要高质量底层数据喂养。
成本感知观测: 采样、保留策略、冷热分层和价值分级会越来越重要。
信号泛滥: 什么都采但没人用，会把成本和复杂度一起推高。
平台脱离业务: 只做工具接入、不理解关键链路，就很难定义真正有价值的 SLO 和告警。
把 AI 当银弹: 没有干净数据和清晰流程时，智能运维只会把噪音包装得更花哨。