企业官网建设流程全解析

简介：面向大数据集群管理员、运维工程师及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/MariaDB），Agent 则以守护进程方式跑在每台受管主机上，负责接收命令、上报心跳、启动和停止组件。

你可以用以下命令直接确认三者的进程状态：

# 检查 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.log

Agent 日志中与 heartbeat 相关的行如果频繁出现“wait for next heartbeat”或 RPC 超时，说明主导的 TCP 连接质量不稳定，下一步检查 Server 主机到 Agent 主机的网络延迟与丢包。这里有一个常见的认知偏差：Cloudera Manager 管理的组件流量与它本身的控制流量是走同一条物理链路的，所以大数据业务跑满带宽时，CM 控制通道也可能被拖垮。巡检时不要只看集群组件状态表，也要看每个主机的入向出向流量。

2.3 用 API 替代页面完成快速摸底

CM 提供了完整免登陆的 REST API，日常运维用批量脚本比在界面上逐个点击效率高得多。API 的默认端口是 7180（HTTP）和 7183（HTTPS），认证方式为 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; data=json.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> <name>dfs.replication.max</name> <value>2</value> <description>限制文件最大副本数，防止个别任务误写过大或异常副本扩散</description> </property>

这类安全阀配置上线前必须先在测试环境验证。它直接写入服务端配置文件，语法错误会导致组件启动失败；排查难度在于 Web 界面上看到的错误信息常常是“找不到配置项”，而不是真正的语法原因。标注清楚响应的后台文件路径，能让排错时间缩短一半：HDFS 的配置在/etc/hadoop/conf.cloudera.hdfs/hdfs-site.xml，Kafka 在/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 -50

GC 问题基本落到两个常规修法：增大堆内存，或者调整年轻代与老年代的比例。对计算型角色（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?view=FULL" \ > /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_HOST="cm-host" API_USER="admin" API_PASS="admin123" 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 2>&1 && 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; d=json.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 集群，你也得先接管它自己的运行边界。

本文还有配套的精品资源，点击获取