文章

可观测性知识总览

#observability#sre#prometheus#grafana#opentelemetry#监控

可观测性知识总览

一句话：可观测性不是”装个监控”，而是通过系统外输出的信号，回答”现在为什么慢/为什么错/为什么挂”的能力。SRE 的三大支柱是 Metrics、Logs、Traces——近年又加了 Profiling（持续性能剖析）。

为什么这个主题对你不是可选项

你的 vault 里已经反复出现观测需求，但一直散落：

  • Cilium 架构与数据面组件 / Cilium Hubble 可观测性与运维排障 —— Hubble 就是基于 Envoy 的分布式追踪 + metrics
  • LLM 推理服务化/生产部署与运维 —— 监控指标 TTFT/TPOT/吞吐/GPU 利用率是服务化的命脉
  • cgroup v2 详解 / eBPF 排障实战 —— PSI 压力指标、bpftool 看到的都是信号
  • K8s 网络架构总览 —— 数据包路径排查本质是 trace 思维

缺一个统一底座，这些就只是孤岛。本系列把底座补齐，并和上面每一篇打通。

知识结构图

graph TD
    A[可观测性] --> B[Metrics 指标]
    A --> C[Logs 日志]
    A --> D[Traces 追踪]
    A --> E[Profiling 剖析]
    B --> B1[Prometheus]
    B --> B2[Grafana 可视化]
    C --> C1[Loki]
    C --> C2[ELK]
    D --> D1[OpenTelemetry]
    D --> D2[Jaeger/Tempo]
    E --> E1[Pyroscope/PProf]
    B1 --> O[OTel Collector 统一采集]
    C1 --> O
    D1 --> O
    O --> BE[后端存储/告警]
    BE --> SLO[SLO/错误预算]

三大信号对比（核心心智模型）

维度Metrics 指标Logs 日志Traces 追踪
回答的问题有多少？多快？发生了什么？为什么慢/为什么错？
数据形态数值时间序列（聚合）离散结构化事件请求跨服务的调用链
体量小（预聚合）大（全量/采样）中（按请求采样）
典型工具PrometheusLoki / ELKJaeger / Tempo
例子QPS=1200、P99=350ms”order-svc 超时 DB”一次 checkout 经过 7 个服务耗时分解
成本低高（索引/存储）中

选型铁律：能用 Metrics 回答的，绝不靠 Logs 捞；能靠 Traces 定位的，别用 Logs 猜。三者互补，不是替代。

方法论：黄金信号 / RED / USE

  • 四大黄金信号（Google SRE）：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）
  • RED（请求类服务）：Rate（速率）、Errors（错误率）、Duration（时延分布）
  • USE（资源类）：Utilization（利用率）、Saturation（饱和度）、Errors（错误数）

你的 cgroup v2 笔记里 PSI 的 some/full 就是 USE 中 Saturation 的极致体现——某资源（CPU/IO/内存）被压满的程度。

OpenTelemetry：统一采集层

OpenTelemetry（OTel）用一套 API/SDK 产生三类信号，通过 OTLP 协议 发给 Collector，再由 Collector 转发到任意后端（Prometheus/Jaeger/Loki/Tempo）。它解决的是” instrumentation 锁定”问题——代码不绑死某家后端。

graph LR
    APP[应用 OTel SDK] --> OTLP[OTLP]
    OTLP --> COL[OTel Collector]
    COL --> P[(Prometheus)]
    COL --> J[(Jaeger)]
    COL --> L[(Loki)]

学习路线

  1. 先建立三大信号心智模型（本篇 + RED/USE）
  2. Metrics：Prometheus 数据模型 → PromQL → 规则 → 长期存储
  3. 可视化：Grafana 面板 + 告警
  4. 日志：Loki/ELK 模型差异 + 查询
  5. 追踪：OTel 架构 + 采样 + Jaeger/Tempo
  6. 闭环：SLO/SLI/错误预算 把信号变成”该不该告警/该不该发版”
  7. 落地：K8s 可观测性实战（Prometheus Operator + Hubble + cAdvisor）

概念速查

术语含义
TSDB时序数据库（Prometheus 自带）
cardinality标签组合数，爆炸会拖垮 Prometheus
histogram直方图指标（分桶统计，算分位数的基础）
exemplar直方图样本关联一个 trace，实现指标→链路跳转
OTLPOpenTelemetry 协议（gRPC/HTTP）
CollectorOTel 收发处理管线（pipeline）
spantrace 中的一个操作单元
context propagation跨进程传递 trace 上下文（W3C traceparent）
tail-based sampling看完整个 trace 再决定采不采（按错误/慢采）
SLO服务等级目标（如 99.9% 请求 < 300ms）
Error Budget1 - SLO 允许的”错误配额”
burn rate错误预算消耗速率（告警核心指标）
exemplar指标样本挂一个 trace id，实现下钻

工具链总览

层推荐
采集OTel SDK / Collector、node_exporter、kube-state-metrics、cAdvisor
Metrics 存储Prometheus、Thanos、Mimir、VictoriaMetrics
可视化Grafana
日志Loki（+ Promtail/Vector）、ELK
追踪Jaeger、Tempo、Zipkin
告警Alertmanager
SLOPrometheus SLI、Polaris、Pyroscope（剖析）

深度实战笔记

关联知识

参考资源

  • Google SRE Book: Monitoring Distributed Systems
  • OpenTelemetry 官方文档（opentelemetry.io）
  • Prometheus 官方文档（prometheus.io/docs）
  • Grafana Labs 博客（Loki 设计哲学）

学习时间

内容日期状态
体系总览2026-07-24完成：三信号模型、RED/USE、OTel、学习路线、概念速查

学习时间

内容日期状态
可观测性六维信号深度实战2026-08-04完成：Go 代码 + PromQL/LogQL/TraceQL + K8s 配置

状态

  • 总览 MOC
  • 可观测性六维信号深度实战（2026-08-04）
  • Metrics 与 Prometheus 实战
  • Grafana 可视化与告警
  • 日志体系 Loki/ELK
  • 分布式追踪 OpenTelemetry
  • SLO/SLI 错误预算
  • K8s 可观测性实战