想象凌晨三点的急诊室：一位患者被推进来，主治医生桌上摆着三样东西——一张画满体温、心率曲线的体征单，一本按时间记录的护理日志，一张标着每个检查步骤耗时的手术流程单。体征单告诉他“情况在恶化”，护理日志告诉他“两点十分开始呕吐、咳血”，流程单告诉他“从抽血到CT出结果花了整整40分钟，其中排队占了35分钟”。任意一份档案都说不清全貌，但三份放在一起，症状、原因、路径就拼成了一个完整的故事。 这套思路搬到软件系统，就是“可观测性”（Observability）。传统监控只回答“系统挂了没”，可观测性要回答“系统为什么变成这样、它是怎么一步步走到这里的”。行业把观测数据分为三大支柱——Metrics（指标）、Logs（日志）、Traces（链路），再用统一视角把它们关联成一张完整的“病情地图”。本文就用急诊室这个比喻，带你认识三大支柱、统一视角，以及 SRE 如何靠它们守住系统健康。

岗位关联

可观测性是 SRE 与云原生工程师的核心技能：学会构建三大支柱并打通统一视角，你就能在线上故障中从“猜”变成“看”，把定位时间从小时级压到分钟级。

目录
  1. 可视化演示
  2. 三大支柱概述
  3. Metrics指标
  4. Logs日志
  5. Traces链路
  6. 统一视角
  7. SRE实践
  8. 落地实战
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示日志、指标、追踪三大支柱汇聚为统一视角，展示跨信号关联查询与根因定位的过程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三大支柱 日志/指标/追踪三路信号 支柱=信号采集的独立维度 三者互补组成完整可观测性。

三大支柱概述

假设你是急诊室主治医生，患者被推进来时，你桌上摆着三份档案：一张画满体温心率曲线的体征单，一本按时间记录的护理日志，一张标着每个检查步骤耗时的手术流程单。只看体征单，你知道情况不稳定，却不知道是感染还是出血；只看护理日志，你知道三小时前开始呕吐，却不清楚整体恶化趋势；只看流程单，你知道CT排队花了35分钟，却不明白为什么需要做CT。三份档案拼在一起，你才能在几分钟内形成完整判断。

软件系统遇到线上故障时，工程师面临的正是同样的困境。我们把这种“从外部输出推断内部状态”的能力称为可观测性（Observability）。它不等于传统监控——监控回答“系统挂了没”，可观测性回答“系统为什么变成这样”。2017年，OpenTracing 社区提出“三大支柱”概念：Metrics、Logs、Traces，分别对应医院里的体征单、护理日志和流程单。

三大支柱各司其职：Metrics 是定期数值采样，反映长期趋势、触发告警，像每半小时量一次的体温；Logs 是离散事件记录，信息最丰富也最嘈杂，像护理日志里每一条“几点几分发生了什么”；Traces 记录一个请求穿越多个服务的完整路径，像一张盖满时间戳的检查流程单，能把“慢”精确到具体环节。三者不是替代关系，而是不同颗粒度、不同成本下的互补。

就像急诊医生从三份档案中还原病情全貌，现代可观测性平台把这三份“档案”按同一时间轴摆在一起，让工程师能问出新问题：“这个延迟尖峰发生时，日志里发生了什么？这条慢请求经过了哪几个服务？”——这正是后面各节要展开的能力。

O=f(M,L,T)\displaystyle \mathcal{O} = f(M, L, T)
可观测程度 $\mathcal{O}$ 是三类信号的综合函数：仅凭任何一类，都无法回答“系统为什么变成这样”。
  1. 可观测程度 $\mathcal{O}$表示系统可从外部推断内部状态的能力，数值越高，定位问题越快。
    O\displaystyle \mathcal{O}
  2. 综合理解函数 $f$工程师或平台把三类信号相互印证、还原因果的过程。
    f\displaystyle f
  3. 三类信号 $M, L, T$Metrics 的定期采样、Logs 的事件记录、Traces 的请求路径，三者缺一不可。
    M,  L,  T\displaystyle M,\;L,\;T

Metrics指标

护士每半小时量一次体温、血压、心率，填进同一张表格。检查单上一行行简洁的数字，生成快、存储省、趋势一眼可见——这就是指标的风格：小而密，适合长期跟踪与自动告警。指标（Metrics）是系统在某一时刻的数值快照，以时间序列形式持续采集。

