tags, create time
| tags | create time | ||
|---|---|---|---|
|
2026-04-29 12:04 |
可观测性
概述
微服务架构下，一个请求可能穿越十几个甚至上百个服务。排查问题就像在大海捞针。可观测性通过三大支柱（Metrics、Logging、Tracing）让系统行为变得"可见"。
知识体系
graph LR
A["Metrics 监控"] --> C["日志系统"]
B["链路追踪"] --> C
C --> D["告警管理"]
style A fill:#e3f2fd
style B fill:#fff3e0
style C fill:#fce4ec
style D fill:#e8f5e9
| # | 主题 | 核心问题 |
|---|---|---|
| 1 | 04-可观测性/01-Metrics监控 | 怎么量化系统的健康度？RED/USE 方法怎么用？ |
| 2 | 04-可观测性/02-日志系统 | 日志怎么集中收集？结构化日志的最佳实践是什么？ |
| 3 | 04-可观测性/03-链路追踪 | trace_id 如何贯穿跨服务调用链？OpenTelemetry 怎么用？ |
| 4 | 04-可观测性/04-告警管理 | 如何设计告警避免疲劳？SLO/Error Budget 怎么做？ |
为什么需要独立的"可观测性"体系？
flowchart LR
subgraph MONO["单体系统"]
S[Service] --> DB[(DB)]
LOG["同一份日志<br/>一目了然"]
S --> LOG
end
subgraph MICRO["微服务系统"]
REQ("Request") --> GW["Gateway"]
GW --> O1["Order Svc"]
GW --> U1["User Svc"]
O1 --> PAY["Payment Svc"]
O1 --> INV["Inventory Svc"]
PAY --> DB1[(DB)]
INV --> DB2[(DB)]
style O1 fill:#faa
style U1 fill:#faa
style PAY fill:#faa
style INV fill:#faa
end
NOTE["问题：日志分散、链路断裂<br/>传统监控无法回答'这个请求经历了什么'"]
MICRO --> NOTE
[!keypoint] 可观测性与监控的本质区别
监控系统告诉你"出事了"（已知未知），可观测性系统让你去探究"为什么会出事"（未知未知）。
三大支柱
| 支柱 | 回答的问题 | 典型工具 |
|---|---|---|
| Metrics | 系统现在健康吗？— 趋势、告警 | Prometheus + Grafana |
| Logging | 具体发生了什么？— 历史回溯 | ELK / Loki |
| Tracing | 请求在哪一步慢了/失败了？— 链路追踪 | Jaeger / Zipkin |
关联笔记
- 02-服务治理 — 熔断器可以触发告警，与监控系统联动
- 05-部署运维/02-Kubernetes — K8s Liveness/Readiness Probe 是可观测性的基础
- hzh/MS/README.md — 完整微服务知识索引