TL;DR · 本文用 100 个关键词构建可观测 / AI 可观测领域的拓扑地图——10 组、按"哲学 → 信号 → 协议 → 采集 → 存储 → 采样 → SLO → 告警 → 用户视角 → AI"逻辑排列。 · 写给：进入这个领域不超过两年、想快速建立全景的工程师；以及已经在领域内、想用这个地图做术语校准 / 选型决策 / 团队对齐的架构师。 · 不读会错过：词条之间的关系——光知道每个词的定义还不够，真正有用的是看懂"为什么 cardinality 决定 sampling 决定 cost"这种横跨多组的因果链。Notes: 行就是用来承载这种关系的。

阅读方式：① 通读建立全景；② 用作后续文章的术语速查；③ 看 Notes: 行——它们承担了这个领域"较难的地方在哪里"的信息密度。

必读 12 条（如果只读一遍）：#1 Observability · #6 Known/Unknown · #7 Wide Event · #9 Cardinality · #13 Histogram · #25 OpenTelemetry · #27 OTel Collector · #55 Cardinality Explosion · #57 Tail Sampling · #68 Error Budget · #88 LLM Observability · #99 GenAI Semantic Conventions。

mindmap
  root((可观测性
100 关键词))
    A · 元概念与哲学
      Observability
      Monitoring
      Wide Event
      Cardinality
      Known / Unknown
    B · 三支柱与变体
      Metric / Log / Trace
      Span / Baggage
      Exemplar
      Continuous Profiling
    C · 数据模型与协议
      OpenTelemetry
      OTLP
      Semantic Conventions
      Arrow
    D · 采集与传输
      Agent / Sidecar
      Push vs Pull
      eBPF
      Backpressure
    E · 存储与查询
      TSDB / 列存
      PromQL / LogQL / TraceQL
      Cardinality Explosion
      Tiered Storage
    F · 采样与归因
      Head / Tail Sampling
      RED / USE
      Four Golden Signals
    G · SLO 与可靠性
      SLI / SLO / SLA
      Error Budget
      MTTR / MTTD
    H · 告警与响应
      Alert Fatigue
      Symptom-based
      Runbook / Postmortem
      Blameless Culture
    I · 用户视角与边缘
      Black / White-box
      RUM / Synthetic
      eBPF
      Chaos / FinOps
    J · AI 可观测
      Prompt Tracing
      Token Accounting
      Hallucination Metric
      LLM-as-Judge
      Agent Trace / Trajectory
      RAG Observability

图 0·100 个关键词的拓扑总览。十组按"哲学 → 信号 → 协议 → 采集 → 存储 → 采样 → SLO → 告警 → 用户视角 → AI"的逻辑排列，从最抽象到最工程化、再回到 AI 时代的新边界。

A. 元概念与哲学（9 条）

1. Observability（可观测性） 1960 年 Kalman 在控制论中提出的系统性质：能否从外部输出推断内部状态。在工程领域被借用并扩展为"系统暴露足够多的信号让人能理解其行为"的实践。 Notes: 它原本是一个数学性质而非产品功能（参见 Kalman 1960 IFAC paper）；当代多数厂商已经把它窄化为"metrics + logs + traces"，与 Kalman 的原义有相当距离。L1-1 把这段历史完整展开。

2. Monitoring（监控） 持续测量系统的预定义指标并在偏离阈值时告警的实践。 Notes: 监控对付"已知问题"（known-unknowns），前提是你提前知道要问什么。它与可观测性的差别主要在询问方式的开放性。

3. Telemetry（遥测） 系统对外发出的描述自身状态的数据流的统称，是可观测性的"原材料"。

4. Instrumentation（埋点 / 插桩） 在应用代码或运行时中加入产生遥测信号的代码，分为手动埋点（开发者写）和自动埋点（agent / 库注入）。

5. Signal（信号） OpenTelemetry 用语，指一类遥测数据（trace / metric / log / profile / event）。 Notes: “信号"取代了"支柱”——它暗示这些数据是被观测对象的输出，而非独立的功能模块。