常见指标有四类，对应四种“仪表”。Counter 是只增不减的计数器，类似手机计步器，适合统计请求总数；Gauge 是可增可减的瞬时值，类似汽车仪表盘，适合当前内存占用；Histogram 统计数值分布，类似医院统计患者年龄分布，适合延迟分位数；Summary 是客户端计算好的摘要，类似考试平均分与排名。采集端以 Prometheus 的 pull 模型为代表，每隔固定时间从各服务抓取指标，存入时序数据库，用 PromQL 之类语言查询。

指标格式小、查询快，是三大支柱中最“便宜”的数据。但有个经典陷阱：高基数问题。标签组合一旦爆炸——比如把请求 URL 的每个参数都做成标签——存储和查询都会被拖垮。好比在病历上给每个病人又按“鞋码、发色、出生地”各建一份索引，索引比病历还厚。

体温单能告诉你“病情在恶化”，却不知道“为什么恶化”。指标的作用是快而准地划出问题区域，若要深挖原因，就要翻开下一份档案——日志。

ApdexT=S1+0.5×S2S1+S2+S3\displaystyle \text{Apdex}_T = \frac{S_1 + 0.5 \times S_2}{S_1 + S_2 + S_3}
Apdex 是“应用性能满意度”指标，把用户分为满意、容忍、失望三档，加权计算出一个 0 到 1 的分数。
  1. 目标阈值 $T$用户可接受的响应时间上限，例如 500 毫秒。
    T=500 ms\displaystyle T = 500\ \text{ms}
  2. 满意样本 $S_1$响应时间不超过 $T$ 的请求数，记为满分。
    S1=#{t≤T}\displaystyle S_1 = \#\{t \le T\}
  3. 容忍样本 $S_2$响应时间在 $T$ 与 $4T$ 之间，只算半分。
    S2=#{T<t≤4T}\displaystyle S_2 = \#\{T < t \le 4T\}
  4. 满意度得分 $\text{Apdex}_T$加权后得到一个 0 到 1 之间的分数，越接近 1 体验越好。
    ApdexT\displaystyle \text{Apdex}_T

Logs日志

护理记录本上，每一条都写着时间、护士签名和事件：“19:30 患者呕吐”“20:00 体温升高”“20:30 换药”。它详细真实，但翻起来费劲，也没法一眼看出趋势。日志（Logs）正是这样：完整但嘈杂。每条日志是一条带时间戳的事件记录，说明“某时某服务发生了什么”。

早期日志是非结构化散文，机器难以处理。于是出现了结构化日志：把信息组织成字段——时间、级别、服务名、traceID、业务字段，像护理记录单画好了格子，每格填固定内容。traceID 尤其关键：它能在日志与链路之间架起第一座桥，让“某条日志”和“某次请求”对上号。

日志从产生到可用要经过“采集管道”：Fluentd、Logstash 等采集器负责收集，缓冲后送入 Elasticsearch、Loki 等存储，再通过检索引擎查询。日志的问题是成本高：量大、占空间、检索慢，因此要分级存储与定期归档，并用级别过滤缩小检索范围。

护理记录能还原细节，但若没有体征单上的异常提示，你根本不知道要翻哪几页。日志必须由指标引导方向、被链路串起坐标，才真正发挥价值。

SNR=NusefulNtotal=1−NnoiseNtotal\displaystyle \text{SNR} = \frac{N_{\text{useful}}}{N_{\text{total}}} = 1 - \frac{N_{\text{noise}}}{N_{\text{total}}}
信噪比衡量日志的价值：有效日志占比越高，排障时越容易发现真相；噪声过多会让检索变成大海捞针。
  1. 有效日志数 $N_{\text{useful}}$真正有助于定位问题的事件，例如异常堆栈、超时记录。
    Nuseful\displaystyle N_{\text{useful}}
  2. 噪声日志数 $N_{\text{noise}}$重复的“一切正常”、调试噪音等无用信息。
    Nnoise\displaystyle N_{\text{noise}}
  3. 信噪比 $\text{SNR}$有效日志占全部日志的比例。结构化、带级别、可过滤的日志能显著提升信噪比。
    NusefulNtotal\displaystyle \frac{N_{\text{useful}}}{N_{\text{total}}}

Traces链路

