大数据平台可观测性
概述
大数据平台组件多、链路长、故障影响大。可观测性要回答三个问题：系统健康吗（监控）、作业跑得对吗（作业）、数据可信吗（数据）。本文讲透集群/作业/数据监控与 Prometheus + Grafana 实践。
一、可观测性的层次
三个层次：
系统层：集群是否健康（资源/服务）
作业层：任务是否正常（成功/延迟）
数据层：数据是否可信（质量/时效）| 层次 | 关注 | 手段 |
|---|---|---|
| 系统 | 资源/进程/网络 | 指标监控 |
| 作业 | 状态/时长/重试 | 作业监控 |
| 数据 | 行数/时效/质量 | 数据监控 |
| 链路 | 全链路耗时/流向 | 链路追踪 |
"可观测"三支柱：
指标（Metrics）：周期性数值
日志（Logs）：事件记录
链路（Traces）：请求轨迹二、集群监控
2.1 监控对象
| 组件 | 关键指标 |
|---|---|
| HDFS | 容量、块数、DataNode 状态 |
| YARN | 队列资源、运行任务、等待任务 |
| HBase | Region 数、读写延迟、MemStore |
| Kafka | 吞吐、积压、分区 Leader |
| 计算引擎 | Spark/Flink 任务资源 |
| 主机 | CPU、内存、磁盘、网络 |
HDFS 核心指标：
容量使用率（>85% 预警）
DataNode 存活数
坏块/复制不足块
写操作延迟2.2 采集架构
架构：
各组件暴露指标（JMX/HTTP）
↓ 抓取
Prometheus（定时拉取）
↓ 存储查询
Grafana（可视化/告警）
↓
钉钉/邮件/短信通知| 组件 | 职责 |
|---|---|
| Exporter | 组件指标暴露 |
| Prometheus | 采集+存储+告警 |
| Grafana | 展示+告警规则 |
| Alertmanager | 告警分发 |
2.3 Prometheus 基础
数据模型：
指标名 + 标签 = 时序
hadoop_hdfs_used_bytes{host="dn1"}
↑指标名 ↑标签查询语言 PromQL 示例：
集群容量使用率：
100 * sum(hdfs_used_bytes) / sum(hdfs_capacity_bytes)
近 5 分钟写入速率：
rate(hdfs_write_ops_total[5m])告警规则示例（yml）：
- alert: HDFS容量预警
expr: hdfs_used_ratio > 0.85
for: 10m
labels: severity: warning
annotations: 描述: HDFS 容量使用率超 85%三、作业监控
3.1 监控维度
| 维度 | 指标 |
|---|---|
| 状态 | 成功/失败/运行中 |
| 耗时 | 运行时长、排队时长 |
| 依赖 | 上游是否就绪 |
| 数据量 | 输入输出行数 |
| 重试 | 重试次数 |
调度平台视角：
工作流状态（DAG 整体）
任务实例状态（单个任务）
失败重试策略
补数实例监控3.2 作业告警
告警场景：
任务失败 → 立即告警
任务超时 → 超时告警
数据量异常 → 行数偏差告警
重试超限 → 升级告警| 告警级别 | 场景 | 响应 |
|---|---|---|
| 提醒 | 轻度延迟 | 记录观察 |
| 警告 | 任务失败重试 | 值班介入 |
| 严重 | 核心任务连续失败 | 紧急处理 |
告警升级机制：
失败 1 次 → 通知负责人
重试 3 次仍失败 → 通知值班组
核心任务失败 → 电话/短信3.3 作业健康度
作业健康分：
按时完成率（时效）
成功率（稳定）
重试率（质量）
资源效率（成本）
综合打分 → 定位问题作业四、数据监控
4.1 数据监控维度
| 维度 | 说明 | 示例 |
|---|---|---|
| 时效 | 数据是否按时就绪 | 日表 8 点前就绪 |
| 量级 | 行数/大小波动 | 订单表行数环比 |
| 质量 | 空值/重复/异常 | 空值率超阈值 |
| 一致性 | 对账校验 | 明细对得上汇总 |
数据监控实现：
数据质量任务定时执行
检查项配置化（阈值/规则）
结果写入质量库
异常触发告警4.2 数据时效监控
实现方式：
表就绪检测（分区存在/行数>0）
调度 DAG 加就绪节点
就绪超时告警
下游依赖就绪状态
SQL 示例：
SELECT COUNT(*) FROM ods_orders
WHERE dt = '2026-08-05'
若为 0 → 数据未就绪4.3 数据量波动监控
波动检测：
今日行数 vs 昨日行数 → 环比
近 7 天均值 → 基线
偏差超阈值 → 告警
示例：
行数环比下降超 50% → 可能采集异常五、链路追踪
5.1 为什么需要链路追踪
场景：
一条数据从业务库 → ODS → DWD → 报表
出问题要定位在哪一段
链路追踪：端到端记录每一跳数据链路：
业务库（binlog）→ Canal → Kafka → Flink
→ Hive/ODS → DWD → DWS → 报表服务5.2 链路追踪实现
| 手段 | 说明 |
|---|---|
| 任务血缘 | 调度/血缘平台记录上下游 |
| 消息追踪 | 消息带 traceId |
| 延迟监控 | 各环节时间戳对比 |
| 异常定位 | 端到端日志串联 |
实现思路：
每个环节记录：开始时间/结束时间/状态/数据量
汇总成链路视图：
业务库 → Canal（耗时 5s，积压 0）
→ Kafka（积压 10000，持续上升！）
→ Flink（消费正常）
→ 定位瓶颈：Kafka 消费慢5.3 常见链路问题
| 问题 | 表现 | 定位 |
|---|---|---|
| 消息积压 | Kafka 堆积 | 消费能力不足 |
| 同步延迟 | ODS 就绪晚 | Canal/采集慢 |
| 加工变慢 | DWD 耗时涨 | 数据倾斜/资源不足 |
| 接口超时 | 报表慢 | 查询引擎压力 |
六、Grafana 实践
6.1 看板规划
看板分层：
总览看板（老板视角）
集群看板（运维视角）
作业看板（数据视角）
业务看板（业务视角）| 看板 | 内容 |
|---|---|
| 平台总览 | 组件状态、资源水位 |
| 集群详情 | 各组件核心指标 |
| 作业监控 | 成功率、耗时、失败 TOP |
| 数据监控 | 就绪率、质量异常 |
| 大屏 | 实时吞吐、积压 |
6.2 告警实践
告警设计原则：
少而准（不轰炸）
分级通知（重要程度匹配渠道）
可执行（告警带定位信息）
可恢复（恢复自动通知）告警三要素：
触发条件（阈值/时长）
通知对象（负责人/值班组）
处理指引（故障手册链接）6.3 告警分级与值班
| 级别 | 通知 | 要求 |
|---|---|---|
| P1 | 电话+短信 | 立即处理 |
| P2 | 钉钉+邮件 | 30 分钟内 |
| P3 | 邮件 | 当天处理 |
| P4 | 记录 | 观察处理 |
七、监控体系建设落地
7.1 整体架构
监控中心：
指标采集（Exporter + Prometheus）
日志采集（Filebeat + ES + Kibana）
链路追踪（血缘 + traceId）
作业监控（调度平台上报）
数据监控（质量平台定时）
→ 统一告警（Alertmanager → 多渠道）
→ 统一看板（Grafana）7.2 落地步骤
步骤：
1. 部署 Prometheus + Grafana
2. 各组件接入 Exporter
3. 制定核心指标与阈值
4. 接入作业/数据监控
5. 建立告警分级与值班
6. 建设看板体系
7. 持续复盘优化7.3 监控指标梳理表
| 组件 | 必备指标 | 预警阈值 |
|---|---|---|
| HDFS | 容量使用率 | 85% |
| YARN | 队列积压 | 持续 10 分钟 |
| Kafka | 消费积压 | 超过阈值 |
| 作业 | 失败率 | 上升趋势 |
| 数据 | 就绪率 | 低于 99% |
八、常见问题与最佳实践
8.1 告警轰炸
最佳实践：
聚合相似告警（同组件同类型合并）
抑制（父故障发生时抑制子告警）
静默（维护窗口静默）
阈值校准（持续调整避免误报）8.2 指标太多看不过来
| 手段 | 说明 |
|---|---|
| 分级展示 | 总览→明细分层 |
| 聚焦核心 | 每个组件只盯关键指标 |
| 自动化 | 异常自动生成工单 |
| 智能基线 | 波动检测代替固定阈值 |
8.3 监控→处理闭环
闭环要求：
告警必有人响应（值班制度）
处理有记录（故障复盘）
根因有改进（避免重复故障）
定期演练（故障预案演练）九、小结
平台可观测性 = 系统监控 + 作业监控 + 数据监控 + 链路追踪，用 Prometheus + Grafana 统一落地。核心不是堆指标，而是建立告警分级、值班响应、复盘改进的闭环，让每一次故障都成为平台稳定性的垫脚石。