大数据平台监控指标体系设计（企业级详细版）

一、总体架构：分层指标体系

监控体系采用四层分层模型，确保从基础设施到业务应用的全栈可观测性：

|---------|--------|--------------|---------------------------------------------------------------------|
| 层级 | 类别 | 目标 | 代表指标 |
| L1基础设施层 | 主机/OS | 保障物理资源稳定 | CPU使用率、内存使用率、磁盘I/O、网络吞吐、磁盘使用率 |
| L2服务层 | 核心组件 | 保障服务健康与性能 | HDFS NameNode RPC延迟、YARN ResourceManager内存使用率、HBase RegionServer读延迟 |
| L3作业层 | 应用执行 | 保障任务效率与资源利用率 | Spark Executor失败率、Hive查询延迟、Kafka Consumer Lag |
| L4业务层 | 业务SLA | 关联业务价值 | 数据管道完成时间、ETL任务成功率、实时报表延迟 |

黄金指标定义(SRE原则):延迟、流量、错误、饱和度（Latency, Traffic, Errors, Saturation）为所有核心服务的必监控四维指标。

二、核心组件监控指标详解

2.1. HDFS（分布式文件系统）

|------------------|------------------------------------------------------------|--------|----------------------|----------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| 磁盘使用率 | hdfs_namenode_fsnamesystem_CapacityUsedGB/ CapacityTotalGB | % | ≥75% 警告，≥85% 危急 | 超过75%需触发数据清理流程 |
| NameNode RPC延迟 | RpcProcessingTimeAvgTime | ms | >50ms 警告，>200ms 危急 | 高延迟通常由元数据膨胀或GC引起 |
| NameNode RPC队列积压 | CallQueueLength | 个 | >10 警告，>50 危急 | 队列积压表明NameNode处理能力不足 |
| 块缺失数 | hdfs_namenode_fsnamesystem_MissingBlocks | 个 | >0 危急 | 存在数据丢失风险 |
| 块损坏数 | hdfs_namenode_fsnamesystem_CorruptBlocks | 个 | >0 危急 | 需立即执行 hdfs fsck检查 |
| DataNode心跳超时 | hdfs_namenode_fsnamesystem_ExpiredHeartbeats | 个/分钟 | >0 警告 | 表明节点网络或进程异常 |

2.2. YARN（资源调度）

|------------------------|-------------------------------------------|--------|-------------|-------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| ResourceManager CPU使用率 | YarnMetrics:ResourceManagerCpuUsage | % | >80% 警告 | 高CPU可能因调度频繁或队列竞争 |
| ResourceManager内存使用率 | YarnMetrics:ResourceManagerHeapMemoryUsed | % | >75% 警告 | 避免Full GC导致调度阻塞 |
| NodeManager任务失败率 | YarnMetrics:NodeManagerFailedContainers | % | >5% 警告 | 持续高失败率需检查磁盘、内存或网络 |
| 队列资源利用率 | YarnMetrics:QueueUsedCapacity | % | >90% 警告 | 队列资源饱和，需扩容或限流 |
| 容器分配延迟 | YarnMetrics:ContainerAllocationLatency | ms | >1000ms 警告 | 影响作业启动速度 |

2.3. HBase（分布式NoSQL）

|-----------------|---------------------------------|----------|------------|-----------------------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| RegionServer读延迟 | HBase:RegionServer:ReadLatency | ms | >100ms 警告 | 高延迟通常由MemStore Flush或Compaction引起 |
| RegionServer写延迟 | HBase:RegionServer:WriteLatency | ms | >150ms 警告 | 检查WAL写入性能与磁盘I/O |
| Region Split频率 | HBase:RegionServer:RegionSplits | 次/小时 | >5 警告 | 频繁Split导致Region短暂不可用 |
| MemStore使用率 | HBase:RegionServer:MemStoreSize | MB | >128MB 警告 | 单Region MemStore超过默认flush阈值 |
| StoreFile数量 | HBase:RegionServer:StoreFiles | 个/Region | >100 警告 | 影响读性能，需触发Compaction |

2.4. Hive（数据仓库）

|--------------------|-------------------------------|--------|-------------|-----------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| HiveServer2查询延迟 | HiveServer2:QueryLatency | ms | >5000ms 警告 | 高延迟可能由资源争用或SQL优化不足引起 |
| Hive Metastore响应时间 | HiveMetastore:RPCResponseTime | ms | >200ms 警告 | Metastore是元数据瓶颈，需独立监控 |
| HiveServer2并发连接数 | HiveServer2:ActiveSessions | 个 | >50 警告 | 超过配置上限导致连接拒绝 |
| Tez/DAG执行失败率 | Hive:Tez:FailedTasks | % | >3% 警告 | 检查Shuffle阶段与资源分配 |

2.5. Spark（内存计算）

|-------------|----------------------------|--------|---------------|-----------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| Executor失败率 | Spark:Executor:FailedTasks | % | >1% 警告 | 常因内存溢出（OOM）或Shuffle失败 |
| Driver内存使用率 | Spark:Driver:MemoryUsed | % | >80% 警告 | Driver内存不足导致作业挂起 |
| 任务执行时间（P95） | Spark:Job:Duration | ms | >10分钟警告 | 长时间任务需检查数据倾斜或资源不足 |
| Shuffle写入量 | Spark:Shuffle:BytesWritten | MB | 持续增长 | 高Shuffle量是性能瓶颈常见原因 |
| GC暂停时间 | Spark:Driver:GCTime | ms | >500ms/分钟警告 | 高GC影响作业响应 |