一次血液检查，从开单、抽血、送检、离心、上机到出报告，每个环节都盖着时间戳。报告出晚了，一看流程单就知道：送检环节等了40分钟。在微服务系统里，一次用户请求也会穿过网关、订单、支付等多个服务——链路（Trace）就是这张盖满时间戳的流程单。

分布式追踪（Distributed Tracing）把一次请求经过的所有服务节点串成一条链。最基本的单元叫 Span（跨度），代表请求中的一段工作区间：发起一次数据库查询、调用一次下游接口，都对应一个 Span。每个 Span 记录操作名、开始与结束时间、父 Span 的 ID；所有 Span 通过同一个 traceID 串联成树形结构。

跨服务传递上下文是关键：上游服务在 HTTP 头中注入 traceID 与 spanID，下游取出并继承，W3C Trace Context 是通行标准。采样策略决定记录多少链路——头部采样在入口按概率抽取，尾部采样按结果（如是否出错）决定保留，生产中常用“固定概率 + 错误全采样”的混合方案。100% 采样的成本极高，通常只在低流量时开启。

流程单能精确指出“血样在送检环节闲置了40分钟”，这是指标和日志给不了的坐标。链路给故障定位装上瞄准镜：先锁定环节，再翻对应日志。

Ttotal=∑i=1ntiwork+∑i=1ntiwait\displaystyle T_{\text{total}} = \sum_{i=1}^{n} t_i^{\text{work}} + \sum_{i=1}^{n} t_i^{\text{wait}}
一次请求的总耗时等于所有环节自身处理时间与排队等待时间之和。链路的价值，就是把“总耗时”拆成“每一段的耗时”。
  1. 总耗时 $T_{\text{total}}$用户感知到的整个请求时长。
    Ttotal\displaystyle T_{\text{total}}
  2. 处理时间 $t_i^{\text{work}}$第 $i$ 个环节真正干活的时间，例如执行 SQL。
    tiwork\displaystyle t_i^{\text{work}}
  3. 等待时间 $t_i^{\text{wait}}$第 $i$ 个环节排队、网络传输等非工作时间。
    tiwait\displaystyle t_i^{\text{wait}}

统一视角

多科室会诊的会议室里，主治医生把三份档案按时间轴贴满一面白墙：左侧是体征曲线，中间是护理日志，右侧是流程单。对齐之后剧情完整了——19:30 呕吐、20:00 发烧、20:20 CT 排队、20:35 体温升高、20:40 结果出来。同一时间段的三类证据相互印证，复杂的病情瞬间有了脉络。

统一视角（Unified View）就是把三大支柱组织在同一时间轴与同一套关联体系下，包含三件事：时间对齐、ID关联、平台联动。时间对齐让三类数据在同一个图表里并排展示；ID关联让 traceID、日志里的 requestID、指标上的标签组能互相指向；平台联动让工程师从一条指标异常，一键跳转到相关日志与链路。

现代可观测性平台（如 Grafana 全家桶、Datadog、SkyWalking）都在做这件事。落地的形态大致是：统一时间轴作为横坐标；链路的 traceID 自动注入日志字段；告警事件关联到对应时间窗口的 Traces 与 Logs；三类数据共享统一查询语言（LogQL、TraceQL）。开源的 LGTM 栈（Loki + Grafana + Tempo + Mimir）是云原生领域的热门选择。

三份档案躺在三个主任的抽屉里，会诊无从谈起；只有贴在同一面墙上，医生们才能指着同一个时间点说“就是这里”。统一视角让三大支柱从“三份孤立数据”变成“一张病情地图”。

τ:M∪L∪T→T\displaystyle \tau: M \cup L \cup T \rightarrow \mathcal{T}
统一视角本质是一个对齐函数：把指标记录、日志事件、链路片段全部映射到同一条时间轴，让它们可以对齐比较。
  1. 对齐函数 $\tau$为每条观测记录标注统一时间戳与关联 ID 的操作。
    τ\displaystyle \tau
  2. 三类数据集合 $M \cup L \cup T$指标、日志、链路的全体记录。
    M∪L∪T\displaystyle M \cup L \cup T
  3. 统一时间轴 $\mathcal{T}$三者在同一坐标上，异常窗口内可横向对照。
    T\displaystyle \mathcal{T}

SRE实践

