软件工程 / 架构设计方法论知识图谱 / 分组目录 / 技术实践层 / 可观测性信号采集
technology · K · P0 · active

可观测性信号采集

Observability Signals and Instrumentation
P0进阶verified技术实践 technology技术K · 运维质量属性GL-TECHNOLOGY · 技术实践层

§1摘要与结论

TL;DR · 一句话结论

通过 traces、metrics、logs 等信号从系统外部推断内部状态，以回答未知未知与为何发生；工程界习称三支柱，其价值关键在于信号可关联而非数量多少。

别名：Observability Signals、可观测性三支柱、metrics/logs/traces、分布式追踪、OpenTelemetry　|　英文：Observability Signals and Instrumentation　|　类型：技术 / practice

§2局部关系图

可观测性信号采集 的 1-2 跳邻域关系图依据推导（derives_from）：信号关联与追踪依据可观测性本质依赖关联（dependency）：错误预算政策以服务等级目标为输入细化（refines）：四大黄金信号是可观测性信号的核心指标集前置依赖（prerequisite）：事件响应决策依赖错误预算政策前置依赖（prerequisite）：事件复盘证据驱动混沌实验设计细化（refines）：可用性战术是战术映射的细化依据推导（derives_from）：文档化方法以架构描述为对象组织视图与对应关系依据推导（derives_from）：文档化依视图与视角约定组织架构信息前置依赖（prerequisite）：视图与视角概念是理解架构描述构成与对应关系的前提案例印证（case_instance）：印证：以分层文档组织视图，再补跨视图信息案例印证（case_instance）：印证：按不同关注点组织层级与模块视图案例印证（case_instance）：印证：把不可见的架构转写为可复核的架构描述实现（implements）：断路器与重试实现可用性战术实现（implements）：容错战术映射至质量属性实现（implements）：可观测信号关联方法的技术实现实现（implements）：四大黄金信号的采集与呈现实现（implements）：服务等级目标的度量与设定实现（implements）：错误预算与燃尽率告警实现实现（implements）：混沌工程方法的实验化落地实现（implements）：无指责复盘的文档化落地促成（enables）：可观测信号使 SLO 可度量促成（enables）：可观测稳态为混沌实验提供判据组合（combination）：容错机制可由混沌实验验证组合（combination）：实验发现的弱点进入复盘与修复闭环组合（combination）：错误预算与交付指标共同度量稳定与吞吐组合（combination）：熔断与重试事件需被可观测信号捕获组合（combination）：错误预算界定混沌实验可接受的爆炸半径促成（enables）：可观测信号是事故复盘的时间线证据案例印证（case_instance）：印证：以显式失败取代静默降级，呼应快速失败案例印证（case_instance）：印证：事件地图交叉核对声明点与派发点核验埋点可观测性信号采集可观测性信号采集（TEC-K-02）harness 源码架构…harness 源码架构解析（CAS-X-09）四大黄金信号监控方法四大黄金信号监控方法（MTH-K-03）可观测性信号关联方法可观测性信号关联方法（MTH-K-04）断路器与重试退避断路器与重试退避（TEC-K-01）服务等级目标与错误预算服务等级目标与错误预算（TEC-K-03）混沌工程实践混沌工程实践（TEC-K-04）无指责复盘实践无指责复盘实践（TEC-K-05）架构文档化方法架构文档化方法（MTH-G-05）质量属性战术映射方法质量属性战术映射方法（MTH-M-01）preset 通道耦合分…preset 通道耦合分析（CAS-X-05）视图与视角视图与视角（ESS-G-06）架构描述与对应关系架构描述与对应关系（ESS-G-07）服务等级目标方法服务等级目标方法（MTH-K-01）错误预算政策与燃尽率告警错误预算政策与燃尽率告警（MTH-K-02）事件响应与无指责复盘方法事件响应与无指责复盘方法（MTH-K-05）可用性战术应用可用性战术应用（MTH-M-03）混沌工程方法混沌工程方法（MTH-K-06）DORA 交付指标DORA 交付指标（TEC-K-06）可观测性本质可观测性本质（ESS-K-03）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 7 个直接邻接、外环 12 个二跳节点，共 20 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

可观测性不是把尽可能多的数据采集下来，而是让系统暴露足够信号以回答事先未预设的问题，即从系统外部输出推断其内部状态的能力。它与传统监控的区别在于问题类型：监控回答已知指标当前是否正常，可观测性回答未知未知以及为什么会这样。前提是应用已被正确埋点（instrumentation），否则任何后端都无法凭空还原系统行为。工程界把指标（metrics）、日志（logs）、追踪（traces）习称为三支柱，作为组织信号采集的通行框架；但真正决定可观测性上限的是信号之间能否被关联起来并支持高基数查询，而非采集了多少类信号。信号越能相互印证，越能从症状快速下钻到根因。可观测性的成熟度还体现在能否在事故中快速回答未曾预设的问题，这依赖于数据模型、关联标识与查询能力三者的配合；埋点应覆盖关键路径与错误分支，而非平均用力。

§4机制 · 如何运作