6. Known-unknowns / Unknown-unknowns（已知未知 / 未知未知） 前者：你知道该问什么问题（CPU 是不是高了）；后者：你不知道该问什么问题（为什么只有日本区的 iOS 14 用户在周三早上 timeout）。 Notes: Charity Majors 给出的可观测性 vs 监控的标志性区分；它是认识论问题，不是技术问题。

7. Wide Event（宽事件） 一条结构化事件记录，携带尽可能多的上下文字段（user、tenant、region、build、feature flag……）。 Notes: Honeycomb 提出的"反三支柱"主张（参见 Charity Majors Observability Engineering, O’Reilly 2022）——metrics、logs、traces 都可从宽事件派生；是"事件即真相、其余皆派生"的理论基础。L1-2 论证它正在赢。

8. Sociotechnical Observability（社会技术可观测性） 可观测性不只是技术系统的属性，还包括"谁在什么时间、为什么、看什么数据"的组织实践。 Notes: SLO、on-call 轮值、postmortem 都是社会技术构件；忽视这层是大多数公司"上了 Grafana 但没真正变得可观测"的根因。

9. Cardinality（基数） 一个 metric / 字段在所有时间序列中可能取的不同值的总数。 Notes: 它决定了存储成本的量级，并贯穿整个可观测体系的设计权衡——TSDB 结构、采样策略、聚合方案都是在"解释力 vs 基数代价"上做选择。

B. 三支柱与其变体（15 条）

10. Metric（指标） 在时间维度上对系统状态做数值聚合的信号，通常是 (name, labels, timestamp, value) 四元组。

11. Counter（计数器） 单调递增的累计指标，例如 HTTP 请求总数。重启或溢出后重置；查询时通常配合 rate() 等差分函数使用。

12. Gauge（仪表） 任意时刻可上下波动的瞬时值，例如内存使用量、队列长度。

13. Histogram（直方图） 将观测值分桶累计的分布型指标，常用于 latency 分布。 Notes: 经典 Prometheus histogram 的桶边界是静态的——选错边界会导致 p99 完全失真；OpenTelemetry 的 exponential histogram 用对数分桶解决了这个问题。

14. Summary（摘要） 在客户端预先计算分位数（p50 / p95 / p99）并上报的指标类型。 Notes: 比 histogram 节省存储但不可跨实例聚合——多副本的 p99 没法相加。生产中通常优先选 histogram。

15. Log（日志） 描述一次离散事件的文本记录，最古老也最不结构化的信号。

16. Structured Log（结构化日志） 以 JSON 或类似格式输出、字段可索引的日志。 Notes: 一旦日志结构化到极致，它就趋同于 wide event——这是"事件统一论"的工程证据。

17. Trace（追踪） 一次请求穿越多个服务时形成的完整因果链路，由多个 span 组成。

18. Span（跨度） Trace 的最小组成单元，描述一段有起止时间的工作（一次函数调用、一次数据库查询、一次 RPC）。

19. Span Event（Span 事件） 挂在 span 上的离散时间点事件（如"重试触发"“缓存未命中”），介于日志和 span 之间。

20. Span Link（Span 链接） 跨 trace 的弱因果引用，用于表达"这个 span 与另一个 trace 有关但不是父子关系"的场景，如批处理多个上游请求。

21. Baggage（携带载荷） 随 trace context 一起在服务间传递的键值对，可携带业务上下文（user_id、experiment_id）。 Notes: 强大但危险——baggage 容易膨胀 header、泄露敏感字段，需要白名单治理。

22. Context Propagation（上下文传播） 将 trace ID / span ID / baggage 通过协议头跨进程传递的机制，是分布式追踪能成立的前提。

23. Exemplar（样例点） 挂在 metric 数据点上的代表性 trace ID 引用，把一个 p99 数值直接链到产生它的那条 trace。 Notes: 它修补了"指标和追踪割裂"的旧问题——看到 p99 飙升不用再去日志里反查 trace ID。