医院里有一个不直接看病的质控科：它定义标准——门诊平均等待不超15分钟、术后感染率低于1‰，每月统计指标、分析差距、推动整改。SRE（站点可靠性工程）就是软件系统的质控科。它把可靠性变成可量化的工程：用 SLI（服务等级指标）度量“服务有多好”，用 SLO（服务等级目标）规定“应该有多好”。

错误预算（Error Budget）是允许出错的额度，等于 1 减去 SLO。SLO 定 99.9%，一个月就只允许约 43 分钟不可用；额度花完，就停止上线新功能，先还可靠性债。可观测性为 SLI 提供真实测量——指标负责测量，日志解释偏差，链路定位瓶颈，三支柱是这个闭环的数据底座。

Google SRE 手册提出四个黄金信号：延迟、流量、错误、饱和度。落地时拆成具体指标：延迟看 P50/P95/P99 分位，流量看 QPS 或并发连接，错误看错误率与类型，饱和度看 CPU、内存、连接池水位。告警治理要避免“狼来了”：告警必须可执行、去重、按优先级分级，并围绕 SLO 设置燃烧率告警，而不是堆砌噪声。

质控科必须手持三份档案才能做季度复盘——指标暴露偏差，日志解释原因，链路定位环节。三大支柱在 SRE 手里不是装饰品，而是驱动可靠性改进的数据引擎。

EB=(1−SLO)×30×1440=43200×(1−SLO) 分钟\displaystyle \text{EB} = (1 - \text{SLO}) \times 30 \times 1440 = 43200 \times (1 - \text{SLO})\ \text{分钟}
一个自然月按 30 天共 43200 分钟计算：SLO 99.9% 时，错误预算约 43.2 分钟，这是“允许出错”的底线。
  1. 服务等级目标 $\text{SLO}$用百分比定义可靠性，例如 99.9%。
    SLO\displaystyle \text{SLO}
  2. 每月总分钟数 $30 \times 1440$三天不为约，把百分比换算成可感知的时间。
    43200\displaystyle 43200
  3. 错误预算 $\text{EB}$允许出错的分钟数，花完即触发“停止发布、优先修复”机制。
    (1−SLO)×43200\displaystyle (1 - \text{SLO}) \times 43200

落地实战

医生最怕看到字迹潦草、字段不齐的病历：“患者三小时前不适”——到底几点？哪个护士签的字？没有统一规范的档案，再贵的检查设备也白搭。可观测性落地的成败，七成在数据规范本身。第一守则是标准化埋点：统一服务名、统一标签命名、统一日志级别字段，用 OpenTelemetry 这类标准 SDK 打点，避免每个团队自造一套命名法。

第二守则是成本控制：链路做概率采样、日志按级别和时效分层存储（热存 7 天、温存 30 天、冷归档一年以上）、指标控制标签基数。第三守则是数据质量：上线前校验字段是否齐全、指标是否有单位、traceID 是否贯穿日志。第四守则是安全合规：脱敏敏感字段（手机号、身份证），控制日志的访问权限，防止可观测性平台成为数据泄露的突破口。

OpenTelemetry 提供了埋点、传播、导出的统一标准，被云原生生态广泛接受。成本优化思路围绕四个变量展开：减量（采样与过滤）、压缩、降冗余、分级保留。数据质量则要用“信任度”指标度量，例如字段完整率、traceID 关联率，定期巡检并纳入告警。

档案室制度越严格规范，急诊会诊就越快越准。可观测性工程最终拼的是“数据纪律”——把三类信号的产生、采集、关联都当成基础工程来建设。

Costtotal=∑t=1R(Vt×St×F)\displaystyle \text{Cost}_{\text{total}} = \sum_{t=1}^{R} \left( V_t \times S_t \times F \right)
存储成本 = 每天数据量 × 单价 × 冗余系数，再对保留天数求和。降本的本质是让这四个变量变小。
  1. 每天数据量 $V_t$第 $t$ 天新增的日志/指标/链路数据量。
    Vt\displaystyle V_t
  2. 单位价格 $S_t$存储每字节的成本，冷存与热存价格不同。
    St\displaystyle S_t
  3. 冗余系数 $F$副本与压缩的折中，例如三副本但 0.4 压缩率时 $F = 1.2$。
    F\displaystyle F
  4. 保留天数 $R$数据保留周期，分级后热短冷长。
    R\displaystyle R

