可观测性三支柱架构

可视化演示

演示操作系统进程的五种基本状态及转换条件：New→Ready→Running→Waiting/Terminated，通过步进控制逐个展示状态转换过程。

三支柱概述

想象你是一家三甲医院的急诊科主任。凌晨三点，一个病人被推进抢救室，主诉是“系统崩溃”。你面前摆着三样东西：生命体征仪上跳动的心率曲线、桌上半尺厚的病历本、流调员递来的行动轨迹图。单独看任何一样，你都只能得到片面结论——心率快可能是发烧也可能是恐慌；病历厚说明病史长但不说明当下危机；轨迹图能看出去了哪里却看不出身体内部出了什么问题。只有三样齐备，你才能判断：这是急性心梗，马上送导管室。

云原生系统的可观测性，就是为每套系统配备这“急诊三件套”。指标（Metrics）是系统的生命体征——每秒请求数、CPU 使用率、错误率，以数值形式周期性采集，回答“系统现在健康吗”。日志（Logs）是系统的病历本——每一行带时间戳的文本记录，回答“系统刚才发生了什么”。链路追踪（Traces）是系统的行动轨迹——一个请求从入口到每个微服务的完整路径，回答“一次请求具体经过了哪里、耗时多久”。

这三者不是三个独立工具，而是一套协同诊断体系。监控告诉你“出问题了”，可观测性告诉你“为什么出问题”。三支柱的价值在于：指标报警时，你能顺着日志找到具体错误，再沿链路追踪定位到是哪个服务的哪个环节拖慢了整个请求。

指标监控：生命体征仪表盘

急诊室里的心电监护仪从不关心病人昨晚吃了什么，它只以固定频率捕捉心率、血压、血氧饱和度这些关键数值。一旦数值越界，立刻响起刺耳警报。指标监控就是系统的监护仪：用数值描述系统状态，以固定时间间隔采样，用最少的存储换来最实时的健康感知。

一个指标由三要素构成：指标名称（如 http_requests_total）、标签（如 method="GET"、status="500"）以及采样值。这就是指标的数据模型——把标签想象成监护仪上的不同导联：心电图导联贴胸口，血氧夹夹手指，每个标签都从不同维度切分同一个指标。计数器只增不减（总请求数），仪表盘可升可降（当前连接数），直方图记录分布（请求耗时分布）——这对应监护仪上不同的波形模式。

采集方式上，系统通过 Prometheus 这类工具定期“拉取”（Pull）各服务的指标端点，或由服务主动“推送”（Push）到网关。配上告警规则，当指标超过阈值（如 P99 延迟超过 500ms），就触发告警通知值班工程师。

指标监控的局限也很明显：它只告诉你“心率 140”，但不告诉你“为什么 140”。这时就需要翻开病历本——日志。

日志管理：病历记录本

每个病人都有一本厚厚的病历，医生每次查房都会在上面写一行：“体温 38.5℃，主诉头痛，开药布洛芬”。日志就是系统的病历本——每一行日志记录一个离散事件，包含时间戳、级别、来源和详细描述。它最贴近“发生了什么”的原始事实，因此排障时工程师的第一反应永远是“去看看日志”。

但病历本有个麻烦：它太厚了。一个中等规模的系统每天产生几十 GB 甚至 TB 级日志，像病历堆满整间档案室。如果每行日志都是非结构化自由文本（“user 123 visit failed“），事后检索就像在病历堆里找某一句话——大海捞针。结构化日志为此而生：用 JSON 等格式固定字段，让每行日志成为可被机器解析的”结构化病历”。

日志的采集通常通过 Filebeat/Fluentd 等代理读取日志文件或监听标准输出，解析后送入 Elasticsearch、Loki 等存储。为提高检索效率，日志系统通常建立倒排索引，支持按关键字、时间范围、字段值组合查询。

但病历本只记录“出现过什么”，记录不了“一件事如何在科室之间流转”。要追踪流程路径，需要第三份材料——行动轨迹图。

链路追踪：病毒传播链流调

