别让数据平台“盲开车”：可观测性三件套（指标、日志、追踪）到底怎么落地？

大家好，我是 Echo_Wish。今天咱聊一个听着高大上、但其实每个搞大数据的都应该天天关心的话题——可观测性（Observability）。

为什么说它重要？
因为没有可观测性的平台，就像没有仪表盘的车，你坐进去猛踩油门，看着风很大，但你完全不知道车速、多热、油有没有漏……最后你会经历两种命运：要么炸、要么爆炸。

本文我会用最接地气的方式讲清楚：

• 大数据平台为什么必须做可观测性？
• 指标、日志、追踪这三件套分别干嘛？
• 真实场景应该如何落地？
• 给你完整的代码示例（Prometheus + ELK + Jaeger）

放心，读完你不仅能讲明白，还能实现。

一、为什么数据平台特别容易“失明”？

你以为数据平台是这样的？

• 大规模集群
• 各种分布式计算框架（Spark、Flink、Hive、Trino）
• 各种服务扯着嗓子吼：“我在工作我在工作！！”

但实际是这样的：

• 一个 Spark 作业突然跑慢？不知道哪段代码炸了
• Flink 的 checkpoint 卡住？你看不到哪个 Operator 出问题
• Kafka 吞吐严重下降？你看到的只是一堆报错日志
• Hive SQL 花 3 小时？root cause 找一天

一句话：链路长、组件多、依赖复杂、问题像打地鼠一样冒头。

这时候，可观测性三件套就显得尤其关键：

👉 指标 (Metrics) —— 告诉你系统现在状况好不好
👉 日志 (Logs) —— 告诉你发生过什么事
👉 追踪 (Traces) —— 告诉你请求走了什么路

三者组合，就是数据平台的“火眼金睛”。

二、指标：让你的平台“有体温、有心跳、有血压”

指标是所有可观测性的基础，它是系统的量化表现。

在大数据平台里，最常见的指标是：

• 资源类：CPU、内存、磁盘、网络
• 任务类：QPS、延迟、task 执行时间、吞吐
• 框架类：Spark/Flink/Hive 的执行器指标
• 存储类：HDFS block、Kafka lag、HBase latency

为什么指标重要？因为 指标趋势往往比错误本身更早出现。

例如 Kafka lag：

# 假设你用 Prometheus Client 监控 Kafka lag
from prometheus_client import Gauge, start_http_server
import random, time

kafka_lag = Gauge("kafka_topic_lag", "Kafka consumer lag", ["topic", "group"])

def simulate():
    while True:
        lag_value = random.randint(0, 1000)
        kafka_lag.labels("user-events", "consumer-1").set(lag_value)
        time.sleep(2)

start_http_server(8000)
simulate()

这段代码的意思很简单：

• 暴露一个指标
• Prometheus 会来抓取
• 你能在 Grafana 里实时看到 lag 的波动

当 lag 突然暴涨，你不用日志也知道肯定出事了。

三、日志：大数据系统的“黑匣子”

指标只能回答一个问题：“它坏了没？”
但日志能回答更关键的问题：“它怎么坏的？”

大数据平台的日志一般包含：

• 应用日志（Spark、Flink、Kafka）
• 系统日志（OS、Docker、K8s）
• 业务日志（具体 pipeline 的逻辑行为）
• 安全日志（权限、审计）

举个简单的日志埋点例子（Python）

import logging

logging.basicConfig(
    filename='etl.log',
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

def process(item):
    if "error" in item:
        logging.error(f"Bad data detected: {item}")
    else:
        logging.info(f"Process success: {item}")

process("ok_data")
process("error_data")

如果你把日志集中进 ELK（Elasticsearch + Logstash + Kibana）
那么你能做到：

• 关键字搜索
• 全局过滤
• 多维度扫描
• 自动告警

有次我在调一个线上 Flink 作业，metrics 一切正常，但结果数据不全。最后发现是 某条脏数据触发逻辑分支，但 metrics 没覆盖那个分支。
最后还是日志救了我。

四、追踪：让数据流动有“导航路线图”

日志和指标都解决不了一个核心问题：
分布式系统到底是怎么调用的？

数据平台的调用链可能非常复杂：

Kafka → Flink → MySQL → API → Redis → ClickHouse

如果你不用 tracing，你看到的就是：

• Flink 卡住
• ClickHouse RT 很高
• Redis occasionally timeout

但你不知道这三个是不是同一条链路。

用 OpenTelemetry 实现追踪（Python）

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.jaeger.thrift import JaegerExporter

trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)

jaeger_exporter = JaegerExporter(agent_host_name="localhost", agent_port=6831)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

def fetch_data():
    with tracer.start_as_current_span("fetch_data"):
        return {"id": 1, "value": 100}

def process_data(data):
    with tracer.start_as_current_span("process_data"):
        return data["value"] * 2

with tracer.start_as_current_span("pipeline"):
    d = fetch_data()
    res = process_data(d)

你在 Jaeger UI 里就能看到一个完整链路：

pipeline → fetch_data → process_data

在真实大数据平台里，你能看到如下链路：

API → Flink Source → Operator1 → Operator2 → Kafka Sink → Elasticsearch

任何一个环节延迟变高，你都能一眼发现瓶颈点。

五、三者组合起来，数据平台才算“可观测”

一个成熟的数据平台必须做到：

三者相互补充：

• 指标告诉你哪里不对劲
• 日志告诉你为什么不对劲
• Trace 告诉你问题传导路径

这就像医生问诊：

• 指标 = 量体温测血压
• 日志 = 做血检
• Trace = 做 CT

三者一起，才有“诊断能力”。

六、可观测性不是工具，而是思维

最后我说一个非常重要的观点：

可观测性不是 Prometheus、ELK、Jaeger 的组合，而是一种工程文化。

你要让系统能被观察，而不是问题来了再救火。

这意味着：

• 写代码时就要想着埋点
• 做任务时要定义 SLA
• 数据链路要有 trace
• 所有关键环节必须可度量
• 每次故障都要反推监控缺口

你越早做可观测性，就越少晚上的救火。

我见过太多团队，系统都快崩了，结果连最基本的指标都没有。就像开着几百万的大货车，仪表盘不亮、后视镜坏了，司机说：“我凭感觉开。”
那不出事才怪。

总结

大数据平台的可观测性，是未来架构是否稳得住的关键。
不要等出问题才想做监控，那是亡羊补牢。

你应该做到：

• 指标：实时洞察
• 日志：全局审计
• 追踪：定位瓶颈
• 可观测性思维：设计之初就考虑监控方案

当你把这三件套真正打通，你会发现：

系统变透明了，团队变从容了，故障变少了，早下班的日子变多了。