AI 应用场景

线上大促故障快速定位

阶段：监控告警与故障定位

解决的问题：没有统一视角时，指标、日志、链路散落在三套系统，故障排查要开三四个页面反复比对，定位一次线上问题动辄半小时以上。统一视角让三类信号按同一时间轴联动，从“发现异常”到“锁定根因”压缩到几分钟。

具体案例：晚高峰时段，订单接口成功率骤降。监控大盘的 Metrics 显示 order 服务错误率冲到 15%，点击进入 Trace 视图，发现慢请求集中在 checkInventory 调用；再打开关联 Logs，看到“Redis 连接池获取超时”的异常堆栈。三者相互印证，8 分钟内确认根因是缓存连接池配置过小。

大促容量规划与压测评估

阶段：容量规划与性能分析

解决的问题：大促前需要评估系统能否扛住峰值流量。传统做法靠经验拍脑袋，容易过度扩容或漏掉瓶颈。可观测性让决策基于数据：指标看历史流量趋势，链路看各服务在压测中的耗时分布，日志验证是否有慢 SQL 与超时重试。

具体案例：双十一前压测团队用历史指标预测峰值 QPS，对整条下单链路做全链路压测，通过 Trace 发现支付服务在 3000 QPS 时耗时从 80ms 飙到 900ms，定位到第三方渠道线程池饱和；扩容后复测，P99 稳定在 120ms 以内。

AIOps 智能根因分析

阶段：智能化运维与根因推理

解决的问题：海量告警中人工筛选根因效率低。把三大支柱数据按统一视角接入 AI 模型，让模型从指标异常、日志错误、链路拓扑中自动推理出最可能的根因候选。

具体案例：某电商团队将 Metrics 异常检测、Logs 关键词聚类、Traces 慢调用链分析三者结合起来，构建根因推荐模型。一次数据库抖动引发的连锁故障中，模型在 2 分钟内同时给出“数据库主从延迟升高”的指标证据、“连接池创建失败”的日志证据、“user 服务调用 db 耗时 3.2s”的链路证据，把人工排查时间从 25 分钟缩短到 5 分钟。

Python 演示

python69 行
import random  class ObservabilitySimulator:    """用三大支柱信号模拟一次线上故障排查"""     def __init__(self):        self.services = ["gateway", "user", "order", "pay"]        self.metric_map = {}        self.log_list = []        self.trace_list = []        self.req_count = 0     def emit_metrics(self):        """生成每个服务当前P95延迟(单位毫秒)"""        for svc in self.services:            samples = sorted(random.randint(20, 90) for _ in range(100))            self.metric_map[svc] = samples[94]     def emit_trace(self):        """生成一条完整链路: gateway -> user -> order -> pay"""        self.req_count += 1        req_id = f"req-{self.req_count}"        parent_span = None        spans = []        for svc in self.services:            if svc == "pay" and random.random() < 0.3:                dur_ms = random.randint(800, 1500)                self.log_list.append(                    f"{svc} ERROR 支付接口调用超时 req_id={req_id}")            else:                dur_ms = random.randint(20, 80)                self.log_list.append(f"{svc} INFO 处理完成 req_id={req_id}")            span_id = f"{svc}-{self.req_count}"            spans.append((span_id, parent_span, svc, dur_ms))            parent_span = span_id        self.trace_list.append((req_id, spans))     def diagnose(self):        """统一视角: 找出最慢链路并关联日志定位根因"""        if not self.trace_list:            return "尚无数据"        slow_trace = max(self.trace_list,                         key=lambda item: sum(s[3] for s in item[1]))        slow_span = max(slow_trace[1], key=lambda s: s[3])        error_logs = [log for log in self.log_list                      if "ERROR" in log and slow_trace[0] in log]        return {            "请求": slow_trace[0],            "最慢服务": slow_span[2],            "耗时_ms": slow_span[3],            "关联错误日志": error_logs,        }  def main():    sim = ObservabilitySimulator()    for _ in range(100):        sim.emit_trace()    sim.emit_metrics()    print("各服务指标(P95):", sim.metric_map)    result = sim.diagnose()    print("统一视角诊断结果:", result)    if result["最慢服务"] == "pay":        print("根因明确: 支付服务调用第三方接口超时")  if __name__ == "__main__":    main()
目的：模拟指标、日志、链路三类信号的产生过程，并用统一视角完成一次“最慢请求根因定位”。
  1. self.metric_map[svc] = samples[94]排序后取第 95 个值即 P95，相当于护士记录“最新体温”。
  2. if svc == "pay" and random.random() < 0.3:以 30% 概率给支付服务埋下故障，模拟线上偶发接口超时。
  3. spans.append((span_id, parent_span, svc, dur_ms))每个环节挂到父 Span 上，构成“流程单”上的追踪链。
  4. self.trace_list.append((req_id, spans))用请求号把多段 Span 串成一条完整链路。
  5. slow_trace = max(self.trace_list, key=lambda item: sum(s[3] for s in item[1]))统一视角第一步：按总耗时找到最慢请求。
  6. error_logs = [...]用 req_id 把日志与链路关联起来，把“流程单上的环节”和“护理日志里的异常”对上号。