24. Continuous Profiling（持续剖析） 持续采集生产环境的 CPU / 内存 / 锁 profile 并存储为时间序列。 Notes: 被部分人称作"第四支柱"。它是少数能回答"为什么慢"而不仅是"是不是慢"的信号。

C. 数据模型与协议（10 条）

25. OpenTelemetry（OTel） CNCF 旗下统一遥测数据 API、SDK、协议的开源标准，已经成为云原生可观测的事实标准底层。

26. OTLP（OpenTelemetry Protocol） OTel 定义的传输协议，基于 Protobuf 编码，支持 gRPC 和 HTTP。

27. OTel Collector（OTel 采集器） 可独立部署的代理进程，承担接收、处理（过滤 / 采样 / 富化）、转发遥测数据的角色。 Notes: 是"vendor 无关"的关键基础设施；把 SDK 和后端解耦后，更换可观测后端的迁移成本从几个月降到几小时。

28. Semantic Conventions（语义约定） OTel 对常见属性名的标准化规范（如 http.request.method、db.system），保证不同语言、不同库产生的数据可以互通查询。

29. Resource（资源） 描述遥测数据来源实体的属性集（service.name、k8s.pod.name、cloud.region），与具体 span / metric 解耦。

30. Attribute（属性） 挂在 span / metric / log 上的键值对，是可观测查询和过滤的基本维度。

31. Prometheus Exposition Format（Prometheus 暴露格式） Prometheus 拉取指标时使用的纯文本格式，每行 metric_name{labels} value timestamp。 Notes: 简单、自描述、人可读，是它能成为事实标准的重要原因。

32. OpenMetrics 在 Prometheus 暴露格式基础上扩展并形式化的标准化尝试（CNCF 沙箱项目，曾提交为 IETF 草案），增加了 exemplar、UNIT 等字段。

33. StatsD 早期的指标推送协议，UDP 上的简短文本格式（metric:value|type），如今仍在大量遗留系统中存在。

34. Apache Arrow 列式内存数据格式；OTel Arrow 协议用它替换 Protobuf 来传输大批量遥测数据，可显著降低带宽和 CPU。

D. 采集与传输（9 条）

35. Agent（采集代理） 部署在主机或 Pod 上的独立进程，负责收集遥测数据并转发到后端。

36. Sidecar（伴生容器） 在 Kubernetes Pod 内与应用容器并存的辅助容器，常用于以"零代码侵入"方式提供可观测能力。

37. DaemonSet Kubernetes 中每节点一个的部署模式，是节点级日志 / 指标采集器的典型形态。

38. Push vs Pull（推 vs 拉） 应用主动把数据推送给后端 vs 后端定期来抓取。 Notes: 在云原生 metrics 领域，pull（Prometheus）赢了模式之争——服务发现集成、健康检查副作用、配置中心化都是 pull 的优势；但在 logs / traces 领域 push 仍是默认。

39. Scrape（抓取） Prometheus 式 pull 模型中定期访问目标端点拉取指标的动作。

40. Remote Write（远程写入） Prometheus 将本地存储的指标转发到远端（如 Mimir、VictoriaMetrics、Thanos）的协议。

41. Batching（批处理） 将多条遥测数据合并为一次网络请求发送，是降低传输开销的基本手段。

42. Backpressure（背压） 当后端处理速率跟不上数据产生速率时，向上游反馈以减慢生产的机制。 Notes: 缺乏背压的可观测管道会在事故中放大事故——业务慢导致日志堆积，日志堆积压垮 collector，进一步影响业务。

43. eBPF Linux 内核中的可编程沙箱，允许在不修改应用的前提下采集进程、网络、系统调用级数据。 Notes: 是"零代码侵入观测"的新一代基础设施，Pixie、Cilium、Parca 都构建在它之上。

E. 存储与查询（12 条）

44. TSDB（时间序列数据库） 针对时间戳排序数据优化的存储系统，以高写入吞吐和按时间范围扫描见长。