2.6. Kafka（消息队列）

|--------------|---------------------------------------------------------------------------------|--------|------------|----------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| Consumer Lag | kafka.consumer:type=consumer-fetch-manager-metrics,client-id=*:records-lag-max | 条 | >10000 警告 | 消费积压，需扩容消费者或优化处理逻辑 |
| Broker吞吐量 | kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec | B/s | 持续监控 | 评估集群负载能力 |
| 副本同步延迟 | kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions | 个 | >0 危急 | 数据不可靠，需立即排查Broker或网络 |
| 请求处理延迟 | kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Produce | ms | >100ms 警告 | 影响生产者吞吐 |

2.7. ZooKeeper（协调服务）

|-------------------|-------------------------------|--------|----------------------|------------------------|
| 指标名称 | JMX指标名 | 单位 | 推荐阈值 | 说明 |
| 会话数 | ZooKeeper:NumAliveConnections | 个 | >500 警告 | 过多连接可能由客户端未关闭引起 |
| 吞吐量 | ZooKeeper:OutstandingRequests | 个 | >1000 警告 | 高请求量导致响应延迟 |
| 同步延迟 | ZooKeeper:ZxidLatency | ms | >100ms 警告 | 影响集群选举与一致性 |
| Leader与Follower状态 | ZooKeeper:Mode | - | 必须为 leader或 follower | looking状态持续>30s表示选举异常 |

三、监控落地：JMX → Prometheus → Grafana

3.1. 指标采集方案

所有组件均通过 JMX 暴露指标。推荐使用 JMX Exporter 作为中间代理，将JMX指标转换为Prometheus格式：

jmx_exporter_config.yml 示例（YARN ResourceManager）

复制代码

rules:

- pattern: "hadoop:service=ResourceManager,name=QueueMetrics.*"

  name: "yarn_queue_used_capacity"

  labels:

    queue: "$1"

  type: GAUGE

- pattern: "hadoop:service=ResourceManager,name=AppAttemptMetrics.*"

  name: "yarn_app_attempt_failed"

  type: COUNTER

启动命令：

复制代码

java -javaagent:/opt/jmx_prometheus_javaagent.jar=8080:/opt/jmx_exporter_config.yml -jar yarn-resourcemanager.jar

官方支持：Cloudera官方推荐使用JMX Exporter，支持CDH 5.x/6.x全版本。

3.2. 推荐仪表盘（Grafana）

|-----------|--------------------|--------------------------------------|
| 组件 | 推荐Dashboard ID | 说明 |
| YARN | 1860 | 队列资源使用、应用状态、容器分配 |
| HDFS | 1861 | NameNode健康、DataNode状态、存储趋势 |
| HBase | 1862 | RegionServer延迟、MemStore、Region Split |
| Kafka | 1863 | Consumer Lag、Broker吞吐、副本同步 |
| Spark | 1864 | Executor状态、Driver内存、任务执行时间 |
| ZooKeeper | 1865 | 会话数、请求延迟、节点状态 |

可在Grafana官网搜索以上ID导入，或使用Cloudera官方提供的Dashboard模板。

四、告警策略设计

|--------|----------------------------------------------------------------------------------------------|---------------------|---------|
| 级别 | 触发条件 | 响应动作 | 负责人 |
| P0（危急） | HDFS MissingBlocks > 0 ZooKeeper Mode = looking > 30s Kafka UnderReplicatedPartitions > 0 | 立即电话通知自动暂停写入作业 | SRE团队 |
| P1（高） | NameNode RPC延迟 > 200ms YARN Queue Capacity > 95% Spark Executor Failure > 5% | 自动扩容资源发送Slack/钉钉告警 | 运维团队 |
| P2（中） | 磁盘使用率 > 75% Hive Metastore响应 > 200ms Consumer Lag > 10000 | 生成报告通知业务方清理数据 | 数据平台团队 |
| P3（低） | CPU使用率 > 80% GC时间 > 500ms/分钟 | 记录日志，周期性优化 | 开发/运维 |

告警抑制：避免"告警风暴"，对同一集群的多个组件告警设置关联抑制规则（如HDFS磁盘满 → 抑制YARN任务失败告警）。

五、当前存在的问题与建议

|-------------|-------------------------------------------------------|
| 问题 | 建议 |
| 指标分散，缺乏统一视图 | 推行统一监控平台（Prometheus+Grafana），替代Cloudera Manager的碎片化视图 |
| 阈值静态，无法自适应 | 引入动态阈值（如基于历史趋势的异常检测，使用Prometheus的predict_linear） |
| JMX采集性能开销大 | 仅在关键节点部署JMX Exporter，避免全集群开启；使用轻量级Agent（如Telegraf）替代 |
| 缺乏业务指标关联 | 在监控体系中增加业务埋点（如ETL任务完成时间、报表生成延迟） |
| 告警响应流程不闭环 | 建立告警-处理-复盘闭环机制，使用Jira或ServiceNow跟踪处理状态 |

六、附录：推荐工具与资源

官方文档：Cloudera Enterprise 6.x Monitoring Guide
开源Exporter：hadoop_jmx_exporter
Grafana模板库：https://grafana.com/grafana/dashboards/
企业实践：LinkedIn 10,000节点YARN集群监控实践

本体系已覆盖全栈组件，适用于金融、电信、互联网等高可用生产环境。建议每季度复审指标与阈值，适配业务增长。