可观测性

→ 返回 云原生

可观测性（Observability）是通过系统外部输出推断内部状态的能力，三大支柱：Metrics + Logs + Traces。实现层以 OpenTelemetry 为统一标准，后端对接 Prometheus、Loki、Jaeger 等；详见 可观测性中间件索引。

三大支柱

系统运行时输出
    │
    ├── Metrics（指标）：系统当前状态的数值
    │   CPU 使用率、QPS、延迟、错误率
    │
    ├── Logs（日志）：离散事件的详细记录
    │   请求日志、错误日志、业务日志
    │
    └── Traces（链路追踪）：请求在系统中的完整调用链
        A → B → C，每段耗时，哪里慢

OpenTelemetry（OTel）

现代可观测性的统一标准，将三大支柱的采集、传输统一化：

应用代码
    │
    ▼
OpenTelemetry SDK（自动/手动埋点）
    │
    ▼
OTel Collector（采集、处理、路由）
    │
    ├── Metrics → Prometheus
    ├── Logs    → Loki / Elasticsearch
    └── Traces  → Jaeger / Tempo / SkyWalking

优势： 切换后端（如从 Jaeger 换 Tempo）无需修改业务代码，只改 Collector 配置。

中间件与文档入口

组件	说明	文档
OpenTelemetry	SDK、Collector、OTLP 协议	OpenTelemetry
Prometheus	指标抓取与 TSDB	Prometheus
Grafana	大盘与告警可视化	Grafana
SkyWalking	Java APM、全链路	SkyWalking
Spring Boot / Cloud	Micrometer、Tracing	见下方 Java 文档列表

Java 文档：

• 链路追踪 — Boot 链路追踪
• 链路追踪 — Cloud 链路追踪
• 指标采集 — 指标采集
• 日志聚合 — 日志聚合

OTel Collector 在 K8s 中常以 DaemonSet 或 Sidecar 部署，与 Kubernetes 配套。

Metrics（指标监控）

Prometheus 架构

Target（被监控服务）
   │ 暴露 /metrics HTTP 端点
   ▼
Prometheus Server（定时 Pull 抓取）
   │ 存储时序数据（TSDB）
   ▼
Grafana（可视化面板）
   │
AlertManager（告警）
   │
   └── 钉钉 / Slack / PagerDuty

核心监控指标（RED 方法）

指标	说明
Rate	请求速率（QPS）
Errors	错误率（5xx / 业务错误）
Duration	请求耗时（P50 / P95 / P99）

常用 Exporter

Exporter	监控目标
node-exporter	主机 CPU、内存、磁盘、网络
kube-state-metrics	K8s 资源状态（Pod 数、副本数）
JMX Exporter	JVM 堆内存、GC、线程数
Redis Exporter	Redis 命令数、内存、连接数
MySQL Exporter	QPS、慢查询、连接数

Grafana 仪表盘

┌─────────────────────────────────────────────┐
│  QPS: 12,340/s    P99 Latency: 45ms         │
│  Error Rate: 0.02%  CPU: 34%  Mem: 62%      │
├────────────────────────┬────────────────────┤
│  [QPS 折线图]           │  [延迟热力图]       │
│                        │                    │
├────────────────────────┴────────────────────┤
│  [各服务错误率对比]                           │
└─────────────────────────────────────────────┘

Logs（日志系统）

EFK 架构

Pod（日志写到 stdout/stderr）
   │
   ▼
Filebeat / Fluentd（DaemonSet，采集每个 Node 日志）
   │
   ▼
Kafka（可选，削峰）
   │
   ▼
Logstash（过滤、解析、转换）
   │
   ▼
Elasticsearch（存储 + 索引）
   │
   ▼
Kibana（查询 + 可视化）

Loki 架构（轻量替代）

Pod
   │
Promtail（类似 Filebeat，K8s 原生）
   │
   ▼
Loki（仅索引元数据，日志内容压缩存储）
   │
Grafana（统一查询 Metrics + Logs）

Loki vs ELK：

维度	Loki	ELK
资源消耗	低	高
查询能力	LogQL（类 PromQL）	DSL（强大）
全文搜索	有限（需 chunk 扫描）	强（倒排索引）
适用场景	中小规模，K8s 日志	大规模，需全文搜索

日志规范

# 结构化日志（JSON）
{
  "timestamp": "2026-05-21T10:00:00Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123",
  "message": "数据库连接超时",
  "user_id": "12345",
  "latency_ms": 3001
}

关键字段：

• trace_id：与链路追踪关联，点击日志直接跳转 Trace
• service：服务名，方便过滤
• level：日志级别，生产环境只保留 WARN 以上

Traces（链路追踪）

原理

每个请求携带唯一 TraceID，经过的每个服务生成一个 Span：

TraceID: abc123

Span 1: API Gateway          0ms ~ 150ms
  └── Span 2: user-service   5ms ~ 30ms
  └── Span 3: order-service  35ms ~ 140ms
        └── Span 4: MySQL    36ms ~ 130ms  ← 慢查询！
        └── Span 5: Redis    36ms ~ 38ms

快速定位哪一层出现了性能问题。

主流方案

工具	特点	文档
Jaeger	CNCF 毕业，开源，常用	OTel Exporter 对接
Tempo	Grafana 出品，与 Loki/Prometheus 统一	Grafana 栈
SkyWalking	APM 完整方案，Java 生态友好	SkyWalking
Zipkin	老牌，简单	常与 OTel / Micrometer 配合
OpenTelemetry	统一采集，后端可换	OpenTelemetry

告警策略

AlertManager 配置：

QPS 下降 > 30%（服务异常）   → 立即告警
P99 延迟 > 500ms（持续 5m） → 告警
Error Rate > 1%（持续 2m）  → 告警
Pod 重启次数 > 3（1h 内）    → 告警
磁盘使用率 > 85%            → 预警

告警分级：

级别	触发条件	通知方式
P0 Critical	服务不可用，核心指标断崖	电话 + 短信 + 群消息
P1 High	核心功能受损	群消息 + 工单
P2 Medium	性能下降，有用户感知	群消息
P3 Low	预警，暂无影响	邮件

K8s 可观测性全栈

K8s 集群
  │
  ├── kube-state-metrics → Prometheus（集群资源状态）
  ├── node-exporter → Prometheus（节点资源）
  ├── cAdvisor → Prometheus（容器资源）
  │
  ├── 应用 Pod → OTel Collector
  │     ├── Metrics → Prometheus
  │     ├── Logs → Loki
  │     └── Traces → Tempo
  │
  └── Grafana（统一展示 Metrics + Logs + Traces）

---

相关链接

云原生专题

• 云原生概述
• Kubernetes 核心
• 服务网格（网格侧追踪与指标）
• CD（发布与回滚可观测）

中间件（可观测性）

• 可观测性索引
• OpenTelemetry
• Prometheus
• Grafana
• SkyWalking

Java 实战

• Actuator
• 链路追踪
• Spring Cloud 链路追踪

架构全景

• 系统全貌