常见误区

误区只要日志齐全，什么问题都能查出来，指标和链路可有可无。很多团队遇到故障第一反应就是“去翻日志”，翻半天也没定位到。

正解日志是“事件明细”，但没有方向的明细等于大海捞针。就像护理记录写满了“几点几分做了什么”，但医生必须先看体温单判断“病情在恶化”，才知道该翻哪几页。指标负责划出问题区域和趋势，链路负责标定问题发生在哪个环节，日志才负责还原具体细节。三者缺一不可。

为何常见：日志最直观、最容易上手，初学者往往只熟悉日志排查，忽略了它的“无方向”缺陷。

误区有了完善的指标监控（CPU、内存、QPS、延迟），就不需要链路追踪了，反正都能看到系统慢了。

正解指标告诉你“慢了”，但不告诉你“是哪条路慢”。就像体温计告诉你发烧了，却不告诉你是扁桃体发炎还是阑尾炎。微服务中一次请求经过多个服务，指标只看到整体延迟，链路才能把总耗时拆解到每个环节，让你知道“网关等了 50ms、订单服务处理 200ms、支付服务调用耗时 1.2s”。

为何常见：指标图表直观且历史久，链路是后出现的概念，很多人还没建立“把请求当流程单看”的思维。

误区可观测性就是拼命打日志，把每个函数的入参出参都打出来，出问题时信息一定够用。

正解日志越多，信噪比越低，检索越慢，成本越高。想象护理记录本上每 5 分钟写一条“患者一切正常”，医生翻 200 页才找到一条有价值的异常记录。要做的是结构化日志、合理级别、按需采样：INFO 记关键业务事件，DEBUG 留给调试，ERROR 才记异常。用级别过滤和字段索引提升信噪比。

为何常见：人类直觉是“信息越多越安全”，但忽略了机器检索和存储的物理上限，也忽略了噪声对注意力的稀释。

误区上了 Prometheus、ELK、Jaeger 三个系统，可观测性就建好了。工具齐了，各看各的。

正解三大支柱之间没有关联，等于三个主任各拿一份档案却从不坐在一起会诊。统一视角才是精髓：时间轴对齐、traceID 跨数据关联、平台内一键跳转。没有关联的三大支柱，只是三个更贵的监控系统；有了统一视角，才是可观测性。

为何常见：三大支柱概念容易记，但“统一视角”是抽象能力，不如具体工具好理解，实践中常被忽略。

误区链路数据这么有用，应该 100% 采样，一条都不能丢，不然就错过关键请求了。

正解100% 采样意味着每个请求都要生成、传输、存储完整的 Span 树，成本高到大多数公司无法承受，还会拖慢业务性能。就像给每个病人都做全套 MRI，不仅血不够，钱也不够。实务中采用“固定概率采样 + 错误全采样”的混合策略：正常请求按 1%-10% 抽取，出错请求 100% 保留，兼顾成本与覆盖率。

为何常见：只看到链路的价值，没算清存储和性能账单；这也是“数据越多越好”直觉的另一种表现。

面试题

Q1. 可观测性的三大支柱是指？

单选题 · easy

  • A.指标、日志、链路← 正确答案
  • B.CPU、内存、磁盘
  • C.开发、测试、运维
  • D.告警、监控、报表

