79 lines
2.5 KiB
Markdown
79 lines
2.5 KiB
Markdown
---
|
|
tags: [microservice, observability]
|
|
create time: 2026-04-29 12:04
|
|
---
|
|
|
|
# 可观测性
|
|
|
|
## 概述
|
|
|
|
微服务架构下，一个请求可能穿越十几个甚至上百个服务。**排查问题就像在大海捞针**。可观测性通过三大支柱（Metrics、Logging、Tracing）让系统行为变得"可见"。
|
|
|
|
## 知识体系
|
|
|
|
```mermaid
|
|
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 怎么做？ |
|
|
|
|
### 为什么需要独立的"可观测性"体系？
|
|
|
|
```mermaid
|
|
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]] — 完整微服务知识索引
|