追踪（trace）由若干 span 组成，记录单个请求在微服务或无服务器架构中跨服务传播的路径，root span 覆盖请求从始到终，子 span 表示请求内的各步骤，用于定位分布式性能问题的根因。指标（metrics）是一段时间内的数值聚合，写入与查询成本低，适合长期观测与告警，但会丢失单个请求的细节。日志（log）是带时间戳的消息，结构化后可携带丰富上下文，适合记录离散事件与错误细节。三类信号通过 trace_id、span_id 等关联标识相互连接：通常从指标发现异常，用追踪定位到具体的慢调用或失败调用，再下钻到日志查找根因。事件与剖析（profiles）等信号正在扩展这一体系。可关联、高基数、可查询是支撑这套下钻链路的关键属性；当同一请求跨越同步调用与异步消息时，还需保证上下文在边界处正确传递，否则调用链会在队列处断裂而不完整。

§5工程 · 怎么落地

统一采用 OpenTelemetry 的 SDK 与 Collector 做埋点、处理与导出，避免厂商锁定并降低多语言接入成本；为每个请求建立并跨服务传播 trace context；日志结构化并携带 trace_id/span_id，使日志可被追踪串联。延迟等指标使用百分位（如 p99、p99.9）而非均值，因为延迟呈长尾分布，均值会掩盖尾部。设计采样策略以控制成本：尾部采样保留错误与慢请求，头部采样控制总量，并对关键路径提高采样率。把 traces、metrics、logs 汇聚到能够相互关联查询的后端，并对关键信号建立告警。埋点应作为代码的一部分被评审与测试，而非事后补丁，且需关注其运行时开销。对跨服务的异步消息与后台任务，也应传递并延续 trace context，避免追踪在消息队列处断裂，造成调用链不完整。

§6权衡卡

代价 · 风险

全量采集的存储、带宽与费用高昂，采样虽能降低成本却可能丢失关键细节，须在覆盖率与成本之间权衡。

三支柱是工程口语而非 OpenTelemetry 官方术语（OTel 列 Traces/Metrics/Logs/Baggage），成熟实践还扩展出 profiles、RUM 等信号，过度纠结术语数量会偏离信号可关联这一重点。

此外，埋点带来运行时开销，海量但不可关联的数据只会增加噪声与查询成本，反而降低可观测性。

高基数指标（如按用户 ID、请求 ID 打标）成本极高，标签维度设计不当会迅速推高费用。

采集策略需要随系统规模与业务重要性动态调整，定期复核哪些信号真正被使用，淘汰长期无人查询的埋点以控制成本。

原文要点
  • 可观测性也无法替代良好的架构与测试：缺少边界清晰的系统，再多的信号也难以推断行为。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7案例带

CAS-X-09 · 经 direct

harness 源码架构解析

对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。

CAS-X-01 · 2 跳派生：当前节点 → CAS-X-09 → MTH-G-05

去中心化聊天架构逆向

对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。

CAS-X-05 · 经 TEC-K-01

preset 通道耦合分析

对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。

CAS-X-10 · 2 跳派生：当前节点 → CAS-X-09 → MTH-G-05

dsh 插件依赖增量定位

以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。

CAS-X-13 · 2 跳派生：当前节点 → CAS-X-09 → MTH-G-05

Claude Code 架构逆向

以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。

CAS-X-15 · 2 跳派生：当前节点 → CAS-X-09 → MTH-G-05

Open Code Review 图谱

对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。

§8信源与核验

核验状态True（verified）
置信度high
复核日期2026-10-11
生命周期active
版本2026 (OpenTelemetry / Datadog)
规范信源VEN-026、VEN-027、BK-025
书证核验BK-025 ChBlack-Box Versus White-Box（direct），ChLatency（direct），ChThe Four Golden Signals（direct），ChWhy Monitor?（partial），ChWorrying About Your Tail (or, Instrumentation and Performance)（direct）；BK-026 ChDependencies（direct），ChIntended Changes（direct），ChPrefer Loose Coupling（direct），ChSaturation（direct），ChSources of Monitoring Data（direct），ChTesting Alerting Logic（direct）
入口链接https://opentelemetry.io/docs/concepts/observability-primer/　https://docs.datadoghq.com/service_management/service_level_objectives/
勘误
常见误解：可观测性三支柱是 OpenTelemetry 的官方术语
核验结论：OTel 官方列 Traces/Metrics/Logs/Baggage，并未使用三支柱措辞；三支柱是工程界通行口语，术语未统一　[VEN-026]
勘误
常见误解：可观测性就是尽可能多地采集指标、日志与追踪
核验结论：价值在于信号可关联并回答未知未知，而非数据数量；不可关联的海量数据反而增加噪声与成本　[VEN-027]

§9原始关系清单

展开：本节点的全部原始关系边（7 条，含边 ID 与方向）
关系方向对端节点说明
案例印证← CAS-X-09harness 源码架构解析
E-24		印证：事件地图交叉核对声明点与派发点核验埋点
组合← TEC-K-01断路器与重试退避
E-870		熔断与重试事件需被可观测信号捕获
促成→ TEC-K-03服务等级目标与错误预算
E-865		可观测信号使 SLO 可度量
促成→ TEC-K-04混沌工程实践
E-866		可观测稳态为混沌实验提供判据
促成→ TEC-K-05无指责复盘实践
E-872		可观测信号是事故复盘的时间线证据
实现→ MTH-K-03四大黄金信号监控方法
E-859		四大黄金信号的采集与呈现
实现→ MTH-K-04可观测性信号关联方法
E-858		可观测信号关联方法的技术实现

附对照资源 · 12factor 子库

12factor 节点关系对照说明
日志 app-logs跨体系对照日志即事件流，对应可观测性本质、黄金信号方法与信号采集技术
可观测性与错误可见性 t-observability跨体系对照传统日志与 Agent 错误压缩共同指向可观测性与信号采集