1. 生产可观测性体系总览
在 OpenShift 生产环境中，可观测性不是“装几个监控面板”这么简单，它是一套围绕系统内部状态进行推断与决策的能力体系。可观测性（Observability）与监控（Monitoring）常被混用，但二者关注点不同：监控回答“已知的指标是否越界”，例如节点 CPU 是否超过 80%、Pod 是否频繁重启；可观测性回答“面对未知故障，我能否通过已有数据还原现场并定位根因”。生产环境的复杂性在于故障形态不断变化，因此可观测性体系的目标是让团队在问题发生时，能够用最少的时间从“现象”走到“原因”。
三大支柱的定位与关系
OpenShift 可观测性建立在三大支柱之上：指标（Metrics）、日志（Logs）和追踪（Traces）。它们不是三个独立工具，而是从不同维度描述同一套系统的互补数据。
- 指标：以时间序列形式记录可聚合的数值，如 CPU 使用率、请求速率、错误率、延迟分位数。它回答“系统整体是否健康、趋势如何”，适合告警与容量分析。OpenShift 内置 Prometheus 栈，通过 ServiceMonitor、PodMonitor 采集应用与平台指标。
- 日志：以离散事件形式记录“发生了什么”，如应用报错堆栈、审计事件、容器标准输出。它回答“具体错误是什么、上下文如何”，适合根因定位。OpenShift 使用 ClusterLogging/LogForwarding 将日志汇聚到 Loki 或 Elasticsearch。
- 追踪：以请求为单位记录跨服务调用链，包含 Span 的父子关系、耗时与状态。它回答“一次请求慢在哪一跳、哪个服务出错”，适合微服务与分布式链路分析。OpenShift 通过 OpenTelemetry Collector 接收并转发到 Tempo 或 Jaeger。
三者的关系可以概括为：指标负责“发现异常”，日志负责“解释异常”，追踪负责“串联异常”。当告警触发时，指标给出时间窗口和影响范围；日志提供该窗口内的错误细节；追踪则把一次失败请求的完整路径还原出来。缺少任何一者，排障都会退化为盲人摸象。
生产环境建设目标
生产可观测性建设不能追求“大而全”，而应围绕三个可衡量的目标展开。第一是可发现性：任何影响用户体验的异常，应在分钟级被检测到，而不是等用户投诉。第二是可定位性：从告警触发到定位到具体服务、Pod 或代码行，平均时间（MTTI）应控制在 15 分钟以内。第三是可复盘性：每次故障后能基于历史指标、日志和追踪还原时间线，形成改进项，而不是依赖个人记忆。
以一次典型的订单服务超时为例：Prometheus 告警显示 order-service 的 P99 延迟从 200ms 升至 3s；查看该时段日志，发现大量数据库连接池耗尽异常；再通过 Tempo 追踪一次慢请求，看到耗时集中在调用 inventory-service 的 gRPC 调用上。三个支柱依次给出“异常范围—错误原因—瓶颈跳数”，这就是生产环境期望的排障路径。
成熟度模型
可观测性建设通常经历四个阶段，团队可以据此评估自身位置并规划下一步。
| 阶段 | 特征 | 典型能力 | 关键短板 |
|---|---|---|---|
| L1 被动告警 | 仅核心指标 + 基础告警 | 节点/Pod 存活、CPU 阈值告警 | 无日志聚合，排障靠登录节点 |
| L2 集中采集 | 指标、日志统一接入 | Prometheus + Loki，Grafana 仪表盘 | 指标与日志割裂，缺少追踪 |
| L3 关联分析 | 三支柱打通，统一标签 | TraceID 贯穿日志与追踪，告警关联 | 采样策略粗放，成本上升 |
| L4 预测与自愈 | 基于趋势的容量预测与自动恢复 | 异常检测、自动扩缩容、Runbook 自动化 | 需较高数据质量与组织协同 |
多数团队处于 L2 到 L3 之间。从 L2 迈向 L3 的关键动作是统一关联标识：在应用日志中注入 TraceID，在指标中保留 service、namespace、pod 等标签，使三者在查询时能够互相跳转。例如在 OpenTelemetry 中，通过 Resource 属性统一 service.name，并在日志采集时提取 trace_id 字段，即可在 Grafana 中从指标面板直接跳转到对应追踪。
最后需要明确：可观测性体系的成功标准不是“接入了多少数据”，而是“故障发生时团队能否快速做出正确判断”。因此，在建设初期就应定义关键用户旅程（如登录、下单、支付）和对应的 SLO，让三大支柱围绕这些旅程组织数据，而不是按技术组件堆砌仪表盘。下一阶段的工作，将从指标采集与 Prometheus 栈的具体配置开始展开。