可观测性三大支柱

可视化演示

展示日志/指标/追踪三大支柱数据模型、采集流水线及跨支柱关联分析时序。

可观测性概述

小区里养一只看门狗，陌生人靠近它就叫，但不会告诉你“这个人是快递员还是小偷”。监控就是这只看门狗——它能发出“系统出问题了”的报警，却答不出“为什么出问题”。而可观测性（Observability）是一位真正的医生：它通过系统的外部输出，推断出系统内部的状态。这里的“外部输出”，就是三大支柱：日志、指标与追踪。

从控制理论中走出来的“可观测性”一词，在云原生语境里被赋予了更具体的使命：只靠外部数据，还原系统内部发生了什么。日志回答“发生了什么”，指标回答“当前数据状态如何”，追踪回答“请求经历了什么路径”。三者互为补充，组合起来才能完成一次完整的“病情诊断”。

注意，监控与可观测性不是替代关系，而是上下层关系：监控是建立在可观测数据之上的告警能力。一套完整排障工作流是：告警触发 → 查指标看趋势变化 → 查日志找异常线索 → 查追踪定位跨服务链路。整个流程浓缩成一个公式：

从“看门狗”进化到“医生”，不是换一只更聪明的狗，而是给整个小区装上病历、监护仪和检查单——这正是三大支柱各自要承担的角色。

日志数据模型

医生看病，第一件事是翻病历本：上次发烧是什么时候、吃了什么药、有没有过敏史。日志（Logs）就是系统的病历本，忠实记录每一次“就诊事件”。一条日志说“2024-05-01 10:03:02 订单服务报错：数据库连接超时”，这就是一次完整的事件叙述。

日志是带时间戳的离散事件记录。生产环境里，日志通常以结构化 JSON 输出，字段必须规范化，方便机器检索。常见字段包括时间戳（timestamp）、级别（level）、服务名（service）、消息体（message）以及关联用的 trace_id。级别从 DEBUG 到 FATAL 依次加重，生产环境一般保留 INFO 及以上，ERROR 级别应单独对接告警。

日志的采集方式很有讲究。在 Kubernetes 中部署应用时，惯例是让应用把日志打到标准输出（stdout），再部署一个采集 Agent（如 Fluent Bit、Filebeat）从容器里“偷听”输出流，解析后转发到日志平台。日志天然信息密集但噪音极大，一个大规模集群每秒可产生百万条日志，所以要分级存储：热数据进搜索引擎供全文检索，冷数据压缩后进对象存储。日志五元组可以写成：

病历本写得越规范，医生越容易快速翻到关键页。日志结构越统一，排障时的检索效率就越高——这是第一条支柱的核心价值。

指标数据结构

重症监护室的墙上挂着一台监护仪，心率、血压、血氧饱和度汇成一条条连续曲线，护士扫一眼就知道病人状态是否稳定。指标（Metrics）就扮演这个角色：它们是可聚合的数值序列，以固定时间间隔采集，回答“现在数值是多少”。

指标有四种核心类型，就像体检报告上的不同项目。Counter（计数器） 只增不减，适合统计累计量，比如“今天总请求数 12 万次”；Gauge（仪表） 可增可减，描述当前瞬时状态，比如“当前 CPU 使用率 73%”；Histogram（直方图） 把样本分桶，用于计算延迟分布；Summary（汇总） 直接在客户端算好分位数。有了这些类型，监控系统才能在告警时回答“慢了”——至于“为什么慢”，需要交给另外两根支柱。

Prometheus 是当前指标领域的事实标准，采用拉取模型：应用暴露一个 /metrics 端点，Prometheus 定期“上门取样”。通过 PromQL 查询语言，可以即时算出每秒请求数。比如，一分钟内计数器增长了 6000，那么 QPS 就是 100。公式表达如下：

监护仪的优点是数据量小、存储便宜、趋势直观，最适合做告警触发器。但它只能告诉你“病人心率飙到 180 了”，说不清是紧张、发烧还是失血——查明原因，需要看追踪。

链路追踪模型

医生怀疑病灶已经扩散，会开一张增强 CT 检查单：往血管里注入造影剂，然后追踪造影剂流经全身器官的影像路径。链路追踪（Tracing）就是这个思路——给一次请求注入“造影剂”（TraceID），观察它流经每个微服务时留下的“影像”（Span）。