疫情期间，流调员的职责是画出一条传播链：0 号病人去了超市，接触了收银员，收银员又接触了保安……每一个接触点、每一次停留时长都记录在案。链路追踪干的就是这件事：针对一个用户请求，记录它穿过的每一个服务、每个服务内的操作及耗时，形成一棵“调用树”。

链路追踪的核心概念是 Span（追踪片段）。一个 Span 代表一次带时间范围的操作，比如“订单服务调用支付服务”这一过程。多个 Span 通过父子关系组成一棵树，树的根就是用户请求的入口，整棵树称为一个 Trace。每个 Span 都携带 trace\_id（整棵树的唯一编号）、span\_id（自己的编号）、parent\_span\_id（父节点编号）和时间戳。

由树形结构，我们可以快速计算每个环节的耗时占比——比如发现整个请求 2 秒里 1.5 秒耗在数据库查询上。但要让 Span 跨服务传递，请求每次调用下游服务时，都必须把当前的 trace\_id、span\_id 打包进 HTTP 头（如 traceparent 头），下游服务收到后继续沿这条链记录。这个过程叫上下文传播。

有了三份报告，下一步的关键是：如何把它们拼成一份完整的诊断书？

关联分析：三种报告合体诊断

急诊医生从不只看一张单子：心电图的异常 ST 段（指标）提示心梗，化验单的肌钙蛋白升高（日志）印证诊断，家属描述的“从健身房出来就倒地”（轨迹）则解释了诱因。在可观测性里，三种数据的关联分析，才是从“发现异常”走向“定位根因”的桥梁。

关联的枢纽是一个公共字段——trace\_id。当请求穿过订单服务时，订单服务的日志会带上 trace\_id；支付服务被调用时，也会生成带同一 trace\_id 的日志和 Span；整个过程中产生的指标同样可以用标签标记路由维度。这样，当某条链路追踪变慢时，我们可以带着 trace\_id 去日志系统搜出这条链路上的所有日志，再结合指标的全局画像，快速锁定根因。

OpenTelemetry：统一体检标准

过去的问题是：医院里每台设备都用自己的数据格式——心电图仪输出的纸带、化验室的表格、流调系统的 GIS 图，想合并分析必须先手工誊抄。微服务架构早期也一样：Prometheus、ELK、Jaeger 各说各话，工程师被迫在三个工具间反复切换对齐。

OpenTelemetry（简称 OTel）是 CNCF 推出的统一可观测性标准，相当于给整个行业规定了“电子病历”的格式。它提供一套 API 和 SDK，让应用只需接一次 SDK，就能同时生成指标、日志、追踪三种数据，并通过统一的导出协议（OTLP）发送到任何后端——无论是开源的 Prometheus/Jaeger，还是商业的 Datadog/阿里云 ARMS。

OTel 的目标不是取代 Prometheus 或 ELK，而是做“设备与系统之间的翻译官”——让各种后端消费统一格式的数据。这大大降低了团队切换工具栈的门槛，也使得“一次埋点，多处消费”成为可能。

标准统一之后，现实中的落地还面临一个残酷问题：数据采集是要花钱的。

落地实践：体检套餐的性价比设计

体检中心不会建议客户做“全身体检每天一次”——太贵且没必要。可观测性落地最大的坑，恰恰是“全量采集、全量存储、全量保留”。高基数的指标（每个用户一个标签）、全量日志、100% 采样率的链路追踪，会让存储和计算成本随业务流量线性爆炸。因此，落地三支柱的第一课是学会做减法。

成本优化有三板斧。第一板斧：指标降基数——把 user\_id 这类高基数标签从指标中剥离，只保留 service、api 等低基数标签；第二板斧：日志分层——热日志存高性能存储 7 天，冷日志压缩转储到对象存储 90 天，甚至只保留 ERROR 级别以上的完整上下文；第三板斧：采样策略——这是链路追踪成本控制的核心手段。

