可观测性

三支柱：指标（metrics）是低成本的时序数字（QPS、延迟、错误率、资源水位），适合聚合看趋势与告警；日志（logs）记录离散事件细节，用于下钻定位具体原因；链路追踪（traces）记录请求跨服务传播的完整路径与每段耗时，回答「这次慢在哪个环节」。三者通过 exemplar、trace id 与日志注入关联成整体。与监控的区别：监控是预定义的问题集合（仪表盘加阈值告警），回答「系统是否正常、哪里不正常」；可观测性强调系统能被任意提问（尤其是没预料到的新问题），依靠高基数、高维度原始遥测数据支持临时探索，是 debug 能力而不只是看板能力。实践路径：先有核心指标与告警保命，再补结构化日志与 trace，把三者用统一语义约定（服务名、trace id）串起来。能讲「预定义对新问题」的区分即优秀。

Counter 只增不减的计数器（请求总数、错误数、字节流），重启归零要处理 rate 与 increase 的_counter 处理；求速率用 rate（平滑）或 irate（敏感），是计算 QPS 的基础。Gauge 可升可降的瞬时值（当前连接数、队列长度、内存占用、温度），直接采样。Histogram 把观测值分桶统计（响应时间按 le 桶的累积计数），服务端可聚合算分位数（histogram_quantile），支持跨实例聚合，代价是桶定义要预先设定，桶配置不当分位数不准。Summary 在客户端预计算分位数（带 quantile 标签），精确但不能跨实例聚合，多副本场景下算全局分位数失效，因此监控延迟推荐 histogram。选型口诀：发生次数用 counter、当前状态用 gauge、要分位数且可聚合用 histogram、单实例精确分位用 summary。能讲 histogram 与 summary 的聚合差异即满分。

架构组件：抓取器按配置周期拉取目标的 /metrics 端点（exporter 暴露指标：node_exporter、mysqld_exporter 与应用内嵌 client）；服务发现对接 Consul、Kubernetes 等动态发现目标；本地 TSDB 存储时序（按 series 组织，标签集唯一确定序列）；PromQL 查询引擎；Alertmanager 分组、抑制、静默与路由告警；联邦与 Thanos、vmagent 解决长期存储与水平扩展。选 pull 的理由：目标端只需暴露只读端点，抓取方控制抓取频率与目标清单，天然配合服务发现；健康语义直观——抓取失败即目标异常（up 指标），自带存活检测；易于调试（curl 即可看指标）与缓存与分层（联邦）；防止应用洪水推送压垮监控。代价：短生命周期任务（批处理作业）来不及被抓，用 pushgateway 做中转（只适合批任务，不适服务）；跨网络与防火墙需额外打通。能讲 pull 优点与 pushgateway 的定位即完整。

模型：trace 表示一次完整请求的调用树，span 是树上的一个操作（RPC 调用、DB 查询、一段计算），span 含 trace id、自身 span id、父 span id、开始结束时间、属性标签与状态。传播：跨进程时通过请求头传递上下文——W3C traceparent 标准（旧有 b3 头），下游延续同一 trace id 并建立父子关系，中间件与 RPC 框架（OpenTelemetry 各语言 SDK 自动埋点）负责注入与提取，异步与消息队列也要手动透传。采样：全量追踪成本高，头部采样在入口按比例决定（带 trace id 哈希），尾部采样在收集端看到结果再决定保留（错误与慢请求必保），权衡成本与排障价值。落地：SDK 或字节码增强埋点，OTLP 或 Jaeger 协议上报，后端 Jaeger、Zipkin、Tempo、SkyWalking 存储查询，与日志双向关联（日志打 trace id）。能讲 span 树、传播头、采样三段即达标。

原则：每条告警都要可行动（收到就知道该干什么），不可行动的告警（CPU 平时百分之八十）只是噪音；面向症状而非原因告警（用户影响的指标：错误率、延迟、可用性），原因类指标降为仪表盘或低级别提示；基于 SLO 与错误预算的告警——多窗口燃烧率（burn rate）在预算烧太快时预警，比静态阈值更贴合用户真实体验；分级（P0 电话、P1 即时通讯、P2 工单）配路由与升级策略（无人认领自动升级）；告警要带上下文（哪个服务、当前值、持续时间、runbook 链接），Alertmanager 的分组（同因告警合并）、抑制（机房宕机抑制其上所有服务告警）与静默（变更窗口）三件套用起来。度量告警质量本身：告警量、确认率、误报率、平均响应时长，季度复盘删除长期无人处理的告警。能讲症状优先加 SLO 燃烧率加分组抑制即优秀。