Trace 是一条端到端的请求链，代表“一次从用户点到应用”的完整旅程。Span 是旅程中的单个步骤：网关收到了请求、订单服务查了一次数据库、支付服务调了一次外部 API，各自都是一个 Span。Span 之间通过 parent_id 形成树形结构——支付 Span 的父节点是订单服务里发起调用的那个 Span。一条 Trace 就是这棵树的合集：

关键技术是上下文传播：请求进入第一个服务时生成 TraceID，之后通过 HTTP Header（W3C Trace Context 的 traceparent 字段）逐跳携带，每经过一个服务就追加一个 Span。由于请求量巨大，全量追踪的存储成本难以承受，生产环境通常采用采样策略——只保留 1% 到 10% 的请求追踪，头部采样按入口决定，尾部采样则优先保留出错请求。OpenTelemetry 是行业标准 SDK，一次埋点即可输出三大支柱数据。

造影剂流到哪里，病灶的扩散路径就清晰到哪里。有了这张路径图，排查跨二十个微服务的慢请求，不再需要靠猜。

关联分析技术

医生的办公桌上摊着三份材料：病历本（日志）、监护仪曲线（指标）、CT 影像（追踪）。单独看任何一份都难以确诊，把三份叠在一个灯箱上，病灶才无所遁形。排障的过程，本质是一场关联分析。

最核心的关联键是 TraceID：日志平台从日志字段中提取 TraceID，点击即可跳转到对应追踪链路；反过来，从追踪链路的某个 Span 也能一键查看该服务在那几毫秒打出的相关日志。第二个关联维度是时间：指标曲线显示 10:03:02 出现延迟尖峰，就去日志系统检索这 30 秒窗口内的 ERROR 日志，这种“指标先锁定、日志再深挖”的打法非常高效。

一个标准排障故事是这样的：Prometheus 告警“订单服务 P99 延迟超阈值” → Grafana 看指标锁定异常窗口 → Loki 查该窗口日志，发现大量“数据库连接池耗尽” → 点击 TraceID 跳转 Tempo，看到慢请求全部命中同一条数据库调用链。三大支柱的关联可以用关系运算表达：

三份材料叠在一起，才是一张完整的诊断报告。三大支柱不是三个孤岛，而是建在同一套 TraceID 之上的三块透视镜。

采集管道工具

抽完血之后，样本要打包、贴码、物流转运、实验室分拣，最后才出现在检验报告上。可观测性的采集管道就是这套体检物流系统，负责把三大支柱的数据从“产生地”安全、高效地运到“查询端”。

完整管道要过四关。第一关采集：每个节点部署 Agent（如 Fluent Bit、Vector、OpenTelemetry Collector），从容器 stdout、系统文件、网络探针中侧写数据。第二关缓冲：数据先进入内存队列或 Kafka，防止突发流量压垮下游。第三关处理：解析 JSON、丢弃 DEBUG 日志、按 TraceID 采样、脱敏敏感字段。第四关存储与查询：日志进入 Loki 这类低成本全文索引，指标进入 Prometheus，追踪进入 Tempo/Jaeger，前端通过 Grafana 统一呈现。

管道设计的关键是采样闸门，否则成本会失控。日志通常全量保存（因为需要查细节），指标天然紧凑所以全量采集，追踪则严格控制采样率。每条数据都要算存储账：

物流系统通畅，医生才能十分钟内拿到全部报告。采集管道的目标不是把所有数据搬到存储——而是以可承受的成本，把最关键的数据在关键时刻送到该出现的地方。

SRE实践落地

体检中心不只要出报告，还要根据报告给客户定制健康管理方案。SRE（站点可靠性工程）干的正是这件事：把三大支柱的原始数据，转化成一整套系统健康管理制度。

第一件工具是黄金四信号：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。这四项是系统的“生命体征”，对应体检必测的心率、血压、体温和血氧。第二件工具是 SLO 与错误预算：SLO（服务等级目标）是给系统定的健康红线，比如“99.9% 的请求延迟低于 500ms”；SLI（服务等级指标）是实际达成率的测量值；错误预算则是允许超标的额度。发布新版本就像病人试吃新菜——如果错误预算被快速消耗，说明身体吃不消，必须停止发布，优先恢复稳定：