45. Columnar Store（列式存储） 按列而非按行组织数据的存储格式，对聚合查询和压缩极其友好。 Notes: ClickHouse、Apache Doris、DuckDB、Arrow 等系统让"日志即列式表"成为新一代日志栈的主流路线；Doris 在高并发查询、Join 性能、MySQL 协议兼容上明显优于 ClickHouse，ClickHouse 则在单查询大表扫描的极限速度上更强——两者在可观测后端的选型里互为补集而非替代。

46. Inverted Index（倒排索引） 从词项映射到文档的索引结构，是 Elasticsearch / Loki 这类全文 / 标签检索的核心。

47. LSM Tree（日志结构合并树） 多层有序文件 + 后台合并的存储结构，写入快、读取需合并多层；Cassandra、RocksDB、HBase 是典型实现，Prometheus TSDB 的"WAL + 不可变 block + 后台 compaction"结构亦从中借用了思想。

48. Tiered Storage（分层存储） 近期数据存本地高速盘、历史数据下沉到对象存储（S3）的架构，是可观测数据降本的核心手段。

49. Downsampling（降采样） 将高频原始数据按更长时间窗口聚合（每分钟变每小时）以节省存储。

50. Retention（保留期） 遥测数据被保留多久的策略；通常 metrics 周到月、logs 几天到几周、traces 几小时到几天。

51. Compaction（合并 / 压实） 将多个小数据块合并为更大块的后台作业，存储引擎的"垃圾回收"。

52. PromQL Prometheus 的查询语言，以时间序列代数（区间向量、瞬时向量、函数）为核心。

53. LogQL Grafana Loki 的查询语言，语法借鉴 PromQL，但作用对象是日志流。

54. TraceQL Grafana Tempo 的查询语言，用于按 span 属性、时长、关系筛选 traces。

55. Cardinality Explosion（基数爆炸） 高基数标签（如 user_id、request_id）导致时间序列数量指数级膨胀，最终拖垮 TSDB。 Notes: 它是 TSDB 运维事故的头号原因；多数生产事故源于一个新上线的 label 没人意识到会带高基数。

F. 采样与归因（9 条）

56. Head Sampling（头部采样） 在 trace 起点根据预设比例决定是否记录整个 trace。 Notes: 简单、无状态，但盲点很大——你在 trace 开始时不知道它会不会出错。

57. Tail Sampling（尾部采样） Trace 完整结束后根据其最终特征（是否出错、超时、含关键 span）决定是否保留。 Notes: 解决头采样的盲点，但需要在 collector 缓存完整 trace、内存开销大、跨节点协调复杂。

58. Probabilistic Sampling（概率采样） 按固定概率随机保留 trace 的最常见方案。

59. Adaptive Sampling（自适应采样） 采样率根据流量、错误率、延迟动态调整，目标是低流量时全采、高流量时只采异常。

60. RED Method 服务级监控的三个指标：Rate（请求量）、Errors（错误率）、Duration（延迟）。

61. USE Method 资源级监控的三个指标：Utilization（利用率）、Saturation（饱和度）、Errors（错误数）。 Notes: RED 看服务、USE 看资源；两者互补而非互斥。Brendan Gregg 提出 USE 时明确指出它针对硬件资源。

62. Four Golden Signals（四大黄金信号） Google SRE 书提出的：Latency、Traffic、Errors、Saturation。 Notes: 它是 RED 和 USE 的并集；在"应该监控什么"的所有框架里被引用最多。

63. Exemplar Trace（样例追踪） 通过 exemplar 机制从某条指标数据点反查到的代表性 trace。

64. Trace Context（追踪上下文） W3C 标准化的 trace ID / parent span ID / flags 头部规范（traceparent、tracestate），是跨厂商互通的基础。

G. SLO 与可靠性语言（8 条）

65. SLI（Service Level Indicator，服务等级指标） 用于衡量服务质量的可量化指标，如"成功响应比例"“p99 延迟”。

