早上到工位之后我一般不是先回消息而是先看一遍 Ambari 或 Cloudera Manager 的 HDFS 仪表盘。干这行久了你会知道HDFS 是整个数据湖的地基Hive、Spark、Flink 全在上面跑它一出事就是大事。而且 HDFS 出问题往往不是瞬间崩掉而是有先兆的——NameNode 堆内存缓慢爬升、DataNode 掉线数量悄悄增加、Under-replicated Blocks 只增不减这些都是仪表盘上的求救信号。问题是你用 Ambari 还是 Cloudera Manager怎么把信号接住怎么在正确的时间做正确的操作才是真本事。这篇东西不打算讲怎么安装 Hadoop那些官方文档已经写得很细了。我主要想聊的是拿到一个已经装好的集群接下来怎么监控 HDFS、怎么设告警、怎么在日常运维里快速定位问题。标题叫HDFS 监控与管理使用 Ambari 和 Cloudera Manager我就顺着 Ambari 和 CM 两条线分别梳理该用命令兜底的地方给命令该讲经验的地方讲经验。适合刚接手集群、准备搭监控的入门运维也适合理清楚两套工具异同、想迁移方案的架构同学。1. HDFS 监控的本质先搞懂要盯什么再谈工具很多人一上来就装监控、配告警结果监控页面上数据倒是刷得飞起真出事了反而不晓得看哪里。这里面的核心问题是你没有把 HDFS 的架构逻辑映射到监控指标上。1.1 先理解 HDFS 的架构再谈监控HDFS 是一个主从架构NameNode 管元数据DataNode 管数据块。你可以把 NameNode 想象成一个公司的财务部——所有文件叫什么、拆成多少块、每块放在哪台机器上它心里都有一本账。DataNode 就是仓库管理员真正把货数据块堆在货架磁盘上的人。那么监控重点就很明确了财务部本身不能出问题NameNode 进程、JVM、RPC 状态仓库管理员不能大面积失联DataNode 心跳、磁盘状态账本跟实际库存不能对不上块副本健康度。这三层展开到一个仪表盘上就是你天天要看的那些指标。也就是为什么我特别反对那种装个 Grafana 拉一堆图表就觉得完事的做法。HDFS 的监控不是看趋势图好看而是每一个指标背后都对应一个可执行的运维动作。看到 Capacity 使用率从 70% 一路涨到 85%你该去扩磁盘或者清数据了看到 RPC 延迟持续超过 50ms你得查是不是有 DataNode 在做磁盘 IO 重负载。指标不是用来看的是用来决策的。1.2 HDFS 监控的核心指标按重要程度排个序在 Ambari 和 CM 里HDFS 服务都有预设的监控指标但我建议你不要照单全收。盯太多反而会错过真正重要的东西。我自己在实践里习惯按这个优先级来看第一梯队决定了 HDFS 还能不能正常服务NameNode 进程状态与 HA 状态进程是否存活、Active/Standby 切没切换过。SafeMode 状态是否处于安全模式后写不可用这是系统级灾难信号。Capacity 使用率集群整体和各 DataNode 的磁盘使用率超过 90% 就是高危。Missing Blocks / Corrupt Blocks缺失块和损坏块数量这个数字代表真实数据损坏程度。第二梯队影响性能但不至于立即瘫痪RPC 队列长度与处理延迟NameNode 单点能承载的请求吞吐队列越长表示越拥挤。JVM 堆内存使用 / Full GC 次数NameNode 在大集群下经常因为堆内存不够或者频繁 GC 导致卡顿。Under-replicated Blocks副本数不足的数据块数量出现回升说明复制流程跟不上。DataNode 心跳延迟超过 5 秒就要留意可能是有节点开始装死了。第三梯队日常调优和容量预测文件数 / Block 数增长趋势为 NameNode 堆内存扩容提供依据文件数上亿后堆内存就是大头。网络 IO / 磁盘 IO 吞吐判断集群运行高峰规划什么时候跑数据均衡任务。EditLog 大小与 FSImage 加载时间NameNode 启动和 checkpoint 的速度直接关系故障恢复时长。1.3 监控工具只是望闻问切别把看到当搞定用 Ambari 或 CM 做监控本质上是给你装了个远程生命体征检测仪。但检测仪只能告诉你哪里疼不能帮你止痛。新手最容易犯的错是看到告警就以为问题解决了——不是的看到的下一步是诊断诊断完才是操作。我带的团队里我经常说一句话监控页面告诉你的永远是结果你要自己通过命令或者日志去找原因。比如 CM 上看到某个 DataNode 心跳丢失仪表盘上就是一个红叉但你是要 SSH 上去看网络丢包、看磁盘状态还是看进程日志工具帮不了你得靠你自己的排查思路。所以下一章起我会把两套工具的操作和底层的排查方法配合起来讲这才是完整的监控闭环。2. Ambari 实战开源工具里的全家桶体验Ambari 是 Apache 的开源项目在 Hortonworks 时代大放异彩。它的定位很明确一键部署、集中管理、以服务为中心做监控告警。给了你一套很完整的全家桶式管理途径HDFS 作为其中的一个服务被管得明明白白。2.1 Ambari 的监控机制与数据链路Ambari 的监控不是自己发明轮子它内部用了两个核心组件Ambari Metrics System简称 AMS和 Ambari Infra。Ambari Metrics Collectors 负责把各节点的监控数据收上来存在内置的 HBaseAmbari Metrics 对应的表里。每个节点上有 Ambari Metrics Monitor负责采集本机指标CPU、内存、磁盘、网络以及 HDFS 各角色的 JVM 和 RPC 指标。Ambari Infra基于 Solr负责存日志比如 NameNode 的日志可以在这里检索。这套机制的优点是数据链路短开箱即用你装完 HDP 之后不用额外配 Prometheus 那套东西就能看到 HDFS 的绝大多数关键指标。缺点是 AMS 把数据存在自己的 HBase 里时间长了磁盘占用会比较大后面我会讲到这个坑。在 Ambari 的 HDFS 服务页你会看到这样几个核心模块SummaryNameNode 和 DataNode 实况、容量、块健康。Heatmap各节点资源热力图一眼看出哪些机器负载高。Metrics以时间序列方式展示指标可以选时间范围放大查看。我一般会在 Metrics 里预先存几个常用视图NameNode 的 RPC 延迟、堆内存使用、DataNode 的磁盘使用趋势。不要等到出事了再临时翻图那时候你连指标叫什么名字都找不到。2.2 把 Ambari 的告警规则调到人话水平Ambari 的告警分为两类一是服务级告警Service Alerts比如 NameNode 存活、DataNode 存活、HDFS 容量告警二是自定义告警Ambari Alert。在 HDFS 服务下找到 Configs Advanced HDFS Default你会的看到一堆跟告警相关的配置项。比较常用的有dfs.namenode.handler.count这是处理 RPC 的线程数跟监控告警没关系但线程数不够时 RPC 队列会涨告警也会跟着报。dfs.namenode.safemode.threshold-pct安全模式阈值这个默认是 0.999f意思是得有 99.9% 的块满足副本条件才退出安全模式。真正跟告警强相关的在 Ambari UI 里是 Alerts 页面。你点进去可以看到每个告警定义比如 HDFS_CAPACITY_USAGE、HDFS_UNDER_REPLICATED_BLOCKS 等。我建议你把以下阈值按自己集群实际情况改一改告警项默认阈值参考我调过后的建议HDFS 容量使用率 Warning70%尽量留足空间做中间数据和副本均衡我一般 Warning 设 75%Critical 设 90%NameNode 堆内存使用率 Warning70%堆内存超过 80% 基本伴随 Full GC我建议 Warning 改 60%Under-replicated Blocks Warning10大集群日常波动的正常值可能在几十个我建议 Warning 设 50DataNode 存活数告警1 个掉线就报我习惯短暂掉线先放一放连续 10 分钟以上才报避免节点重启时告警轰炸改完告警配置之后记得点 Save然后在 Ambari 里重启对应的服务或告警检查器不然配置不生效。这个细节好多人忽略。另外一个实用技巧是Ambari 支持任意指标告警就是你可以在 Alerts 里新建一个告警指定指标名和阈值。比如我想在 NameNode RPC 处理延迟超过 80ms 时收到通知就可以自己建一条。这类 Alert 的语法本质是把指标名写进配置文件里可以在 Ambari 高级配置里找到 alert 定义文件。如果嫌麻烦第一版直接挑常用的服务级告警就够了。2.3 Ambari 的日常管理操作清单Ambari 的价值不只是看板它还能做不少运维操作省掉你去每台机器敲命令的功夫。服务启停在 HDFS 服务页点 Start / Stop 按钮可以一键启动整个 HDFS 服务或者选指定角色操作。滚动重启RESTART也支持从 DataNode 开始分批重启不会出现全部掉线。配置修改与下发在 Configs 页面改完配置直接点 SaveAmbari 会提示你需要重启哪些服务或角色。它会把配置同步到各节点然后按依赖顺序做滚动重启。NameNode HA 切换在 Ambari 里可以选中 Active NameNode执行 Failover 操作方便做定期切换演练。节点管理下线节点时把该 DataNode 从管理中排除DecommissionAmbari 会触发 HDFS 的数据块复制把该节点上的数据搬到其他节点安全完成退役。查看日志Ambari 服务页有 Logs 入口可以检索 NameNode、DataNode 的日志对排查问题有很大帮助。我曾经遇到过某 DataNode 一直起不来靠日志检索一眼就看到是磁盘挂载点没了。2.4 我用 Ambari 踩过的三个坑第一个坑AMS 数据磁盘爆炸。Ambari Metrics Collector 默认会把监控数据存很久在集数据量大的时候这个内置 HBase 能占几十个 GB 甚至上百 GB。解决办法是在 Ambari 的 Metrics Collector 配置里调小数据保留时间ttl一般保留 7 天足够。别等到磁盘被它吃满才想起来。第二个坑Ambari 的告警阈值被重置。升级 Ambari 或者 RHEL 打补丁重启之后自定义告警有时候会恢复默认值需要重新配置。所以我的习惯是把告警配置记在团队的知识库里每次操作后对一遍。第三个坑滚动重启 HDFS 之后部分 DataNode 迟迟不退出安全模式。这种情况通常在集群刚启动、块上报还没完成时最为典型。别急着手动退出安全模式先用hdfs dfsadmin -safemode get看状态再用hdfs dfsadmin -safemode leave手动退出 SLOWLY。如果块健康没问题通常几分钟到十几分钟就会自动退出你手动操作反而可能掩盖底层问题。3. Cloudera Manager 实战企业级监控的显微镜Cloudera ManagerCM跟 Ambari 完全不是一个路子。Ambari 是把开源的东西包一层壳CM 是 Cloudera 自己的全家桶跟 CDH 深度绑定部署起来更闭源但监控粒度、告警体系、管理功能都要重度一些。装完 CM 之后它会默认启动 Cloudera Management ServiceCMS这个服务就是监控核心。3.1 CM 的体系结构谁在采集数据不少人对 CM 的认知是界面挺好看但实际上它的采集架构相当扎实。CMS 下有几个角色Host Monitor采集每台主机的 CPU、内存、磁盘、网络指标Agent 上报。Service Monitor采集 HDFS、YARN 等各种服务的角色指标比如 NameNode 的 RPC、JVM、DataNode 的心跳。Event Server收集各服务的审计日志和事件支持搜索。Activity Monitor跑 MapReduce 任务时采集任务指标不过在 CDH 7 之后的版本里这个角色基本淡出。这套架构下CM 看到的指标比 Ambari 细一个量级。比如同一个 HDFS 容量使用在 Ambari 里你可能只看到百分比在 CM 里你可以看到按目录细分、按 Storage Type 细分DFS Used / Non DFS Used / Remaining甚至能看到每个 DataNode 的磁盘剩余趋势。3.2 告警与健康检查三色状态的背后CM 的告警体系跟 Ambari 最大的区别是它有健康检查这层抽象。每个角色有一套 Health Check 规则比如NameNode 的 RPC 延迟超过多少毫秒算 concern黄超过多少算 bad红。DataNode 心跳超时多久算 bad。HDFS 容量使用率超过多少算 bad。这些规则在 CM UI 里是可视化的对应路径是 Clusters HDFS Configuration Health Checks。你可以点开看每个检查的阈值设置。CM 默认的阈值一般比较保守在大集群里容易频繁报黄我通常会把阈值调宽一点比如 RPC 延迟从 50ms 调到 80ms。告警通道方面CM 支持邮件和 SNMP Trap以及 Webhook在新版本里。邮件是绝大多数团队的标配但需要注意别把邮件告警变成狼来了——阈值太灵敏会让大家麻木最后真出事了没人看邮件。要避免这个局面做法是分级只有 critical 级别的告警发邮件warning 级别的只在 CM 里看一下。3.3 CM 的运维能力边界CM 提供的运维能力比 Ambari 更强主要体现在这几个点配置管理与部署一致性CM 的配置修改有Stale Configuration 的机制如果改了配置没重启它会在界面上明确标记避免了 Ambari 里那种改了配置忘记重启的隐患。滚动重启与角色生命周期对 HDFS 做滚动重启时CM 会自动编排 DataNode 的启停顺序还会在重启前检查副本健康避免数据不安全。这个细节在自动化运维里非常加分。备份与灾难恢复CM 支持对 NameNode 元数据做定期备份也能引导配置备份。虽然实际操作中还是依赖脚本但入口统一了。升级路径CDH 的大版本升级通常通过 CM 的 Upgrade Wizard 完成界面引导式操作比 Ambari 手动升级顺畅太多。CM 的局限在于它是 Cloudera 生态的一部分免费的 Community Edition 有功能限制企业版要付费而且它跟 CDH 绑定得比较紧如果你用的是纯 Apache Hadoop 构建的集群CM 基本帮不上忙。3.4 用 CM 时容易忽略的细节第一CM 的管理服务CMS本身也是需要维护的。Host Monitor 和 Service Monitor 的数据会存在 CM 的监控数据库中时间长了也要清理或者调整保留策略。我的建议是监控数据保留 14 天就够太长了不只是占磁盘查询也慢。第二CM 界面上的指标趋势图会自动做聚合比如把一小时内的数据聚合成一个点。如果你看某个时间段的指标觉得看不清记得把时间范围缩小让它回到原始粒度。我见过有人盯着 24 小时聚合图找不到 10 分钟前那次卡顿的根因。第三CM 的 License 和版本升级节奏比较快每一次升级前都要在官方文档里核对一下你用的 CDH 版本对应的 CM 版本乱升容易导致 Agent 与服务端失联。踩过那次坑之后我养成了一个习惯升级前先把 CM 和 CDH 的版本兼容矩阵截图存档。4. Ambari 与 CM 怎么选一张表理清思路我做运维这些年两套工具都用过也被问过无数次到底哪个好。我的态度一直很明确没有绝对好坏只有场景适不适合。4.1 维度对比从我的实际使用体验出发拉一个对比表格给你。对比维度AmbariCloudera Manager开源程度完全开源Apache 项目企业版收费社区版功能受限部署便捷性界面引导式安装HDP 一体包需要先装 CM Server再通过 Agent 装服务流程更重监控指标粒度基础指标齐全够用指标更多细分维度更深告警配置服务级 / 自定义指标告警可配置可调健康检查机制更成熟可视化更好滚动重启支持但编排能力一般编排能力更强自动检查数据安全升级体验偏手工需要自己盯步骤有向导式升级流程更规范运维自动化一般通过 API 可以做深度自动化社区与生态HDP 停止更新后社区活跃度下降CDP 是当前主力更新快4.2 场景化选型建议如果你是在一个长期跑 Apache Hadoop 生态的团队技术栈比较原汁原味需要开源可控、不受厂商限制Ambari 会更顺手。但要注意HDP 3.x 之后Ambari 的社区维护节奏明显放缓新功能基本停摆。如果你有长期演进规划我个人不太建议新项目再选 Ambari除非你只是需要一个轻量级管理面板。如果你在 Cloudera / CDP 生态里或者团队需要强 SLA、重视监控深度和升级可靠性那 CM 是更合适的答案。它跟 CDH/CDP 的集成深度不是 Ambari 能比的尤其是诊断问题时CM 的图表和日志联动能帮你省下很多时间。不过我得强调一个反直觉的点工具再好也只是管理入口。我见过有人在 Ambari 和 CM 上反复横跳最终发现解决不了问题根本原因是他对 HDFS 本身的运维理解不够。监控工具解决的是看得到和统一操作的问题诊断对处理快还是要靠底层功底。4.3 融会贯通核心指标图在两边都是同一套逻辑不管哪套工具HDFS 健康的本质不会变。你把 Ambari 里 HDFS 的 Summary 页面跟 CM 里 HDFS 的仪表盘放一起对比会发现底层指标高度重合Capacity、Datanodes、Blocks、Missing Blocks、Under-replicated Blocks换了皮肤而已。所以我给团队做培训的时候从来不是教点这里点那里而是教他们先理解 NameNode 和 DataNode 的工作方式再去套工具。理解了 NameNode 是单点、JVM 堆内存有限、RPC 是瓶颈你在哪个工具里都知道要看什么不理解这些工具页面再华丽也只是摆设。5. 命令行兜底与问题排查实录监控工具是给你按快捷键的地方但真正要精确操作的时候命令行是最可靠的后路。Ambari 或者 CM 的 UI 打不开、Agent 失联、服务卡死这些情况我都遇到过最后都是靠一套 HDFS 命令完成诊断的。5.1 仪表盘失灵时命令行怎么顶上去以下是我最常用的几条几乎每个星期都会用查看集群整体状态和容量hdfs dfsadmin -report这条命令的输出会包含每个 DataNode 的容量、使用率、最后心跳时间、DFS Used 比例。哪天你怀疑某个节点掉线了不要只看监控跑一下这个命令一目了然。查看安全模式和副本健康状态hdfs dfsadmin -safemode get hdfs fsck / -files -blockssafemode get确认 NameNode 当前是否在安全模式fsck可以统计整个文件系统的缺失块、损坏副本数。磁盘占满导致安全模式、块丢失这两条命令是必须的。看各目录的占用大小hdfs dfs -du -h /这条命令在清理空间的时候非常好用一分钟就能定位到哪个目录把硬盘吃满了。5.2 真实案例复盘三个典型故障处理讲三个我实际踩过的坑按 HDFS 运维里最常见的场景展开。案例一DataNode 大面积掉线HDFS 进安全模式现象某个机房断电后重新上电Ambari 上看到 20 多个 DataNode 心跳丢失NameNode 自动进入安全模式。判断思路先确认是不是批量网络问题再决定是重拉服务还是等心跳恢复。处理过程第一件事别慌跑hdfs dfsadmin -safemode get确认状态再跑hdfs dfsadmin -report看哪些节点心跳还在。如果只是断电恢复我会等 5 到 10 分钟让 DataNode 的心跳陆续上来。如果等了很久还没恢复再考虑去目标机器上手动重启 DataNode 服务。等大多数节点心跳恢复后观察hdfs fsck输出的缺失副本数量确认没有大规模数据损坏再在低峰期执行hdfs dfsadmin -safemode leave。这里有个要点不要急着手动退出安全模式先让系统自己完成块报告。案例二Under-replicated Blocks 持续增加现象CM 告警里显示 Under-replicated Blocks 从几十涨到上千而且每天还在涨。一开始我以为是某个 DataNode 挂了导致副本损坏上升但检查后发现所有节点在线。排查思路先看是不是某个目录下的文件故意设置了低副本数比如 1 副本再看是不是复制线程不够。HDFS 处理副本复制的速度受dfs.namenode.replication.max-streams参数影响默认是 2大集群里这个值太小会导致复制赶不上损坏速度。处理办法临时把这个参数调大到 6-10并重启 NameNode 让它生效观察一段时间下副本数量开始下降。不过参数调大后 NameNode 的 RPC 开销会上升所以问题解决后记得调回来。案例三NameNode JVM 堆内存告警现象Ambari 里 NameNode 堆内存使用率一直报警每天都在涨GC 频繁RPC 延迟升高。最直接的原因是文件数增长太快堆内存被元数据吃掉了。排查思路先看hdfs dfsadmin -report里的文件数和 Block 数确认是不是元数据膨胀然后在 NameNode 的 hadoop-env.sh 里调大HADOOP_NAMENODE_OPTS的-Xmx值。如果堆已经设得够大比如 64GB你还是频繁 Full GC那就得考虑 federated NameNode 或者做文件清理了。这类调参操作在 Ambari 和 CM 里其实都能改配置但验证逻辑得靠命令行。5.3 三个习惯能帮你少踩一半的坑第一个习惯每次改完配置都记录改了什么、为什么改、预期效果是什么。我自己吃过亏曾经在凌晨调完 RPC 参数第二天忘了改的是哪个查了半小时历史记录才想起来。团队里搞一个简单的运维日志文档或者直接在 CM/Ambari 的配置备注里写一句话都能救命。第二个习惯把监控告警和真实业务运行状态交叉验证。比如你在 Ambari 里看到 HDFS 容量告警但 MapReduce 任务还跑得好好的那可以缓一缓如果容量告警伴随任务大面积失败那就要马上处理。工具给你的指标是绝对数值但运维动作要结合业务影响来判断。第三个习惯维护一套常用的 HDFS 巡检命令脚本每天定时跑一遍把结果存成日志。不需要写多复杂就是上面提到的dfsadmin -report、fsck、目录du这些配合静态分析很多问题在报警前就能被提前发现。说到底HDFS 的监控与管理从来不是装个工具就完事的事。我个人的经验是先吃透 HDFS 的工作原理再把 Ambari 或 CM 当成放大自己操作能力的杠杆最后保留一手命令行兜底的能力。三样凑齐了不管哪套工具、哪个发行版你都能真正镇得住场子。
HDFS监控与管理：Ambari和Cloudera Manager实战指南
早上到工位之后我一般不是先回消息而是先看一遍 Ambari 或 Cloudera Manager 的 HDFS 仪表盘。干这行久了你会知道HDFS 是整个数据湖的地基Hive、Spark、Flink 全在上面跑它一出事就是大事。而且 HDFS 出问题往往不是瞬间崩掉而是有先兆的——NameNode 堆内存缓慢爬升、DataNode 掉线数量悄悄增加、Under-replicated Blocks 只增不减这些都是仪表盘上的求救信号。问题是你用 Ambari 还是 Cloudera Manager怎么把信号接住怎么在正确的时间做正确的操作才是真本事。这篇东西不打算讲怎么安装 Hadoop那些官方文档已经写得很细了。我主要想聊的是拿到一个已经装好的集群接下来怎么监控 HDFS、怎么设告警、怎么在日常运维里快速定位问题。标题叫HDFS 监控与管理使用 Ambari 和 Cloudera Manager我就顺着 Ambari 和 CM 两条线分别梳理该用命令兜底的地方给命令该讲经验的地方讲经验。适合刚接手集群、准备搭监控的入门运维也适合理清楚两套工具异同、想迁移方案的架构同学。1. HDFS 监控的本质先搞懂要盯什么再谈工具很多人一上来就装监控、配告警结果监控页面上数据倒是刷得飞起真出事了反而不晓得看哪里。这里面的核心问题是你没有把 HDFS 的架构逻辑映射到监控指标上。1.1 先理解 HDFS 的架构再谈监控HDFS 是一个主从架构NameNode 管元数据DataNode 管数据块。你可以把 NameNode 想象成一个公司的财务部——所有文件叫什么、拆成多少块、每块放在哪台机器上它心里都有一本账。DataNode 就是仓库管理员真正把货数据块堆在货架磁盘上的人。那么监控重点就很明确了财务部本身不能出问题NameNode 进程、JVM、RPC 状态仓库管理员不能大面积失联DataNode 心跳、磁盘状态账本跟实际库存不能对不上块副本健康度。这三层展开到一个仪表盘上就是你天天要看的那些指标。也就是为什么我特别反对那种装个 Grafana 拉一堆图表就觉得完事的做法。HDFS 的监控不是看趋势图好看而是每一个指标背后都对应一个可执行的运维动作。看到 Capacity 使用率从 70% 一路涨到 85%你该去扩磁盘或者清数据了看到 RPC 延迟持续超过 50ms你得查是不是有 DataNode 在做磁盘 IO 重负载。指标不是用来看的是用来决策的。1.2 HDFS 监控的核心指标按重要程度排个序在 Ambari 和 CM 里HDFS 服务都有预设的监控指标但我建议你不要照单全收。盯太多反而会错过真正重要的东西。我自己在实践里习惯按这个优先级来看第一梯队决定了 HDFS 还能不能正常服务NameNode 进程状态与 HA 状态进程是否存活、Active/Standby 切没切换过。SafeMode 状态是否处于安全模式后写不可用这是系统级灾难信号。Capacity 使用率集群整体和各 DataNode 的磁盘使用率超过 90% 就是高危。Missing Blocks / Corrupt Blocks缺失块和损坏块数量这个数字代表真实数据损坏程度。第二梯队影响性能但不至于立即瘫痪RPC 队列长度与处理延迟NameNode 单点能承载的请求吞吐队列越长表示越拥挤。JVM 堆内存使用 / Full GC 次数NameNode 在大集群下经常因为堆内存不够或者频繁 GC 导致卡顿。Under-replicated Blocks副本数不足的数据块数量出现回升说明复制流程跟不上。DataNode 心跳延迟超过 5 秒就要留意可能是有节点开始装死了。第三梯队日常调优和容量预测文件数 / Block 数增长趋势为 NameNode 堆内存扩容提供依据文件数上亿后堆内存就是大头。网络 IO / 磁盘 IO 吞吐判断集群运行高峰规划什么时候跑数据均衡任务。EditLog 大小与 FSImage 加载时间NameNode 启动和 checkpoint 的速度直接关系故障恢复时长。1.3 监控工具只是望闻问切别把看到当搞定用 Ambari 或 CM 做监控本质上是给你装了个远程生命体征检测仪。但检测仪只能告诉你哪里疼不能帮你止痛。新手最容易犯的错是看到告警就以为问题解决了——不是的看到的下一步是诊断诊断完才是操作。我带的团队里我经常说一句话监控页面告诉你的永远是结果你要自己通过命令或者日志去找原因。比如 CM 上看到某个 DataNode 心跳丢失仪表盘上就是一个红叉但你是要 SSH 上去看网络丢包、看磁盘状态还是看进程日志工具帮不了你得靠你自己的排查思路。所以下一章起我会把两套工具的操作和底层的排查方法配合起来讲这才是完整的监控闭环。2. Ambari 实战开源工具里的全家桶体验Ambari 是 Apache 的开源项目在 Hortonworks 时代大放异彩。它的定位很明确一键部署、集中管理、以服务为中心做监控告警。给了你一套很完整的全家桶式管理途径HDFS 作为其中的一个服务被管得明明白白。2.1 Ambari 的监控机制与数据链路Ambari 的监控不是自己发明轮子它内部用了两个核心组件Ambari Metrics System简称 AMS和 Ambari Infra。Ambari Metrics Collectors 负责把各节点的监控数据收上来存在内置的 HBaseAmbari Metrics 对应的表里。每个节点上有 Ambari Metrics Monitor负责采集本机指标CPU、内存、磁盘、网络以及 HDFS 各角色的 JVM 和 RPC 指标。Ambari Infra基于 Solr负责存日志比如 NameNode 的日志可以在这里检索。这套机制的优点是数据链路短开箱即用你装完 HDP 之后不用额外配 Prometheus 那套东西就能看到 HDFS 的绝大多数关键指标。缺点是 AMS 把数据存在自己的 HBase 里时间长了磁盘占用会比较大后面我会讲到这个坑。在 Ambari 的 HDFS 服务页你会看到这样几个核心模块SummaryNameNode 和 DataNode 实况、容量、块健康。Heatmap各节点资源热力图一眼看出哪些机器负载高。Metrics以时间序列方式展示指标可以选时间范围放大查看。我一般会在 Metrics 里预先存几个常用视图NameNode 的 RPC 延迟、堆内存使用、DataNode 的磁盘使用趋势。不要等到出事了再临时翻图那时候你连指标叫什么名字都找不到。2.2 把 Ambari 的告警规则调到人话水平Ambari 的告警分为两类一是服务级告警Service Alerts比如 NameNode 存活、DataNode 存活、HDFS 容量告警二是自定义告警Ambari Alert。在 HDFS 服务下找到 Configs Advanced HDFS Default你会的看到一堆跟告警相关的配置项。比较常用的有dfs.namenode.handler.count这是处理 RPC 的线程数跟监控告警没关系但线程数不够时 RPC 队列会涨告警也会跟着报。dfs.namenode.safemode.threshold-pct安全模式阈值这个默认是 0.999f意思是得有 99.9% 的块满足副本条件才退出安全模式。真正跟告警强相关的在 Ambari UI 里是 Alerts 页面。你点进去可以看到每个告警定义比如 HDFS_CAPACITY_USAGE、HDFS_UNDER_REPLICATED_BLOCKS 等。我建议你把以下阈值按自己集群实际情况改一改告警项默认阈值参考我调过后的建议HDFS 容量使用率 Warning70%尽量留足空间做中间数据和副本均衡我一般 Warning 设 75%Critical 设 90%NameNode 堆内存使用率 Warning70%堆内存超过 80% 基本伴随 Full GC我建议 Warning 改 60%Under-replicated Blocks Warning10大集群日常波动的正常值可能在几十个我建议 Warning 设 50DataNode 存活数告警1 个掉线就报我习惯短暂掉线先放一放连续 10 分钟以上才报避免节点重启时告警轰炸改完告警配置之后记得点 Save然后在 Ambari 里重启对应的服务或告警检查器不然配置不生效。这个细节好多人忽略。另外一个实用技巧是Ambari 支持任意指标告警就是你可以在 Alerts 里新建一个告警指定指标名和阈值。比如我想在 NameNode RPC 处理延迟超过 80ms 时收到通知就可以自己建一条。这类 Alert 的语法本质是把指标名写进配置文件里可以在 Ambari 高级配置里找到 alert 定义文件。如果嫌麻烦第一版直接挑常用的服务级告警就够了。2.3 Ambari 的日常管理操作清单Ambari 的价值不只是看板它还能做不少运维操作省掉你去每台机器敲命令的功夫。服务启停在 HDFS 服务页点 Start / Stop 按钮可以一键启动整个 HDFS 服务或者选指定角色操作。滚动重启RESTART也支持从 DataNode 开始分批重启不会出现全部掉线。配置修改与下发在 Configs 页面改完配置直接点 SaveAmbari 会提示你需要重启哪些服务或角色。它会把配置同步到各节点然后按依赖顺序做滚动重启。NameNode HA 切换在 Ambari 里可以选中 Active NameNode执行 Failover 操作方便做定期切换演练。节点管理下线节点时把该 DataNode 从管理中排除DecommissionAmbari 会触发 HDFS 的数据块复制把该节点上的数据搬到其他节点安全完成退役。查看日志Ambari 服务页有 Logs 入口可以检索 NameNode、DataNode 的日志对排查问题有很大帮助。我曾经遇到过某 DataNode 一直起不来靠日志检索一眼就看到是磁盘挂载点没了。2.4 我用 Ambari 踩过的三个坑第一个坑AMS 数据磁盘爆炸。Ambari Metrics Collector 默认会把监控数据存很久在集数据量大的时候这个内置 HBase 能占几十个 GB 甚至上百 GB。解决办法是在 Ambari 的 Metrics Collector 配置里调小数据保留时间ttl一般保留 7 天足够。别等到磁盘被它吃满才想起来。第二个坑Ambari 的告警阈值被重置。升级 Ambari 或者 RHEL 打补丁重启之后自定义告警有时候会恢复默认值需要重新配置。所以我的习惯是把告警配置记在团队的知识库里每次操作后对一遍。第三个坑滚动重启 HDFS 之后部分 DataNode 迟迟不退出安全模式。这种情况通常在集群刚启动、块上报还没完成时最为典型。别急着手动退出安全模式先用hdfs dfsadmin -safemode get看状态再用hdfs dfsadmin -safemode leave手动退出 SLOWLY。如果块健康没问题通常几分钟到十几分钟就会自动退出你手动操作反而可能掩盖底层问题。3. Cloudera Manager 实战企业级监控的显微镜Cloudera ManagerCM跟 Ambari 完全不是一个路子。Ambari 是把开源的东西包一层壳CM 是 Cloudera 自己的全家桶跟 CDH 深度绑定部署起来更闭源但监控粒度、告警体系、管理功能都要重度一些。装完 CM 之后它会默认启动 Cloudera Management ServiceCMS这个服务就是监控核心。3.1 CM 的体系结构谁在采集数据不少人对 CM 的认知是界面挺好看但实际上它的采集架构相当扎实。CMS 下有几个角色Host Monitor采集每台主机的 CPU、内存、磁盘、网络指标Agent 上报。Service Monitor采集 HDFS、YARN 等各种服务的角色指标比如 NameNode 的 RPC、JVM、DataNode 的心跳。Event Server收集各服务的审计日志和事件支持搜索。Activity Monitor跑 MapReduce 任务时采集任务指标不过在 CDH 7 之后的版本里这个角色基本淡出。这套架构下CM 看到的指标比 Ambari 细一个量级。比如同一个 HDFS 容量使用在 Ambari 里你可能只看到百分比在 CM 里你可以看到按目录细分、按 Storage Type 细分DFS Used / Non DFS Used / Remaining甚至能看到每个 DataNode 的磁盘剩余趋势。3.2 告警与健康检查三色状态的背后CM 的告警体系跟 Ambari 最大的区别是它有健康检查这层抽象。每个角色有一套 Health Check 规则比如NameNode 的 RPC 延迟超过多少毫秒算 concern黄超过多少算 bad红。DataNode 心跳超时多久算 bad。HDFS 容量使用率超过多少算 bad。这些规则在 CM UI 里是可视化的对应路径是 Clusters HDFS Configuration Health Checks。你可以点开看每个检查的阈值设置。CM 默认的阈值一般比较保守在大集群里容易频繁报黄我通常会把阈值调宽一点比如 RPC 延迟从 50ms 调到 80ms。告警通道方面CM 支持邮件和 SNMP Trap以及 Webhook在新版本里。邮件是绝大多数团队的标配但需要注意别把邮件告警变成狼来了——阈值太灵敏会让大家麻木最后真出事了没人看邮件。要避免这个局面做法是分级只有 critical 级别的告警发邮件warning 级别的只在 CM 里看一下。3.3 CM 的运维能力边界CM 提供的运维能力比 Ambari 更强主要体现在这几个点配置管理与部署一致性CM 的配置修改有Stale Configuration 的机制如果改了配置没重启它会在界面上明确标记避免了 Ambari 里那种改了配置忘记重启的隐患。滚动重启与角色生命周期对 HDFS 做滚动重启时CM 会自动编排 DataNode 的启停顺序还会在重启前检查副本健康避免数据不安全。这个细节在自动化运维里非常加分。备份与灾难恢复CM 支持对 NameNode 元数据做定期备份也能引导配置备份。虽然实际操作中还是依赖脚本但入口统一了。升级路径CDH 的大版本升级通常通过 CM 的 Upgrade Wizard 完成界面引导式操作比 Ambari 手动升级顺畅太多。CM 的局限在于它是 Cloudera 生态的一部分免费的 Community Edition 有功能限制企业版要付费而且它跟 CDH 绑定得比较紧如果你用的是纯 Apache Hadoop 构建的集群CM 基本帮不上忙。3.4 用 CM 时容易忽略的细节第一CM 的管理服务CMS本身也是需要维护的。Host Monitor 和 Service Monitor 的数据会存在 CM 的监控数据库中时间长了也要清理或者调整保留策略。我的建议是监控数据保留 14 天就够太长了不只是占磁盘查询也慢。第二CM 界面上的指标趋势图会自动做聚合比如把一小时内的数据聚合成一个点。如果你看某个时间段的指标觉得看不清记得把时间范围缩小让它回到原始粒度。我见过有人盯着 24 小时聚合图找不到 10 分钟前那次卡顿的根因。第三CM 的 License 和版本升级节奏比较快每一次升级前都要在官方文档里核对一下你用的 CDH 版本对应的 CM 版本乱升容易导致 Agent 与服务端失联。踩过那次坑之后我养成了一个习惯升级前先把 CM 和 CDH 的版本兼容矩阵截图存档。4. Ambari 与 CM 怎么选一张表理清思路我做运维这些年两套工具都用过也被问过无数次到底哪个好。我的态度一直很明确没有绝对好坏只有场景适不适合。4.1 维度对比从我的实际使用体验出发拉一个对比表格给你。对比维度AmbariCloudera Manager开源程度完全开源Apache 项目企业版收费社区版功能受限部署便捷性界面引导式安装HDP 一体包需要先装 CM Server再通过 Agent 装服务流程更重监控指标粒度基础指标齐全够用指标更多细分维度更深告警配置服务级 / 自定义指标告警可配置可调健康检查机制更成熟可视化更好滚动重启支持但编排能力一般编排能力更强自动检查数据安全升级体验偏手工需要自己盯步骤有向导式升级流程更规范运维自动化一般通过 API 可以做深度自动化社区与生态HDP 停止更新后社区活跃度下降CDP 是当前主力更新快4.2 场景化选型建议如果你是在一个长期跑 Apache Hadoop 生态的团队技术栈比较原汁原味需要开源可控、不受厂商限制Ambari 会更顺手。但要注意HDP 3.x 之后Ambari 的社区维护节奏明显放缓新功能基本停摆。如果你有长期演进规划我个人不太建议新项目再选 Ambari除非你只是需要一个轻量级管理面板。如果你在 Cloudera / CDP 生态里或者团队需要强 SLA、重视监控深度和升级可靠性那 CM 是更合适的答案。它跟 CDH/CDP 的集成深度不是 Ambari 能比的尤其是诊断问题时CM 的图表和日志联动能帮你省下很多时间。不过我得强调一个反直觉的点工具再好也只是管理入口。我见过有人在 Ambari 和 CM 上反复横跳最终发现解决不了问题根本原因是他对 HDFS 本身的运维理解不够。监控工具解决的是看得到和统一操作的问题诊断对处理快还是要靠底层功底。4.3 融会贯通核心指标图在两边都是同一套逻辑不管哪套工具HDFS 健康的本质不会变。你把 Ambari 里 HDFS 的 Summary 页面跟 CM 里 HDFS 的仪表盘放一起对比会发现底层指标高度重合Capacity、Datanodes、Blocks、Missing Blocks、Under-replicated Blocks换了皮肤而已。所以我给团队做培训的时候从来不是教点这里点那里而是教他们先理解 NameNode 和 DataNode 的工作方式再去套工具。理解了 NameNode 是单点、JVM 堆内存有限、RPC 是瓶颈你在哪个工具里都知道要看什么不理解这些工具页面再华丽也只是摆设。5. 命令行兜底与问题排查实录监控工具是给你按快捷键的地方但真正要精确操作的时候命令行是最可靠的后路。Ambari 或者 CM 的 UI 打不开、Agent 失联、服务卡死这些情况我都遇到过最后都是靠一套 HDFS 命令完成诊断的。5.1 仪表盘失灵时命令行怎么顶上去以下是我最常用的几条几乎每个星期都会用查看集群整体状态和容量hdfs dfsadmin -report这条命令的输出会包含每个 DataNode 的容量、使用率、最后心跳时间、DFS Used 比例。哪天你怀疑某个节点掉线了不要只看监控跑一下这个命令一目了然。查看安全模式和副本健康状态hdfs dfsadmin -safemode get hdfs fsck / -files -blockssafemode get确认 NameNode 当前是否在安全模式fsck可以统计整个文件系统的缺失块、损坏副本数。磁盘占满导致安全模式、块丢失这两条命令是必须的。看各目录的占用大小hdfs dfs -du -h /这条命令在清理空间的时候非常好用一分钟就能定位到哪个目录把硬盘吃满了。5.2 真实案例复盘三个典型故障处理讲三个我实际踩过的坑按 HDFS 运维里最常见的场景展开。案例一DataNode 大面积掉线HDFS 进安全模式现象某个机房断电后重新上电Ambari 上看到 20 多个 DataNode 心跳丢失NameNode 自动进入安全模式。判断思路先确认是不是批量网络问题再决定是重拉服务还是等心跳恢复。处理过程第一件事别慌跑hdfs dfsadmin -safemode get确认状态再跑hdfs dfsadmin -report看哪些节点心跳还在。如果只是断电恢复我会等 5 到 10 分钟让 DataNode 的心跳陆续上来。如果等了很久还没恢复再考虑去目标机器上手动重启 DataNode 服务。等大多数节点心跳恢复后观察hdfs fsck输出的缺失副本数量确认没有大规模数据损坏再在低峰期执行hdfs dfsadmin -safemode leave。这里有个要点不要急着手动退出安全模式先让系统自己完成块报告。案例二Under-replicated Blocks 持续增加现象CM 告警里显示 Under-replicated Blocks 从几十涨到上千而且每天还在涨。一开始我以为是某个 DataNode 挂了导致副本损坏上升但检查后发现所有节点在线。排查思路先看是不是某个目录下的文件故意设置了低副本数比如 1 副本再看是不是复制线程不够。HDFS 处理副本复制的速度受dfs.namenode.replication.max-streams参数影响默认是 2大集群里这个值太小会导致复制赶不上损坏速度。处理办法临时把这个参数调大到 6-10并重启 NameNode 让它生效观察一段时间下副本数量开始下降。不过参数调大后 NameNode 的 RPC 开销会上升所以问题解决后记得调回来。案例三NameNode JVM 堆内存告警现象Ambari 里 NameNode 堆内存使用率一直报警每天都在涨GC 频繁RPC 延迟升高。最直接的原因是文件数增长太快堆内存被元数据吃掉了。排查思路先看hdfs dfsadmin -report里的文件数和 Block 数确认是不是元数据膨胀然后在 NameNode 的 hadoop-env.sh 里调大HADOOP_NAMENODE_OPTS的-Xmx值。如果堆已经设得够大比如 64GB你还是频繁 Full GC那就得考虑 federated NameNode 或者做文件清理了。这类调参操作在 Ambari 和 CM 里其实都能改配置但验证逻辑得靠命令行。5.3 三个习惯能帮你少踩一半的坑第一个习惯每次改完配置都记录改了什么、为什么改、预期效果是什么。我自己吃过亏曾经在凌晨调完 RPC 参数第二天忘了改的是哪个查了半小时历史记录才想起来。团队里搞一个简单的运维日志文档或者直接在 CM/Ambari 的配置备注里写一句话都能救命。第二个习惯把监控告警和真实业务运行状态交叉验证。比如你在 Ambari 里看到 HDFS 容量告警但 MapReduce 任务还跑得好好的那可以缓一缓如果容量告警伴随任务大面积失败那就要马上处理。工具给你的指标是绝对数值但运维动作要结合业务影响来判断。第三个习惯维护一套常用的 HDFS 巡检命令脚本每天定时跑一遍把结果存成日志。不需要写多复杂就是上面提到的dfsadmin -report、fsck、目录du这些配合静态分析很多问题在报警前就能被提前发现。说到底HDFS 的监控与管理从来不是装个工具就完事的事。我个人的经验是先吃透 HDFS 的工作原理再把 Ambari 或 CM 当成放大自己操作能力的杠杆最后保留一手命令行兜底的能力。三样凑齐了不管哪套工具、哪个发行版你都能真正镇得住场子。