---
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]] — 完整微服务知识索引