第三件工具是告警分级：页面级告警要求立即处理（打电话、影响用户）；票据级告警生成工单（不影响主流程）；通知级告警进周报（仅供观察）。每条告警都必须附上对应指标的链接和日志的查询入口，让接收人一步进入排障现场。

好的体检套餐不是越贵越好，而是覆盖了最重要的指标、形成了“体检—诊断—治疗—复查”的闭环。SRE 的终极目标，就是把排障变成一道流水线——数据自动汇聚，告警自动携带上下文，恢复动作自动执行。

AI 应用场景

Python 演示

import randomfrom collections import defaultdict  class Span:    """追踪里的一个跨度，代表一次服务调用"""    def __init__(self, trace_id, span_id, parent_id, service):        self.trace_id = trace_id        self.span_id = span_id        self.parent_id = parent_id        self.service = service        self.duration_ms = 0  class Logger:    """日志采集器：所有服务把事件写入这里"""    def __init__(self):        self.lines = []     def write(self, trace_id, level, service, msg, duration_ms):        self.lines.append({            "trace_id": trace_id, "level": level,            "service": service, "msg": msg, "duration_ms": duration_ms        })  class Metrics:    """指标采集器：计数器和延迟观测"""    def __init__(self):        self.counter = defaultdict(int)        self.observations = defaultdict(list)     def count(self, name, value):        self.counter[name] += value     def observe(self, name, value):        self.observations[name].append(value)  def generate_trace(chain, logger, metrics):    """模拟一次请求生成追踪链路"""    trace_id = "t%d" % random.randint(100000, 999999)    spans = []    parent_id = None     for i, service in enumerate(chain):        span = Span(trace_id, "s%d" % i, parent_id, service)        parent_id = span.span_id         duration = random.uniform(5, 60)        if service == "payment":            duration = random.uniform(80, 300)         span.duration_ms = duration        if i == 0:            metrics.count("requests_total", 1)        metrics.observe("latency_ms", duration)         if service == "order" and duration > 50:            logger.write(trace_id, "ERROR", service, "timeout", duration)        else:            logger.write(trace_id, "INFO", service, "ok", duration)         spans.append(span)     if spans:        total_ms = sum(s.duration_ms for s in spans)        logger.write(trace_id, "INFO", "gateway", "total", total_ms)    return trace_id, spans  def percent_99(values):    """计算 P99 分位数"""    values = sorted(values)    return values[int(len(values) * 0.99) - 1]  def main():    logger = Logger()    metrics = Metrics()    chain = ["gateway", "order", "payment"]     for _ in range(300):        generate_trace(chain, logger, metrics)     total_requests = metrics.counter["requests_total"]    p99 = percent_99(metrics.observations["latency_ms"])    errors = [line for line in logger.lines if line["level"] == "ERROR"]     trace_map = defaultdict(list)    for line in logger.lines:        trace_map[line["trace_id"]].append(line)     slowest = sorted(trace_map.items(),                     key=lambda kv: kv[1][-1]["duration_ms"],                     reverse=True)[:3]     print("总请求数:", total_requests, "P99延迟: %.1f ms" % p99)    print("ERROR日志数:", len(errors))    for trace_id, lines in slowest:        print("慢请求", trace_id, "总耗时 %.1f ms" % lines[-1]["duration_ms"])        for line in lines[:-1]:            print("  ", line["service"], line["msg"],                  "%.1f ms" % line["duration_ms"])  if __name__ == "__main__":    main()

1. span = Span(trace_id, "s%d" % i, parent_id, service)每经过一个服务就创建一个 Span，parent_id 形成调用树结构，相当于追踪链路的一个节点。
2. logger.write(trace_id, "ERROR", service, "timeout", duration)日志必须带上 trace_id 和耗时，这是后续关联分析的“钥匙”。
3. metrics.observe("latency_ms", duration)把每个 Span 的耗时存进观测列表，供最后计算 P99 分位数。
4. trace_map[line["trace_id"]].append(line)按 trace_id 把日志分组，实现日志与追踪的关联，这就是“拼图游戏”在代码里的落地。
5. sorted(trace_map.items(), key=lambda kv: kv[1][-1]["duration_ms"], reverse=True)[:3]按每条链路的网关汇总耗时排序，找出最慢的三个请求。
6. values[int(len(values) * 0.99) - 1]延迟样本排序后取第 99 百分位的下标，就是 P99 延迟。

常见误区

面试题