你还在“出问题才查日志”？用 Prometheus + Grafana，把大数据平台变成“会说话”的系统！

大家有没有这种经历：

凌晨2点，报警电话响了——
“任务延迟了，用户投诉了，老板在群里@你了。”

你第一反应是啥？

👉 SSH 上去
👉 tail -f 日志
👉 grep 半天
👉 最后发现：CPU早就打满半小时了，只是没人看见

说白了，这不是技术问题，是**“不可观测”问题**。

🧠 一、为什么大数据平台必须“可观察”？

很多人以为监控 = CPU + 内存 + 磁盘

错了，大错特错。

在大数据场景里（Flink / Spark / Kafka / HDFS）：

👉 问题从来不是“机器挂了”
👉 而是“系统已经开始变慢，但没人发现”

举几个真实场景：

• Kafka Lag 慢慢堆积（没人盯）
• Spark Job GC 飙升（没报警）
• Flink Backpressure 爆炸（无感知）
• HDFS NameNode 延迟升高（用户才发现）

👉 这类问题的本质：信号早就有了，但你没看见

🔍 二、Prometheus + Grafana，本质是什么？

很多人把它当工具，其实它是一个理念：

👉 从“被动查问题” → “主动感知异常”

架构非常简单：

业务系统 → metrics → Prometheus → Grafana → 人

一句话总结：

👉 Prometheus 负责“采集 + 存储”
👉 Grafana 负责“展示 + 洞察”

⚙️ 三、从0搭一个平台级监控（核心实战）

我们直接上干货，不讲虚的。

1️⃣ Prometheus 抓取配置

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'kafka'
    static_configs:
      - targets: ['localhost:9308']

  - job_name: 'flink'
    metrics_path: /metrics
    static_configs:
      - targets: ['flink-jobmanager:9249']

👉 核心点：

• 每15秒抓一次指标
• 每个组件一个 job
• 不依赖 agent（这点很香）

2️⃣ Python服务接入监控（重点）

很多人忽略了这一步，其实业务监控才是核心价值。

from prometheus_client import start_http_server, Counter, Gauge
import time
import random

# 请求计数
REQUEST_COUNT = Counter('request_count', 'Total Request Count')

# 当前任务延迟
TASK_LATENCY = Gauge('task_latency_seconds', 'Task latency')

def process_task():
    latency = random.random()
    TASK_LATENCY.set(latency)
    REQUEST_COUNT.inc()
    return latency

if __name__ == '__main__':
    start_http_server(8000)  # Prometheus 抓取端口
    while True:
        process_task()
        time.sleep(2)

👉 这段代码干了三件事：

• 暴露指标接口 /metrics
• 记录请求量
• 实时上报延迟

👉 这一步，是把“业务状态”变成“数据信号”

3️⃣ Grafana 可视化（核心体验）

你在 Grafana 里只需要写 PromQL：

rate(request_count[1m])

👉 看QPS趋势

task_latency_seconds

👉 看实时延迟

avg_over_time(task_latency_seconds[5m])

👉 看平滑趋势

🚨 四、真正的价值：不是看图，是“报警”

如果你只停留在“看Dashboard”，那你还停在初级阶段。

👉 真正的监控 = 自动触发行动

AlertManager 配置

groups:
- name: latency-alert
  rules:
  - alert: HighLatency
    expr: task_latency_seconds > 1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "任务延迟过高"

👉 含义：

• 延迟 > 1秒
• 持续1分钟
• 自动报警

💡 五、一个很多人没想明白的本质

很多人部署了 Prometheus + Grafana，但还是没用好。

为什么？

因为他们只监控：

👉 机器
👉 服务

却没有监控：

👉 业务语义

✨ 举个对比

普通监控：

• CPU 80%
• 内存 70%

高级监控：

• Kafka Lag > 10万
• Flink 延迟 > 5秒
• 订单处理失败率 > 2%

👉 哪个更有价值？

显然是后者。

🧠 六、可观察平台的3个层次（认知升级）

如果你想把这件事做到位，记住这三层：

🥉 第一层：资源监控

• CPU / 内存 / IO
• Node Exporter

👉 只能发现“机器问题”

🥈 第二层：服务监控

• JVM / GC / QPS
• Kafka / Spark / Flink

👉 能发现“系统问题”

🥇 第三层：业务监控（核心）

• 订单成功率
• 数据延迟
• 消费积压

👉 才能发现“用户问题”

🔥 七、我自己的一个踩坑总结

我以前也踩过一个大坑：

👉 Grafana 面板做得特别漂亮
👉 指标一大堆
👉 但出问题时还是靠人肉查日志

后来才明白一个事：

❗监控不是为了“展示”，而是为了“决策”

如果你的监控不能回答这三个问题，那就是失败的：

1. 现在是否异常？
2. 异常在哪？
3. 要不要立刻处理？

🚀 八、再往前一步：走向“可观测性平台”

Prometheus + Grafana 只是起点。

真正的未来是：

• Metrics（指标）
• Logs（日志）
• Traces（链路）

三者融合（也就是 OpenTelemetry 体系）

👉 你不仅知道“慢了”
👉 还能知道“哪一行代码慢”

🧾 最后说点掏心窝的话

做大数据平台，最怕的不是 bug：

👉 是**“问题已经发生，但你不知道”**

Prometheus + Grafana 的价值，不是工具，而是：

👉 让系统“开口说话”

当你的平台开始主动告诉你：

• “我快撑不住了”
• “这里开始变慢了”
• “这批数据可能要出问题了”

那一刻，你就从“救火队员”变成了：

👉 真正的系统掌控者

如果你现在的平台还停留在：

👉 出问题 → 查日志 → 猜原因

那我建议你认真想一件事：

❗你缺的不是运维能力，而是“可观察性能力”