简介面向大数据集群管理员、运维工程师及BI平台支撑人员这份《大数据集群Cloudera Manager日常运维手册》是一份以实际操作为导向的CM平台维护指南帮助读者快速掌握从登录入口到日常配置变更的完整流程。它覆盖了集群生命周期管理中最高频的操作场景登录Cloudera Manager管理页面启动、停止或重启Cloudera Management Service按批次启停Hadoop所有服务对HDFS、Hive、MapReduce、ZooKeeper等常用组件做单项启停精确控制单个节点上的Datanode、Namenode等角色进程以及修改全局或单节点级别的blocksize等配置参数。每个操作都按“操作前检查—执行—结果确认”展开明确强调先启动Cloudera Management Service再启动Hadoop相关服务、修改参数保存后需部署客户端配置或重启对应服务等注意事项避免因启动顺序或生效流程不当造成服务异常。文档还包含服务状态判断、重启生效确认等排查要点适合正在维护CDH/CDP集群的初中级工程师随手查阅也可作为团队培训速查材料。文档目录层级清晰便于快速定位到目标章节。资源共1个docx文件约1.55MB虽内容精炼但覆盖足够完整。目前已有591人学习下载是久经验证的轻量级运维参考。1. 为什么 Cloudera Manager 的日常运维本质上是在管两套系统接手一套 CDH 集群时很多人会先看 HDFS 容量、YARN 队列、Hive 表数量却忽略一个事实Cloudera Manager 自身也是需要被运维的对象而且它的故障优先级远高于其管理的大数据组件。一个只有几台机器的实验集群上CM Server 进程挂掉的影响常常比 DataNode 掉线更大——因为元数据不可达时你连“谁挂了”都查不到。日常运维 CM 的难度在于它同时管理“CM 自身的生命周期”和“受管组件的生命周期”前者出问题会直接导致后者失去可控性。本文不打算重复官方文档的逐屏点击说明而是按一线运维的实操链路来写从架构认知、进程健康检查到配置变更、滚动升级、备份恢复最后落在几个真实场景的排错和自动化巡检上。熟悉各发行版 Hadoop 手工部署的老手也能在这里找到把 Cluster 与 CM 解耦管理的思路。2. Cloudera Manager 架构与日常巡检最小命令集2.1 Server、Agent、数据库的职责边界Cloudera Manager 的经典架构是 Server-数据库-Agent 三段式。Server 通过 HTTPS 提供管理界面和 API所有配置的持久化落在元数据库通常是内嵌的 PostgreSQL 或外部 MySQL/MariaDBAgent 则以守护进程方式跑在每台受管主机上负责接收命令、上报心跳、启动和停止组件。你可以用以下命令直接确认三者的进程状态# 检查 CM Server 主进程 sudo systemctl status cloudera-scm-server # 检查单个主机上的 Agent sudo systemctl status cloudera-scm-agent # 查看元数据库连接是否正常以 MySQL 5.7 为例 mysql -h cm-host -u scm -p -e select 1; scm这三行命令回答的是三个独立问题Server 本身的 JVM 是否活着、Agent 与 Server 之间的通道是否通、数据库能否响应查询。它们任意一环断了Web 界面都会表现出不同症状。排查时不要一上来就重启整个 Server——先分清是某个 Agent 失联还是 Server 进程整体僵死否则一个误操作会把仍在服务的集群拖下水。2.2 巡检要从日志与指标双通道入手日常巡检不建议只盯着 CM 首页的绿色图标。图标的颜色来自 Server 对 Agent 心跳和组件运行状态的聚合结果心跳默认按 15 秒周期上报。这个值可以调但不是建议你乱调——心跳过快里会造成 Server 端负载偏高过慢则会让故障发现延迟。保持默认的 15 秒即可你更需要的是直接的监控数据# 查看 Agent 与 Server 的上次心跳时间 sudo grep -i heartbeat /var/log/cloudera-scm-agent/cloudera-scm-agent.log | tail -20 # 查看 Server 自身的内存压力 sudo tail -100 /var/log/cloudera-scm-server/cloudera-scm-server.logAgent 日志中与 heartbeat 相关的行如果频繁出现“wait for next heartbeat”或 RPC 超时说明主导的 TCP 连接质量不稳定下一步检查 Server 主机到 Agent 主机的网络延迟与丢包。这里有一个常见的认知偏差Cloudera Manager 管理的组件流量与它本身的控制流量是走同一条物理链路的所以大数据业务跑满带宽时CM 控制通道也可能被拖垮。巡检时不要只看集群组件状态表也要看每个主机的入向出向流量。2.3 用 API 替代页面完成快速摸底CM 提供了完整免登陆的 REST API日常运维用批量脚本比在界面上逐个点击效率高得多。API 的默认端口是 7180HTTP和 7183HTTPS认证方式为 Basic Auth通常使用管理员账号或专用只读账号。# 获取集群内所有主机的健康状态汇总 curl -u admin:admin http://cm-host:7180/api/v19/hosts | python -m json.tool # 获取某个服务的运行状态 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201/services | python -c import sys,json; [print(s[name], s[healthSummary], s[serviceState]) for s in json.load(sys.stdin)[items]]注意 API 路径中的Cluster%201是默认集群名的 URL 编码如果你的集群改名了需要替换成对应名称。这里的用途是批量巡检把多个命令写进一个 shell 脚本定时跑一遍把 healthSummary 不是 GOOD 的服务输出出来。实际使用中API 的 v19 版本覆盖了 CDH 6.x 的核心功能更高版本的 API 多数是对新组件功能的扩展日常巡检不必追新。3. 配置变更与滚动重启的正确操作路径3.1 配置下发到底是改什么Cloudera Manager 的配置管理可以类比成一套“两层模板”系统。第一层是 CM 内置的服务级配置模板第二层是配置组Config Group。每个配置组会有与之对应的一组主机同一服务的不同配置组可以拥有不同的进程参数。最常见的做法是把 Master 节点与 Worker 节点划分到不同配置组给前者分配更大的 JVM 堆内存。如果你要调整 HDFS DataNode 的堆内存常规做法是在 CM 界面进入 HDFS 服务选择“配置”标签页找到Java Heap Size of DataNode修改并保存。改成后用 API 验证参数是否真的到了目标主机# 获取 DataNode 角色所在主机的实际 Java 参数通过服务端 API 触发配置预览 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201/services/hdfs/roleConfigGroups | python -c import sys,json; datajson.load(sys.stdin); [print(c[name], c[configs]) for c in data[items] if DATANODE in c[roleType]]注意保存配置与“让配置生效”是两回事。CM 的“保存”只是修改了数据库里的持久化配置要用户主动执行“重启”或“滚动重启”才会下发到实际进程。如果只保存不重启下次组件自动故障重启时会自动带上新配置反而造成不可预期的行为。3.2 滚动重启的参数与影响面控制重启大数据组件不是简单地把所有角色一起停再一起起。HDFS、YARN、Kafka 这类有状态服务必须采用滚动方式一次只处理一个角色完成后继续下一个。CM 界面里对应的操作是“滚动重启Rolling Restart”命令行方式可以通过 API 触发# 对 HDFS 执行滚动重启staleConfigs 状态下会先通知再逐步重启 curl -u admin:admin -X POST \ http://cm-host:7180/api/v19/clusters/Cluster%201/services/hdfs/commands/restart \ -H Content-Type: application/json \ -d {restartRoleTypes:[DATANODE,NAMENODE],rollingRestart:true}这条命令要留意两点。第一滚动重启的总耗时远高于一次性重启一个 100 个 DataNode 的集群可能要花 40 分钟以上要预留充足窗口。第二NameNode 的滚动重启会让客户端感知到 RPC 闪断Hive/Spark 作业需要重试机制兜底。Yarn NodeManager 的滚动重启用-d指定了slaveGracefulShutdownTimeout参数才有意义——它给正在运行的 Container 一个存活迁移的宽限期。给出的建议是批次大小调小分多轮滚动比一次滚动所有角色更可控。CM 高级配置中Rolling Restart Batch Size默认是 1保持这个值不要改大你失去的只是时间得到的是每次只挂一个节点的确定性。3.3 涉密参数与安全和性能的平衡日常运维少不了手写自定义配置CM 的“高级配置代码段安全阀”机制专门给这类场景用。常见的两个场景在 HDFS 的hdfs-site.xml安全阀里加写入限制或者在 Kafka 的server.properties安全阀里调整num.io.threads。!-- hdfs-site.xml 安全阀片段 -- property namedfs.replication.max/name value2/value description限制文件最大副本数防止个别任务误写过大或异常副本扩散/description /property这类安全阀配置上线前必须先在测试环境验证。它直接写入服务端配置文件语法错误会导致组件启动失败排查难度在于 Web 界面上看到的错误信息常常是“找不到配置项”而不是真正的语法原因。标注清楚响应的后台文件路径能让排错时间缩短一半HDFS 的配置在/etc/hadoop/conf.cloudera.hdfs/hdfs-site.xmlKafka 在/etc/kafka/conf/kafka.properties。改动后第一时间去本地查这两个文件是否与预期一致避免等组件拉起失败后再反向追踪。4. 故障场景排查与关键参数的自我体检4.1 页面打不开、502、502.3 这类入口故障CM 入口故障是日常“看起来最吓人、实际上最好修”的一类。页面打不开的一线排查顺序是先确认 Server 进程活着再确认端口在监听然后才考虑查日志。# 1. 端口监听状态 sudo ss -lntp | grep 7180 # 2. 看 Server 是否抛出了内存错误 sudo grep -i outofmemory\|GC overhead /var/log/cloudera-scm-server/cloudera-scm-server.log # 3. 最近 50 行完整日志重点看 ERROR 与 WARN sudo tail -50 /var/log/cloudera-scm-server/cloudera-scm-server.log如果日志中频繁出现 GC 等待且堆内存占用一直处于高位常见做法是调大 CM Server 自身的 JVM 参数在/etc/cloudera-scm-server/db.properties旁的同目录下找cloudera-scm-server.conf或 systemd drop-in 文件修改-Xmx参数。CM Server 默认堆上限在 2GB 到 4GB 之间管理 100 台以上的集群时建议至少翻倍否则元数据查询与图表渲染都会产生卡顿。不要走“重启一下试试”这条捷径。CM Server 在重启过程中会短暂失去对所有 Agent 的管理通道某些 Agent 的避免心跳重置可能触发重新部署命令进一步加重 Server 启动压力。正确路径是先看日志定位问题再决定是否重启。4.2 大多数 Agent 失联的根因与恢复清单当集群页面上一片黄色、很多主机同时显示“上次心跳时间较早”大概率不是网络故障而是 Server 端资源耗尽或数据库连接被占满。因为单个 Agent 掉线通常是那台机器自身的问题多个主机集体掉线时问题往往出在汇聚端。数据库连接耗尽是比较隐蔽的元凶。CM 的元数据库需要同时支撑 Server 写入、读写 API 与监控数据落盘。排查时直接查数据库连接数# MySQL 中查看连接数及来自 CM Server 的占用 mysql -u scm -p -e show processlist; | grep -c cloudera-scm-server # 确认连接数是否触及 max_connections 上限 mysql -u root -p -e show variables like max_connections;如果连接数打满临时扩大max_connections只能缓解症状真正的解法是把 CM 里的监控数据保留时长缩短进入“管理→监控”界面把每个指标的分辨率保留时间如 15 分钟粒度保留 7 天、1 小时粒度保留 30 天调低。CM 的监控库如果用的是独立的时序存储在 CM 6.3 以后支持用本地 RocksDB其磁盘占用常年在膨胀膨胀到磁盘满时整个 Server 都会停摆。日常运维把监控数据保留策略写进巡检项比事后扩大磁盘来得实际。Agent 失联的另一道检查是看 TLS 证书。CM 的 Agent 与 Server 之间如果启用了 TLS证书过期会导致握手失败症状同样是心跳中止。你可以用openssl直接检查 Server 端证书有效期sudo echo | openssl s_client -connect localhost:7183 2/dev/null | openssl x509 -noout -dates证书日期一旦临近去 CM 的安全设置里重新生成并分发 Agent 端信任链这个流程不复杂但耗时长值得在节点维护窗口提前做。不提前做的后果是某个凌晨证书到期第二天上班你面对一整屏的主机“失去联系”恢复方式只剩手工替换证书后逐个 Agent期间的作业全部受影响。4.3 垃圾回收长暂停导致的“组件假死”CM 监控页面上能看到的组件状态是“健康”但业务反馈 Hive 查询卡住这种情况往往不是组件的单一原因而是 JVM GC 长暂停。CM 的角色页面展示的Last GC指标能帮助你快速定位哪些角色正在经历长 GC。# 从 YARN ResourceManager 日志中查看长时间 GC 的记录 sudo grep -i garbage\|gc /var/log/hadoop-yarn/hadoop-yarn-resourcemanager-*.log | tail -50GC 问题基本落到两个常规修法增大堆内存或者调整年轻代与老年代的比例。对计算型角色NodeManager、RegionServer看到Full GC高频出现时优先考虑是堆分配与实体使用量不匹配调整-XX:MaxNewSize或换用 G1 收集器的参数-XX:UseG1GC比盲目加-Xmx更安全。加-Xmx只是在延长下一次 Full GC 的时间真正的改善来自合理设置堆内缓存与内存分配上限。举 HBase RegionServer 的例子CM 界面中需要同时改hbase.regionserver.global.memstore.size与hfile.block.cache.size两者加起来通常在 0.6 以内超过了会频繁触发全堆 GC。5. Cloudera Manager 元数据备份恢复与一键巡检5.1 备份内容的三个维度维护 Cloudera Manager 集群最重要的习惯不是备份 HDFS 里的业务数据而是备份 CM 自身。CM 的可备份内容分三个维度Server 的配置与集群定义在元数据库里、监控时间序列数据如果是内嵌存储则独立落盘、以及受管主机上的 Agent 配置。第三个维度容易被忽略——当你批量重装 Agent 后如果它的config.ini丢失重新加入集群时大概率要手动指定 Server 地址和身份认证信息。推荐用 CM API 定期把集群与服务配置导出这在版本升级前尤其重要# 导出整个 cluster 的配置快照 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201?viewFULL \ /backup/cm/cluster_config_$(date %F).json配合每日自动 dump 元数据库MySQL 的mysqldump或 PostgreSQL 的pg_dump可实现 CM 自身的可重建最小集。需把 CM 的数据库用户权限限定为最小化——这个账号只导自身库即可不需要也不应该接触任何业务库。5.2 恢复演练的价值与所有备份体系一样备份的有效性必须用恢复演练来验证。多数团队的日常只是把 dump 文件丢到磁盘上但没人回答过“这台 CM Server 彻底宕掉后多久能拉起一个可用的管理面”。搭建恢复演练环境时需要有同版本 or 相近版本的 CM/OS 依赖它会改变视图与版本细节影响恢复过程耗时。这里想提醒的不是“版本怎么选”而是“恢复后的配置需要验证三个点”Agent 能否正常注册并显示健康、HDFS 服务能否正常启动与底层数据无关的服务级恢复即算成功、以及配置快照与元数据导出的时间差要在业务可接受范围内。备份周期建议与元数据变更频率强相关如果团队每天都在改队列配置或调参按天导一次库并不夸张。变更好习惯是每次做配置变更前手动手动触发一次快照备份这个动作不需要依赖 IT 运维平台几秒内能完成。5.3 一键巡检脚本的骨架把上文提到的检查点汇总成一段可挂进 crontab 的巡检脚本是收尾最实际的内容。#!/bin/bash # CM 日常巡检脚本状态、日志、API 三线检查 CM_HOSTcm-host API_USERadmin API_PASSadmin123 LOG_DIR/var/log/cm_daily_check mkdir -p $LOG_DIR TS$(date %F_%H%M) # 1. 本地进程与端口检查 systemctl is-active cloudera-scm-server /dev/null 21 echo OK $LOG_DIR/server_status_$TS \ || echo DEAD $LOG_DIR/server_status_$TS ss -lntp | grep -q :7180 echo PORT_7180_OPEN $LOG_DIR/server_status_$TS \ || echo PORT_7180_CLOSED $LOG_DIR/server_status_$TS # 2. API 拉取所有服务健康状态 curl -s -u $API_USER:$API_PASS \ http://$CM_HOST:7180/api/v19/clusters/Cluster%201/services \ | python -c import sys,json; djson.load(sys.stdin); [print(s[name], s[healthSummary]) for s in d[items]] \ | tee $LOG_DIR/api_health_$TS.log # 3. 检查 Server 日志最近 5 分钟有无 ERROR grep $(date -d 5 minutes ago %Y-%m-%d %H:%M) /var/log/cloudera-scm-server/cloudera-scm-server.log \ | grep -i error || echo NO_ERROR_IN_SERVER_LOG $LOG_DIR/server_status_$TS脚本逻辑不复杂重点是把巡检从“人肉盯页面”变成“被动收文件”。建议把输出统一丢到日志目录再由统一的日志平台如 ELK 或 Loki采集有条件的团队把 healthSummary 不是 GOOD 的项接入告警。该脚本还可以继续加参数如检查 Agent 心跳、检查元数据库连接数与可用空间每加一项都不要让脚本变长到没法读宁可拆成多个专用脚本挂 cron。运维的思路用一句话提炼Cloudera Manager 既然接管了 Hadoop 集群你也得先接管它自己的运行边界。本文还有配套的精品资源点击获取 Cloudera Manager运维实战：架构、巡检、滚动重启与故障恢复
简介面向大数据集群管理员、运维工程师及BI平台支撑人员这份《大数据集群Cloudera Manager日常运维手册》是一份以实际操作为导向的CM平台维护指南帮助读者快速掌握从登录入口到日常配置变更的完整流程。它覆盖了集群生命周期管理中最高频的操作场景登录Cloudera Manager管理页面启动、停止或重启Cloudera Management Service按批次启停Hadoop所有服务对HDFS、Hive、MapReduce、ZooKeeper等常用组件做单项启停精确控制单个节点上的Datanode、Namenode等角色进程以及修改全局或单节点级别的blocksize等配置参数。每个操作都按“操作前检查—执行—结果确认”展开明确强调先启动Cloudera Management Service再启动Hadoop相关服务、修改参数保存后需部署客户端配置或重启对应服务等注意事项避免因启动顺序或生效流程不当造成服务异常。文档还包含服务状态判断、重启生效确认等排查要点适合正在维护CDH/CDP集群的初中级工程师随手查阅也可作为团队培训速查材料。文档目录层级清晰便于快速定位到目标章节。资源共1个docx文件约1.55MB虽内容精炼但覆盖足够完整。目前已有591人学习下载是久经验证的轻量级运维参考。1. 为什么 Cloudera Manager 的日常运维本质上是在管两套系统接手一套 CDH 集群时很多人会先看 HDFS 容量、YARN 队列、Hive 表数量却忽略一个事实Cloudera Manager 自身也是需要被运维的对象而且它的故障优先级远高于其管理的大数据组件。一个只有几台机器的实验集群上CM Server 进程挂掉的影响常常比 DataNode 掉线更大——因为元数据不可达时你连“谁挂了”都查不到。日常运维 CM 的难度在于它同时管理“CM 自身的生命周期”和“受管组件的生命周期”前者出问题会直接导致后者失去可控性。本文不打算重复官方文档的逐屏点击说明而是按一线运维的实操链路来写从架构认知、进程健康检查到配置变更、滚动升级、备份恢复最后落在几个真实场景的排错和自动化巡检上。熟悉各发行版 Hadoop 手工部署的老手也能在这里找到把 Cluster 与 CM 解耦管理的思路。2. Cloudera Manager 架构与日常巡检最小命令集2.1 Server、Agent、数据库的职责边界Cloudera Manager 的经典架构是 Server-数据库-Agent 三段式。Server 通过 HTTPS 提供管理界面和 API所有配置的持久化落在元数据库通常是内嵌的 PostgreSQL 或外部 MySQL/MariaDBAgent 则以守护进程方式跑在每台受管主机上负责接收命令、上报心跳、启动和停止组件。你可以用以下命令直接确认三者的进程状态# 检查 CM Server 主进程 sudo systemctl status cloudera-scm-server # 检查单个主机上的 Agent sudo systemctl status cloudera-scm-agent # 查看元数据库连接是否正常以 MySQL 5.7 为例 mysql -h cm-host -u scm -p -e select 1; scm这三行命令回答的是三个独立问题Server 本身的 JVM 是否活着、Agent 与 Server 之间的通道是否通、数据库能否响应查询。它们任意一环断了Web 界面都会表现出不同症状。排查时不要一上来就重启整个 Server——先分清是某个 Agent 失联还是 Server 进程整体僵死否则一个误操作会把仍在服务的集群拖下水。2.2 巡检要从日志与指标双通道入手日常巡检不建议只盯着 CM 首页的绿色图标。图标的颜色来自 Server 对 Agent 心跳和组件运行状态的聚合结果心跳默认按 15 秒周期上报。这个值可以调但不是建议你乱调——心跳过快里会造成 Server 端负载偏高过慢则会让故障发现延迟。保持默认的 15 秒即可你更需要的是直接的监控数据# 查看 Agent 与 Server 的上次心跳时间 sudo grep -i heartbeat /var/log/cloudera-scm-agent/cloudera-scm-agent.log | tail -20 # 查看 Server 自身的内存压力 sudo tail -100 /var/log/cloudera-scm-server/cloudera-scm-server.logAgent 日志中与 heartbeat 相关的行如果频繁出现“wait for next heartbeat”或 RPC 超时说明主导的 TCP 连接质量不稳定下一步检查 Server 主机到 Agent 主机的网络延迟与丢包。这里有一个常见的认知偏差Cloudera Manager 管理的组件流量与它本身的控制流量是走同一条物理链路的所以大数据业务跑满带宽时CM 控制通道也可能被拖垮。巡检时不要只看集群组件状态表也要看每个主机的入向出向流量。2.3 用 API 替代页面完成快速摸底CM 提供了完整免登陆的 REST API日常运维用批量脚本比在界面上逐个点击效率高得多。API 的默认端口是 7180HTTP和 7183HTTPS认证方式为 Basic Auth通常使用管理员账号或专用只读账号。# 获取集群内所有主机的健康状态汇总 curl -u admin:admin http://cm-host:7180/api/v19/hosts | python -m json.tool # 获取某个服务的运行状态 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201/services | python -c import sys,json; [print(s[name], s[healthSummary], s[serviceState]) for s in json.load(sys.stdin)[items]]注意 API 路径中的Cluster%201是默认集群名的 URL 编码如果你的集群改名了需要替换成对应名称。这里的用途是批量巡检把多个命令写进一个 shell 脚本定时跑一遍把 healthSummary 不是 GOOD 的服务输出出来。实际使用中API 的 v19 版本覆盖了 CDH 6.x 的核心功能更高版本的 API 多数是对新组件功能的扩展日常巡检不必追新。3. 配置变更与滚动重启的正确操作路径3.1 配置下发到底是改什么Cloudera Manager 的配置管理可以类比成一套“两层模板”系统。第一层是 CM 内置的服务级配置模板第二层是配置组Config Group。每个配置组会有与之对应的一组主机同一服务的不同配置组可以拥有不同的进程参数。最常见的做法是把 Master 节点与 Worker 节点划分到不同配置组给前者分配更大的 JVM 堆内存。如果你要调整 HDFS DataNode 的堆内存常规做法是在 CM 界面进入 HDFS 服务选择“配置”标签页找到Java Heap Size of DataNode修改并保存。改成后用 API 验证参数是否真的到了目标主机# 获取 DataNode 角色所在主机的实际 Java 参数通过服务端 API 触发配置预览 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201/services/hdfs/roleConfigGroups | python -c import sys,json; datajson.load(sys.stdin); [print(c[name], c[configs]) for c in data[items] if DATANODE in c[roleType]]注意保存配置与“让配置生效”是两回事。CM 的“保存”只是修改了数据库里的持久化配置要用户主动执行“重启”或“滚动重启”才会下发到实际进程。如果只保存不重启下次组件自动故障重启时会自动带上新配置反而造成不可预期的行为。3.2 滚动重启的参数与影响面控制重启大数据组件不是简单地把所有角色一起停再一起起。HDFS、YARN、Kafka 这类有状态服务必须采用滚动方式一次只处理一个角色完成后继续下一个。CM 界面里对应的操作是“滚动重启Rolling Restart”命令行方式可以通过 API 触发# 对 HDFS 执行滚动重启staleConfigs 状态下会先通知再逐步重启 curl -u admin:admin -X POST \ http://cm-host:7180/api/v19/clusters/Cluster%201/services/hdfs/commands/restart \ -H Content-Type: application/json \ -d {restartRoleTypes:[DATANODE,NAMENODE],rollingRestart:true}这条命令要留意两点。第一滚动重启的总耗时远高于一次性重启一个 100 个 DataNode 的集群可能要花 40 分钟以上要预留充足窗口。第二NameNode 的滚动重启会让客户端感知到 RPC 闪断Hive/Spark 作业需要重试机制兜底。Yarn NodeManager 的滚动重启用-d指定了slaveGracefulShutdownTimeout参数才有意义——它给正在运行的 Container 一个存活迁移的宽限期。给出的建议是批次大小调小分多轮滚动比一次滚动所有角色更可控。CM 高级配置中Rolling Restart Batch Size默认是 1保持这个值不要改大你失去的只是时间得到的是每次只挂一个节点的确定性。3.3 涉密参数与安全和性能的平衡日常运维少不了手写自定义配置CM 的“高级配置代码段安全阀”机制专门给这类场景用。常见的两个场景在 HDFS 的hdfs-site.xml安全阀里加写入限制或者在 Kafka 的server.properties安全阀里调整num.io.threads。!-- hdfs-site.xml 安全阀片段 -- property namedfs.replication.max/name value2/value description限制文件最大副本数防止个别任务误写过大或异常副本扩散/description /property这类安全阀配置上线前必须先在测试环境验证。它直接写入服务端配置文件语法错误会导致组件启动失败排查难度在于 Web 界面上看到的错误信息常常是“找不到配置项”而不是真正的语法原因。标注清楚响应的后台文件路径能让排错时间缩短一半HDFS 的配置在/etc/hadoop/conf.cloudera.hdfs/hdfs-site.xmlKafka 在/etc/kafka/conf/kafka.properties。改动后第一时间去本地查这两个文件是否与预期一致避免等组件拉起失败后再反向追踪。4. 故障场景排查与关键参数的自我体检4.1 页面打不开、502、502.3 这类入口故障CM 入口故障是日常“看起来最吓人、实际上最好修”的一类。页面打不开的一线排查顺序是先确认 Server 进程活着再确认端口在监听然后才考虑查日志。# 1. 端口监听状态 sudo ss -lntp | grep 7180 # 2. 看 Server 是否抛出了内存错误 sudo grep -i outofmemory\|GC overhead /var/log/cloudera-scm-server/cloudera-scm-server.log # 3. 最近 50 行完整日志重点看 ERROR 与 WARN sudo tail -50 /var/log/cloudera-scm-server/cloudera-scm-server.log如果日志中频繁出现 GC 等待且堆内存占用一直处于高位常见做法是调大 CM Server 自身的 JVM 参数在/etc/cloudera-scm-server/db.properties旁的同目录下找cloudera-scm-server.conf或 systemd drop-in 文件修改-Xmx参数。CM Server 默认堆上限在 2GB 到 4GB 之间管理 100 台以上的集群时建议至少翻倍否则元数据查询与图表渲染都会产生卡顿。不要走“重启一下试试”这条捷径。CM Server 在重启过程中会短暂失去对所有 Agent 的管理通道某些 Agent 的避免心跳重置可能触发重新部署命令进一步加重 Server 启动压力。正确路径是先看日志定位问题再决定是否重启。4.2 大多数 Agent 失联的根因与恢复清单当集群页面上一片黄色、很多主机同时显示“上次心跳时间较早”大概率不是网络故障而是 Server 端资源耗尽或数据库连接被占满。因为单个 Agent 掉线通常是那台机器自身的问题多个主机集体掉线时问题往往出在汇聚端。数据库连接耗尽是比较隐蔽的元凶。CM 的元数据库需要同时支撑 Server 写入、读写 API 与监控数据落盘。排查时直接查数据库连接数# MySQL 中查看连接数及来自 CM Server 的占用 mysql -u scm -p -e show processlist; | grep -c cloudera-scm-server # 确认连接数是否触及 max_connections 上限 mysql -u root -p -e show variables like max_connections;如果连接数打满临时扩大max_connections只能缓解症状真正的解法是把 CM 里的监控数据保留时长缩短进入“管理→监控”界面把每个指标的分辨率保留时间如 15 分钟粒度保留 7 天、1 小时粒度保留 30 天调低。CM 的监控库如果用的是独立的时序存储在 CM 6.3 以后支持用本地 RocksDB其磁盘占用常年在膨胀膨胀到磁盘满时整个 Server 都会停摆。日常运维把监控数据保留策略写进巡检项比事后扩大磁盘来得实际。Agent 失联的另一道检查是看 TLS 证书。CM 的 Agent 与 Server 之间如果启用了 TLS证书过期会导致握手失败症状同样是心跳中止。你可以用openssl直接检查 Server 端证书有效期sudo echo | openssl s_client -connect localhost:7183 2/dev/null | openssl x509 -noout -dates证书日期一旦临近去 CM 的安全设置里重新生成并分发 Agent 端信任链这个流程不复杂但耗时长值得在节点维护窗口提前做。不提前做的后果是某个凌晨证书到期第二天上班你面对一整屏的主机“失去联系”恢复方式只剩手工替换证书后逐个 Agent期间的作业全部受影响。4.3 垃圾回收长暂停导致的“组件假死”CM 监控页面上能看到的组件状态是“健康”但业务反馈 Hive 查询卡住这种情况往往不是组件的单一原因而是 JVM GC 长暂停。CM 的角色页面展示的Last GC指标能帮助你快速定位哪些角色正在经历长 GC。# 从 YARN ResourceManager 日志中查看长时间 GC 的记录 sudo grep -i garbage\|gc /var/log/hadoop-yarn/hadoop-yarn-resourcemanager-*.log | tail -50GC 问题基本落到两个常规修法增大堆内存或者调整年轻代与老年代的比例。对计算型角色NodeManager、RegionServer看到Full GC高频出现时优先考虑是堆分配与实体使用量不匹配调整-XX:MaxNewSize或换用 G1 收集器的参数-XX:UseG1GC比盲目加-Xmx更安全。加-Xmx只是在延长下一次 Full GC 的时间真正的改善来自合理设置堆内缓存与内存分配上限。举 HBase RegionServer 的例子CM 界面中需要同时改hbase.regionserver.global.memstore.size与hfile.block.cache.size两者加起来通常在 0.6 以内超过了会频繁触发全堆 GC。5. Cloudera Manager 元数据备份恢复与一键巡检5.1 备份内容的三个维度维护 Cloudera Manager 集群最重要的习惯不是备份 HDFS 里的业务数据而是备份 CM 自身。CM 的可备份内容分三个维度Server 的配置与集群定义在元数据库里、监控时间序列数据如果是内嵌存储则独立落盘、以及受管主机上的 Agent 配置。第三个维度容易被忽略——当你批量重装 Agent 后如果它的config.ini丢失重新加入集群时大概率要手动指定 Server 地址和身份认证信息。推荐用 CM API 定期把集群与服务配置导出这在版本升级前尤其重要# 导出整个 cluster 的配置快照 curl -u admin:admin http://cm-host:7180/api/v19/clusters/Cluster%201?viewFULL \ /backup/cm/cluster_config_$(date %F).json配合每日自动 dump 元数据库MySQL 的mysqldump或 PostgreSQL 的pg_dump可实现 CM 自身的可重建最小集。需把 CM 的数据库用户权限限定为最小化——这个账号只导自身库即可不需要也不应该接触任何业务库。5.2 恢复演练的价值与所有备份体系一样备份的有效性必须用恢复演练来验证。多数团队的日常只是把 dump 文件丢到磁盘上但没人回答过“这台 CM Server 彻底宕掉后多久能拉起一个可用的管理面”。搭建恢复演练环境时需要有同版本 or 相近版本的 CM/OS 依赖它会改变视图与版本细节影响恢复过程耗时。这里想提醒的不是“版本怎么选”而是“恢复后的配置需要验证三个点”Agent 能否正常注册并显示健康、HDFS 服务能否正常启动与底层数据无关的服务级恢复即算成功、以及配置快照与元数据导出的时间差要在业务可接受范围内。备份周期建议与元数据变更频率强相关如果团队每天都在改队列配置或调参按天导一次库并不夸张。变更好习惯是每次做配置变更前手动手动触发一次快照备份这个动作不需要依赖 IT 运维平台几秒内能完成。5.3 一键巡检脚本的骨架把上文提到的检查点汇总成一段可挂进 crontab 的巡检脚本是收尾最实际的内容。#!/bin/bash # CM 日常巡检脚本状态、日志、API 三线检查 CM_HOSTcm-host API_USERadmin API_PASSadmin123 LOG_DIR/var/log/cm_daily_check mkdir -p $LOG_DIR TS$(date %F_%H%M) # 1. 本地进程与端口检查 systemctl is-active cloudera-scm-server /dev/null 21 echo OK $LOG_DIR/server_status_$TS \ || echo DEAD $LOG_DIR/server_status_$TS ss -lntp | grep -q :7180 echo PORT_7180_OPEN $LOG_DIR/server_status_$TS \ || echo PORT_7180_CLOSED $LOG_DIR/server_status_$TS # 2. API 拉取所有服务健康状态 curl -s -u $API_USER:$API_PASS \ http://$CM_HOST:7180/api/v19/clusters/Cluster%201/services \ | python -c import sys,json; djson.load(sys.stdin); [print(s[name], s[healthSummary]) for s in d[items]] \ | tee $LOG_DIR/api_health_$TS.log # 3. 检查 Server 日志最近 5 分钟有无 ERROR grep $(date -d 5 minutes ago %Y-%m-%d %H:%M) /var/log/cloudera-scm-server/cloudera-scm-server.log \ | grep -i error || echo NO_ERROR_IN_SERVER_LOG $LOG_DIR/server_status_$TS脚本逻辑不复杂重点是把巡检从“人肉盯页面”变成“被动收文件”。建议把输出统一丢到日志目录再由统一的日志平台如 ELK 或 Loki采集有条件的团队把 healthSummary 不是 GOOD 的项接入告警。该脚本还可以继续加参数如检查 Agent 心跳、检查元数据库连接数与可用空间每加一项都不要让脚本变长到没法读宁可拆成多个专用脚本挂 cron。运维的思路用一句话提炼Cloudera Manager 既然接管了 Hadoop 集群你也得先接管它自己的运行边界。本文还有配套的精品资源点击获取