66. SLO（Service Level Objective，服务等级目标） 对 SLI 设定的目标值（如"99.9% 的请求在 300ms 内返回"），是组织内部承诺。

67. SLA（Service Level Agreement，服务等级协议） 对外签订的合同性可靠性承诺，违约通常伴随赔偿。 Notes: SLA 一般比 SLO 宽松一档——内部承诺严于外部承诺，否则失去缓冲。

68. Error Budget（错误预算） 1 − SLO 的差额，可被消耗的"允许不可靠"的份额。 Notes: Error budget 是 SRE 体系最关键的发明——它把可靠性从"越高越好"的道德问题变成了可交易的工程资源。

69. Burn Rate（消耗率） Error budget 被消耗的速度，常用于多窗口多阈值告警。

70. Toil（重复劳动） 手工的、可自动化的、无长期价值的运维工作，Google SRE 主张将其控制在 50% 以下。

71. MTTR / MTTD（平均恢复时间 / 平均检测时间） 分别衡量从故障开始到检测到、从检测到到恢复的耗时。

72. Reliability（可靠性） 系统在给定条件下、给定时间内提供正确服务的概率；与"可用性"（uptime）的区别在于它关心正确性而非仅仅在线。

H. 告警与事件响应（8 条）

73. Alert（告警） 当指标越过阈值或 SLO 被违反时产生的通知。

74. Alert Fatigue（告警疲劳） 告警过多、误报过多导致 on-call 工程师对告警的敏感度下降。 Notes: 它是 on-call 体系崩坏的最早信号；治理路径是"告警必须可操作、必须有 runbook、无效告警必须删"。

75. Symptom-based Alerting（症状型告警） 针对用户感知到的现象（错误率上升、延迟超 SLO）告警，而非内部状态（CPU 高）。 Notes: Google SRE 强力推崇——它对应 SLO，避免"内部抖动但用户没事"的噪音告警。

76. Cause-based Alerting（原因型告警） 针对内部状态异常（磁盘满、连接池耗尽）告警的传统模式。

77. Runbook（应急手册） 针对某类告警的处置步骤文档，理想情况下每个告警都应配一个 runbook。

78. Incident（事件） 达到一定严重程度、需要协调响应的故障；通常有 severity 分级（P0 / P1 / P2 / P3）。

79. Postmortem（事后复盘） 事故结束后对原因、时间线、影响、改进项的结构化文档。

80. Blameless Culture（无指责文化） 复盘聚焦系统与流程缺陷而非个人过失的组织规范。 Notes: 它是一项工程治理选择，不是道德姿态；目的是让人愿意说出真相，让系统能从事故中真正学到东西。

I. 用户视角与边缘观测（7 条）

81. Black-box vs White-box Monitoring（黑盒 vs 白盒监控） 黑盒从外部探测系统行为（HTTP probe）；白盒读取系统内部状态（内存、队列长度）。 Notes: 两者互补——黑盒告诉你"用户看到什么"，白盒告诉你"为什么"。只有黑盒会错过慢请求成因，只有白盒会错过 DNS / TLS / CDN 层故障。

82. Synthetic Monitoring（合成监控） 用脚本模拟用户行为定期访问服务，主动产生流量来探测可用性和性能。

83. RUM（Real User Monitoring，真实用户监控） 在用户浏览器或 App 中埋点采集真实用户的性能、错误、行为数据。

84. Distributed Tracing（分布式追踪） 跨服务、跨进程、跨网络的请求追踪实践，是微服务架构下定位问题的核心手段。

85. Service Mesh Observability（服务网格可观测） 通过 Istio / Linkerd 等 sidecar 代理在网络层透明采集服务间调用的指标和 traces。 Notes: 优点是零侵入；缺点是只能看"服务之间"，看不到服务内部，且 sidecar 自身是新的故障源。

86. Chaos Engineering（混沌工程） 主动注入故障以验证系统韧性和可观测覆盖的实践，由 Netflix 推动成熟。 Notes: 它与可观测性互为前提——没有充分可观测，注入故障只会制造事故；没有混沌注入，可观测覆盖永远不知道是否够用。