答案：A。三大支柱是 Metrics（指标）、Logs（日志）、Traces（链路），对应急诊室里的体征单、护理记录、流程单。CPU/内存/磁盘是基础设施资源，开发/测试/运维是职能分工，告警/监控/报表是监控子集，均不属于三大支柱。

Q2. 下列哪种指标适合统计接口的总调用次数？

单选题 · easy

  • A.即时值仪表盘
  • B.单调递增计数器← 正确答案
  • C.分布统计直方
  • D.文本日志全文

答案：B。Counter 是只增不减的计数器，像计步器一样累加，适合统计请求总数。Gauge 是即时值仪表盘，可增可减；Histogram 是分布直方图，用于分位数；文本日志不是指标类型。

Q3. 四个黄金信号包括哪些？

多选题 · easy

  • A.延迟← 正确答案
  • B.流量← 正确答案
  • C.错误← 正确答案
  • D.告警数

答案：ABC。Google SRE 手册提出的黄金信号是延迟、流量、错误、饱和度四项。告警数是治理对象而非黄金信号，重复的告警反而说明告警体系需要优化。

Q4. 关于 Span 的说法，哪一项是错误的？

单选题 · mid

  • A.一次调用的环节
  • B.具备父子层级关系
  • C.记录起止时间戳
  • D.等同于一条日志← 正确答案

答案：D。Span 是链路中的一段工作区间，有父子层级，记录起止时间，但它不是日志。链路中的 Span 和日志是两类数据：Span 回答“这段花了多久”，日志回答“这段发生了什么”，二者通过 traceID 关联。

Q5. 日志中缺失 traceID 会导致什么后果？

单选题 · mid

  • A.链路无法关联日志← 正确答案
  • B.指标采集必然失败
  • C.请求将直接超时
  • D.安全审计无法开展

答案：A。traceID 是日志与链路之间的桥。没有它，看到一条 ERROR 日志也无法知道它属于哪次请求、发生在哪个 Span 里。指标采集、请求超时、安全审计都不直接依赖 traceID。

Q6. 为什么生产环境通常不做 100% 链路采样？

单选题 · mid

  • A.成本惊人且拖慢性能← 正确答案
  • B.数据精度反而下降
  • C.traceID会重复
  • D.Span会乱序

答案：A。100% 采样意味着每个请求的每个 Span 都要传输和存储，成本随流量线性爆炸，还会增加业务开销。实际用“概率采样+错误全采样”的混合策略，在覆盖率与成本之间取平衡。

Q7. 高基数指标问题的本质是什么？

单选题 · hard

  • A.标签组合爆炸拖垮存储← 正确答案
  • B.数据太多需要清空
  • C.指标类型选择错误
  • D.采样率设置过低

答案：A。高基数指指标标签的组合数量爆炸，如把 user_id 作为标签，每个用户一条序列，存储与查询成本剧增。问题是“标签设计不合理”而非“数据太多需清空”或“采样率不足”。

Q8. 统一视角的落地需要哪些关键能力？

多选题 · hard

  • A.时间轴统一对齐← 正确答案
  • B.请求ID跨类关联← 正确答案
  • C.平台内一键跳转← 正确答案
  • D.仅有一份超大数据仓库

答案：ABC。统一视角 = 时间对齐 + ID 关联 + 平台联动跳转。仅把数据塞进一个大仓库而不做关联与联动，只是物理堆叠，不是统一视角——就像三份档案锁进同一个保险柜但不铺在桌上。

Q9. SLO 为 99.9% 时，一个自然月的错误预算是多少？

单选题 · mid

  • A.约43分钟← 正确答案
  • B.约8小时
  • C.约5分钟
  • D.约1天

答案：A。一个月约 43200 分钟，错误预算 = 43200 × (1 - 99.9%) = 43.2 分钟。这就是“允许出错的额度”。8 小时对应约 98.9%，5 分钟对应约 99.99%，1 天对应约 96.7%。

Q10. 可观测性与传统监控的区别体现在哪些方面？

多选题 · extreme

  • A.监控应对已知规则← 正确答案
  • B.可观测性探索未知问题← 正确答案
  • C.需要三类数据联动← 正确答案
  • D.只需更多存储空间

答案：ABC。传统监控围绕预设阈值和已知故障模式，回答“挂了没”；可观测性强调从外部输出推断未知的内部状态，回答“为什么挂了”，依赖三类数据联动。仅增加存储空间不改变能力本质。