可观测性

概述

微服务架构下，一个请求可能穿越十几个甚至上百个服务。排查问题就像在大海捞针。可观测性通过三大支柱（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 — 完整微服务知识索引