87. FinOps for Observability（可观测的成本治理） 针对可观测数据本身的成本管理——它的边际成本在大型组织里可以占到云开支的 5–15%。 Notes: 是近三年从 SRE 实践中分化出来的新方向；常见手段包括基数审计、log volume 治理、retention 分级、采样率分租户。

J. AI 可观测（13 条）

88. LLM Observability（LLM 可观测性） 针对大语言模型应用（单次推理、Agent、RAG）的端到端可观测实践，记录对象从"系统状态"扩展到"模型行为、输入语义、输出质量"。 Notes: 传统三支柱回答"系统在做什么"；LLM 可观测必须回答"模型在想什么、说得对不对、花了多少钱"——这三问只有最后一问能套用旧工具。

89. Prompt Tracing（提示词追踪） 将每次 LLM 调用的完整 prompt（含 system / user / assistant / tool 角色、模板版本、注入的上下文片段）作为一个 span 持久化。 Notes: LLM 应用的 bug 九成出在 prompt 而非代码，没有 prompt trace 等于在没日志的服务里调 bug。

90. Token Accounting（Token 计量） 按调用、链路、用户、租户维度聚合输入 / 输出 token 数及对应成本。

91. Hallucination Metric（幻觉指标） 量化模型输出中无事实依据或与给定上下文矛盾内容比例的指标族，常见实现包括 grounding score、faithfulness、citation accuracy。 Notes: 它把"模型胡说"从工程师的主观感受变成可上报、可告警的数字；但与 latency 不同，幻觉是依赖判定者的指标——你怎么测，决定你看到什么。

92. Online Eval（在线评估） 在生产流量上对 LLM 响应做实时 / 准实时的质量评估，结果作为可观测信号入库。

93. Offline Eval（离线评估） 在固定数据集（黄金集、回归集）上批量评估 prompt / 模型 / 检索策略变更的效果，通常在 CI 或发布流程中运行。

94. LLM-as-Judge（以模型为裁判） 用一个 LLM 给另一个 LLM 的输出打分（正确性、相关性、安全性等）。 Notes: 当"事实正确性"无法用传统 metric 表达时，它是目前主流但有争议的替代方案——便宜可扩展，但裁判模型本身会出错、有偏见，且打分随模型版本漂移。

95. Embedding Drift（嵌入漂移） 用户输入或文档库的 embedding 分布随时间偏离基准分布。 Notes: RAG 系统里 drift 是"昨天还好用的检索今天突然乱召回"的根因；它是 L4 里少数能直接套用传统"数据漂移"理论的概念，但距离度量和基线选择本身就是开放问题。

96. Agent Trace（Agent 执行轨迹） 一次 Agent 任务的完整执行链路：思考、工具调用、子 Agent 分发、状态转移、最终输出，通常表示为有向树或图。 Notes: Agent 是多步、有状态、可分支的执行系统，传统 distributed trace 模型对它太弱——树状 trace 无法表达 ReAct 循环和 reflection 回溯。

97. Tool Call Span（工具调用 Span） Agent 调用外部工具（搜索、代码执行、数据库查询、子 Agent）时产生的 span，承载工具名、参数、返回值、错误。

98. RAG Observability（检索增强可观测） 针对 retrieve → rerank → generate 三段管道的端到端观测，关键观测点为召回 chunk 列表、相似度分数、最终被引用的 chunk。 Notes: RAG 系统的回答质量瓶颈通常不在生成阶段而在检索阶段；没有完整的检索可观测，工程师只能盯着"答得不好"的最终输出却找不到根因。

99. GenAI Semantic Conventions（生成式 AI 语义约定） OpenTelemetry 社区为 LLM / Agent / RAG 调用定义的标准属性集（如 gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens）；规范托管于 github.com/open-telemetry/semantic-conventions，截至 2026-06 仍在 experimental → stable 推进中。 Notes: 它正在把碎片化的厂商规范（Langfuse、LangSmith、Phoenix 各一套）收敛到统一 OTel 数据模型；采不采用它，决定了你三年后的可观测栈能不能跨厂商迁移。L4-3 / L4-10 详细讨论。

