Apache本身不提供高可用集群吞吐量监控,需针对Kafka、Pulsar、HBase或Ambari等具体组件,通过JMX、pulsar-admin、hbtop或Ambari API采集对应吞吐指标,并结合延迟、资源使用与动态阈值进行交叉分析。

Apache 本身不是集群协调系统,不直接提供“高可用集群节点吞吐量”的原生监控能力。你真正想监控的,通常是基于 Apache 生态构建的分布式系统——比如 Kafka、Pulsar、HBase 或 Ambari 管理的 Hadoop 集群。这些系统常被部署在 Linux(如 AlmaLinux 9)上,并以 Apache 开头命名,但它们各自有独立的指标体系和采集方式。
明确你要监控的具体组件
不同组件的吞吐量定义和采集路径完全不同:
-
Kafka Broker:吞吐量 = 每秒入站/出站字节数(
BytesInPerSec/BytesOutPerSec),通过 JMX 暴露,需启用 JMX 远程端口并配置监控工具(如 Applications Manager、Prometheus + JMX Exporter)采集。 -
Pulsar Broker:吞吐量 = 每秒生产/消费消息数或字节数,可通过
pulsar-admin brokers get-broker-metrics命令或 Prometheus 的pulsar_broker_throughput_*指标获取。 -
HBase RegionServer:吞吐量体现为 QPS(
readRequestsCount/writeRequestsCount),通过 JMX 或hbtop实时查看,P99 延迟比平均值更能反映真实负载压力。 -
Ambari 管理的集群:它本身不产生吞吐量,但可聚合 HDFS、YARN、HBase 等服务的吞吐类指标(如
hdfs_bytes_written、yarn_containers_launched),统一展示在 Ambari Web UI 或导出到 Grafana。
通用采集方法:JMX 是核心入口
绝大多数 Apache 分布式组件(Kafka、Pulsar、HBase、ZooKeeper)都默认启用 JMX,暴露结构化性能指标:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 确保服务启动时开启 JMX(例如 Kafka 添加
-Dcom.sun.management.jmxremote及相关参数); - 配置防火墙放行 JMX 端口(如 9999),并设置访问凭证(若启用认证);
- 使用
jconsole或jmxterm手动连接验证指标是否存在; - 生产环境推荐用 JMX Exporter(Prometheus 生态)或 Applications Manager(商业方案)做长期采集与告警。
可视化与告警不能只看峰值
单看“每秒多少 MB”容易误判。建议结合以下维度交叉分析:
-
按节点拆分:确认吞吐是否均匀分布(如 Kafka 各 broker 的
BytesInPerSec差异是否超过 2 倍); -
关联延迟指标:吞吐上升但
FetchTimeMs(Kafka)或zk_max_latency(ZooKeeper)同步飙升,说明节点已承压; - 绑定资源曲线:将吞吐量图层叠在 CPU、磁盘 IO(特别是 NVMe 队列深度)、网络丢包率上,定位瓶颈环节;
- 设置动态阈值:避免固定值告警(如“>100MB/s”),改用同比/环比突增 50% + 持续 3 分钟触发预警。
快速验证命令(无需装新工具)
登录任一节点后可立即执行:
- Kafka:`echo "get -b kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec RateOne" | java -jar jmxterm.jar -l localhost:9999 -n`
- Pulsar:`bin/pulsar-admin brokers get-broker-metrics --broker-url http://broker-host:8080 | jq '.[] | select(.name == "pulsar_broker_throughput_in")'`
- HBase:`echo "ruok" | nc localhost 2181 && echo "stat" | nc localhost 2181 | grep "Zookeeper version\|Received"`(确认 ZooKeeper 连通性,因 HBase 依赖它)

















