日志追踪度量三足鼎立回答三个不同问题却又互有重叠

可观测性这个词借自控制理论（”由外部输出推断内部状态的程度”），但业界 早已把它拆成三个具体方向长期实践，只是单体时代不太自觉。日志记录离散 事件，回答”发生过什么”——曾调用过什么方法、操作过哪些数据；输出容易， 难在收集和分析海量文本。追踪记录调用链路，回答”为什么变慢/出错”—— 单体时代局限于本地调用栈（IDE断点、printStackTrace），微服务时代升级为 横跨多个服务的”全链路追踪”，同时包含服务间网络传输信息和各服务内部的 调用堆栈。度量是对某类信息的统计聚合，回答”系统整体状态如何”——像财报 用营收净利等聚合数字反映一家公司的经营状况，度量用来支撑监控和预警。 三者各有侧重却又天然重叠：日志可以派生出度量（Metricbeat）、追踪探针 可以同时采集度量数据（SkyWalking）、OpenTelemetry更是试图把三者统一到 一套体系里。工业界的产品格局也印证了三者成熟度不同——日志和度量领域 的胜负已基本落定（日志归于Elastic Stack，度量归于Prometheus），追踪 领域因为与具体网络协议、编程语言强绑定（不同语言的调用栈追踪方式不同）， 天然难以出现一统天下的产品，仍处于群雄混战阶段。

结构图：

flowchart LR
    A[可观测性] --> B[日志 Logging: 发生过什么]
    A --> C[追踪 Tracing: 哪里变慢/出错]
    A --> D[度量 Metrics: 整体状态如何]
    B -.可派生.-> D
    C -.探针可同时采集.-> D
    B & C & D -.试图统一.-> E[OpenTelemetry]