100. Trajectory & Replay（轨迹与回放） Trajectory 是 Agent 在一次任务中走过的 (state, action, observation) 序列（借自强化学习）；Replay 基于记录的 prompt / context / tool response 重新执行任务以复现行为。 Notes: LLM 系统的非确定性让传统 debugging 失效——你不能"重启服务再跑一遍"。Trajectory 是 Agent 评估的基本单位，Replay 是 LLM 时代调试的核心工具，但完整 replay 需要冻结模型版本 + 温度 + 工具响应，工程上不便宜。

横跨多组的因果链

下面几条因果链横跨多组概念。读懂它们，会比记住 100 条孤立定义更有用：

  1. #9 Cardinality → #55 Cardinality Explosion → #44 TSDB → #45 Columnar Store → #48 Tiered Storage → #87 FinOps 高基数推动 TSDB 选型，TSDB 局限推动列存兴起，列存推动分层存储，分层存储推动成本治理——这一条贯穿 E 组和 I 组。

  2. #56 Head Sampling → #57 Tail Sampling → #23 Exemplar → #17 Trace 头采样的盲点导致尾采样的发明，尾采样的代价导致 exemplar 这种"采得少但能反查"的机制——这一条解释为什么 OTel Collector 越来越复杂。

  3. #7 Wide Event → #25 OpenTelemetry → #28 Semantic Conventions → #99 GenAI Semantic Conventions 宽事件理论 → OTel 协议化 → 属性标准化 → 延伸到 LLM 调用——这一条是 L4 系列的理论主干。

  4. #65 SLI → #66 SLO → #68 Error Budget → #69 Burn Rate → #74 Alert Fatigue → #75 Symptom-based Alerting SLI/SLO 概念 → error budget 资源化 → burn rate 触发告警 → 告警过多导致 fatigue → 用 symptom-based 治理——这一条是 SRE 体系的工程化路径，L3 主线。

  5. #88 LLM Observability → #89 Prompt Tracing → #96 Agent Trace → #100 Trajectory & Replay LLM 可观测 → prompt 追踪 → Agent 执行轨迹 → 轨迹回放——这一条勾勒了 AI 可观测的演化路径，L4 全系列展开。

接下来

这 100 个概念是后续四篇 L1 文章的"零件库"：

  • L1-1 《可观测性的原始定义：从 Kalman 到 Honeycomb》 主要使用 1、2、5、6、7、8 号概念。
  • L1-2 《“三支柱"是一个误导的框架》 主要使用 7、10、15、17、24 号概念。
  • L1-3 《基数、采样与认识论：你不可能记录全部》 主要使用 9、13、55、56、57、59 号概念。
  • L1-4 《当被观测对象是 LLM：可观测性理论需要重写吗？》 主要使用 J 组（88–100）全部。

主要参考

  • Kalman, R. E. (1960). On the General Theory of Control Systems. IFAC Congress.
  • Beyer, B., et al. (2016). Site Reliability Engineering. Google / O’Reilly——SLI / SLO / Error Budget / Four Golden Signals 等概念的原始出处。
  • Bourgon, P. (2017). Metrics, tracing, and logging. peter.bourgon.org——三支柱韦恩图原始来源。
  • Sridharan, C. (2018). Distributed Systems Observability. O’Reilly Report.
  • Gregg, B. USE Method. brendangregg.com——USE 方法原始定义。
  • Majors, C., Fong-Jones, L., Miranda, G. (2022). Observability Engineering. O’Reilly——宽事件论的最完整阐述。
  • OpenTelemetry Specification & Semantic Conventions. opentelemetry.io.
  • OpenTelemetry GenAI Semantic Conventions. github.com/open-telemetry/semantic-conventions——AI 可观测部分的标准化基准。