除了采样，更聪明的做法是场景驱动的采集策略：核心交易链路全量采样（如支付、下单），非核心链路（如商品浏览）10% 采样；错误请求全量保留，因为排障价值最高。最后，把三支柱的接入纳入 CI/CD 流水线，让每个新服务在发布前必须通过“可观测性体检”（埋点覆盖率检查），才算真正把三支柱落地成工程体系。

AI 应用场景

Python 演示

"""链路追踪模拟：展示 Trace/Span 与三支柱协同使用 OpenTelemetry 风格的简化实现"""import timeimport uuidimport jsonfrom collections import defaultdict  class Span:    def __init__(self, name, trace_id, span_id, parent_id=None):        self.name = name        self.trace_id = trace_id        self.span_id = span_id        self.parent_id = parent_id        self.start_time = time.time()        self.end_time = None        self.attributes = {}        self.children = []     def finish(self):        self.end_time = time.time()        self.attributes["duration_ms"] = round(            (self.end_time - self.start_time) * 1000, 2        )        return self.attributes["duration_ms"]  def trace_exporter(root_span):    """导出 span 树为字典列表"""    lines = []     def walk(span, depth):        dur = span.attributes.get("duration_ms", 0)        prefix = "  " * depth        lines.append(            f"{prefix}span: {span.name} ms={dur} "            f"trace={span.trace_id[:8]} parent={span.parent_id}"        )        for child in span.children:            walk(child, depth + 1)     walk(root_span, 0)    return "\n".join(lines)  def simulate_request(order_id):    """模拟一次订单请求：订单->支付->库存"""    trace_id = uuid.uuid4().hex    root = Span("POST /order", trace_id, uuid.uuid4().hex)     db_span = Span("cache.order_cache", trace_id, uuid.uuid4().hex, root.span_id)    time.sleep(0.05)    cache_log = {"level": "INFO", "service": "order", "trace_id": trace_id}    db_span.finish()    root.children.append(db_span)     pay_span = Span("payment.charge", trace_id, uuid.uuid4().hex, root.span_id)    time.sleep(0.12)    if order_id % 5 == 0:        pay_span.attributes["error"] = "insufficient_balance"        err_log = {"level": "ERROR", "service": "payment", "trace_id": trace_id}    else:        err_log = None    pay_span.finish()    root.children.append(pay_span)     inv_span = Span("inventory.check", trace_id, uuid.uuid4().hex, root.span_id)    time.sleep(0.03)    inv_span.finish()    root.children.append(inv_span)     root.finish()    logs = [cache_log, err_log] if err_log else [cache_log]    return root, logs  def main():    fake_metrics = defaultdict(int)    print("=== 可观测性三支柱模拟 ===")    for order_id in range(1, 8):        root, logs = simulate_request(order_id)        fake_metrics["total_orders"] += 1        has_error = any(l["level"] == "ERROR" for l in logs)        if has_error:            fake_metrics["error_orders"] += 1         print(f"\n--- 请求 #{order_id} ---")        print("【链路追踪 Trace 树】:")        print(trace_exporter(root))        print("【结构化日志】:")        for log in logs:            print("  " + json.dumps(log, ensure_ascii=False))     error_rate = fake_metrics["error_orders"] / fake_metrics["total_orders"] * 100    print("\n【指标监控】")    print(f"  总订单数 = {fake_metrics['total_orders']}, "          f"错误率 = {error_rate:.1f}%")  if __name__ == "__main__":    main()

1. class Span每个 Span 记录操作名、trace_id、span_id、父 id 和起止时间，对应追踪概念的单条“流调记录”。
2. simulate_request(order_id)模拟一次完整请求，依次调用三个服务并生成子 Span，相当于让请求穿过三个“科室”。
3. trace_exporter(root_span)递归遍历 Span 树并格式化输出，展示请求的完整调用链。
4. cache_log` / `err_log每个服务产生结构化日志并携带 trace\_id，这是后续关联分析的“住院号”。
5. fake_metrics["total_orders"]记录总请求数和错误数，最后计算错误率，对应指标监控的“生命体征”。

常见误区

面试题