简介：Cloudera Manager是大数据集群统一管理平台，这份日常运维手册正是面向集群管理员、运维工程师及Hadoop生态初学者的实操型文档。文档以图文步骤为主线，完整覆盖登录Cloudera Manager、启停Management Service、批量启停Hadoop全部服务、单独操作HDFS/Hive/MapReduce/ZooKeeper等服务、重启某节点上的Datanode等角色，以及修改blocksize等全局与单节点配置参数时的方法和注意事项，并强调先启动Management Service、待所有服务变绿灯才算正常的先后依赖关系。同时，手册还说明了修改参数后如何部署客户端配置、如何根据CM页面提示判断是否需重启服务，以及单个节点角色重启成功的验证操作，便于读者按图索骥。资源包共1个文件，为docx格式文档，大小约1.55MB，内容按故障场景与操作对象分节，可直接对照执行。目前已有591人学习使用，既能作为日常排障的查手册，也可用于团队运维规范的快速培训。
1. 为什么CM运维不能当Linux服务管理来用
接手CDH集群后，第一件事不是学怎么点按钮，而是把Cloudera Manager当成集群唯一的控制平面。同样一个Datanode，直接SSH上去kill进程再拉起，和从CM里点“重启”是两回事：后者会把角色实例从CM的Agent台账里剔除再注册回来，状态视图、健康检查、告警阈值都会跟着刷新；前者只会让CM显示红色心跳超时，后续任何配置推送都可能被Agent拒绝。所以这套日常运维手册的底层逻辑只有一个：凡是CM能管的操作，一律从CM入口做，命令行永远只做补充。
这套手册对应的是一个典型BI集群，CM部署在YUCLIENT这台机器上，浏览器访问7180端口即可进入登录页，默认账号admin/admin，生产环境接好LDAP后第一时间改掉这个默认口令。下面按“管理服务 → Hadoop全服务 → 单服务与单节点角色 → 配置参数修改”这条运维主线逐层展开，整个过程里穿插CM REST API的等价操作，便于故障时绕过界面快速拿状态。
2. Cloudera Management Service：CM自己也是一套分布式服务
从CM首页左上角的“Cloudera Management Service”入口进去，很多人才第一次意识到：CM不只是网页外壳，它自己也是跑在集群上的一个服务集。如果在主机上直接kill掉这些进程，或者节点宕机时CMS没有自动拉起，Hadoop集群本身继续跑，但登录CM后会看到监控断档、告警丢失、角色状态停滞，此时的判断力约等于零。所以操作Hadoop之前先操作CMS，不是界面上的强制顺序，而是要让管理平面先回到可信状态。
2.1 CMS由哪些角色组成
CM自带的管理服务在常见CDH版本里主要由四个角色构成，任何一个处于红色状态，首页健康摘要都会跟着标红。不同小版本的组合略有差异，以你环境里实际看到的角色清单为准，但功能划分基本一致。
| 角色 | 职责 | 故障影响 |
|---|---|---|
| Service Monitor | 收集各服务的健康状态与指标 | 首页健康摘要停更，服务状态不可信 |
| Host Monitor | 收集主机CPU、内存、磁盘、网络指标 | 主机指标断档，容量规划无据可依 |
| Event Server | 接收告警与事件流并落库 | 事件页查不到历史告警，审计缺失 |
| Reports Manager | 生成HDFS与MapReduce历史报表 | 报表页空白，无法回溯资源消耗 |
这些角色由CM Server统一调度，在CM主页的“管理服务”分区能看到各自的启停按钮。启动CMS时，CM会先拉起Event Server，因为监控数据落地需要它；然后拉起Service Monitor和Host Monitor，最后启动Reports Manager。停止顺序相反，Reports Manager先停，避免报表写入被截断。
2.2 为什么Hadoop服务必须等CMS就绪
两个层面的原因。监控数据层面，CMS没有起来时启动Hadoop，CM收不到角色心跳和指标，即使Hadoop进程全起来了，页面上依然显示“停止”，值班人员极容易把这个半启动状态误判为故障，然后重复点启动按钮，导致角色被反复拉起。配置推送层面，CM主页的“重新部署”依赖agent与server之间的会话通道，CMS中的Host Monitor承担了大部分主机级健康判定，它不在线时，配置部署的成功与否无法确认。
所以启动顺序应该是：CMS先启动，等所有角色转为绿色后，再从集群操作里启动Hadoop。停止顺序反过来：先停Hadoop全部服务，再停CMS。这个顺序在CM界面上不会强制拦截，但生产故障大多是违规操作积累出来的。
2.3 用API确认CMS和服务状态而不是只盯界面
界面上的绿灯是抽象结果，排查时需要拿到精确状态字段，这时直接用CM REST API就比页面点来点去更快。先执行第一条命令拿到当前CM的API版本号，后续所有API路径都用这个版本号拼接。
# 获取CM支持的API版本号，返回结果类似 v19 curl -s -u admin:admin "http://cm-host:7180/api/version" # 查询集群下所有服务的运行状态与健康摘要 curl -s -u admin:admin \ "http://cm-host:7180/api/v19/clusters/BI/services" \ | python3 -m json.tool命令里的cm-host替换成CM节点地址，在BI集群里就是YUCLIENT；admin:admin是登录账号与密码；BI是集群名，如果创建时没有改过名，一般是Cluster 1，可以直接在CM主页URL里看到。返回的JSON中，serviceState字段表示CM记录的服务期望状态，取值STARTED或STOPPED；healthSummary表示实际健康状态，取值GOOD、CONCERNING、BAD。服务是否真正可用，不能只看serviceState，要serviceState=STARTED且healthSummary=GOOD同时满足才算数。
3. Hadoop全服务启停、单服务重启与单节点角色控制
3.1 全集群启停的依赖顺序与绿灯判定
CM把“启动所有服务”做成了单按钮，但按钮背后的执行顺序是有讲究的：CM会按服务依赖关系逆序启动，典型序列是ZooKeeper先起，HDFS跟上，然后是YARN和Hive这类上层组件。手动操作也应按这个顺序，反过来先启动Hive，Hive Metastore连不上HDFS，会出现大量重试日志，页面状态在几分钟内反复跳动。
启动完成后，所有服务显示绿灯状态才视为正常。CM的绿色不是简单代表进程存在，而是健康评分汇总值，涵盖角色进程心跳、端口连通性、堆内存使用率、底层告警等多维度数据。页面图标颜色含义如下表：
| 状态 | 含义 | 处理建议 |
|---|---|---|
| 绿色 | 健康，无活跃告警 | 正常 |
| 黄色 | 存在警告，服务可用 | 查看告警列表，评估影响 |
| 红色 | 存在严重故障，服务不可用 | 立即查看角色实例日志 |
| 灰色 | 服务已停止或CM无法联系 | 检查agent心跳与进程状态 |
3.2 以HDFS为例的服务级重启
HDFS是CDH集群的地基，重启它的影响面是最大的。点击HDFS实例页右上角的“重启”按钮后，CM会先做依赖分析，弹窗列出引用HDFS客户端的所有服务，例如Hive、MapReduce、Oozie，并要求你勾选是否联动重启。如果只重启HDFS而不同步重启下游服务，业务侧会持续报连接失败，直到积压的客户端调用超时。
CM执行重启的动作序列是：先停掉勾选的下游服务，再按依赖反转顺序停止HDFS内的角色，通常先停NameNode再停DataNode，启动时顺序反过来。关键坑在于：NameNode冷启动要加载镜像和日志，大型集群可能需要几分钟，这期间HDFS客户端全部不可用。所以我一般会选择业务低峰期操作，或者在CM中改用“滚动重启”——一次只重启一个角色实例，HA NameNode配合ZooKeeper Failover，写服务不中断，代价是总耗时更长。
3.3 单节点Datanode重启与副本补偿机制
单节点角色操作在生产环境里频率最高，扩容、坏盘、调整JVM参数后都免不了。以Datanode为例，进入HDFS实例的角色页面，选择目标节点上的Datanode，点击“重启”，CM会单独停掉该角色再拉起，不触碰其他节点。与直接ssh到机器上重启进程的区别在于：CM会校验该角色实例的配置版本与告警状态，并在页面上确认恢复。
需要牢记的是Datanode重启的时间窗口里，该节点上的block副本数暂时低于目标副本系数，Namenode会在节点重新注册后触发自动复制补副本。这个复制过程会消耗网络带宽和磁盘IO，所以不要同时重启多个节点上的Datanode，也不要在一台物理机上连续重启多个角色。如果节点停用后不再回来，比如硬件故障要下线，正确做法是先进入维护模式或执行Decommission让块迁移，再停进程，否则集群会长期处于under replicated状态。查看角色实例状态的API如下：
# 查看HDFS服务下所有角色实例的部署位置与健康状态 curl -s -u admin:admin \ "http://cm-host:7180/api/v19/clusters/BI/services/hdfs/roles" \ | jq '.roles[] | {name, type, hostRef: .hostRef.hostname, healthSummary}'type字段区分角色类型，常见取值包含NAMENODE、DATANODE、SECONDARYNAMENODE；hostRef.hostname是该角色所在的物理机；healthSummary用于快速过滤出状态异常的角色。排查启动失败时，先看healthSummary为BAD或CONCERNING的实例，顺着主机名登上去查角色日志，不要反复点重启，日志最能说明问题。
4. 配置参数修改、部署客户端配置与联动重启判定
4.1 CM配置的三层作用域
CM里的配置不是平铺的一层，理解作用域是改对参数的前提，否则很容易出现“改了没生效”的假象。整体上分三层：服务级配置作用于整个服务的所有角色，例如HDFS服务级配置会下发到所有NameNode和DataNode；角色组配置针对某类角色的一组节点，例如单独调整NameNode的堆内存，要改的是NameNode角色组的Java Heap Size参数；角色实例配置则只作用于单个节点上的具体角色，优先级最高。
| 配置层 | 作用范围 | 修改入口 |
|---|---|---|
| 服务级 | 整个服务的所有角色实例 | 服务实例页 -> 配置 |
| 角色组 | 同一类角色的一组节点 | 角色组标签页 -> 配置 |
| 角色实例 | 单个节点上的具体角色 | 角色实例页 -> 配置 |
日常修改中，全局适用参数走服务级，计算节点差异化参数走角色组，临时调试参数才改角色实例。改完后CM主页出现“部署客户端配置”和“重启服务”两个提示，很多人只点重启而忽略部署客户端配置，这个习惯要改过来。
4.2 修改HDFS的blocksize完整流程
以修改HDFS的blocksize为例：进入HDFS实例页 -> 配置 -> 搜索block-> 找到dfs.blocksize，默认值是134217728字节，即128MB，改成目标值保存即可。保存成功后CM主页会提示需要部署客户端配置，同时HDFS、Hive、MapReduce三个服务都提示需要重启，这一现象在4.4节展开解释。
blocksize的选择直接影响NameNode内存和MapReduce任务粒度。块越小，相同数据量下block条目越多，NameNode堆内存压力越大；块越大，单个Map处理的数据量越大，可能拖慢作业进度。生产环境我会结合文件平均大小和Map任务并行度来定：海量小文件集群保持128MB不折腾，批处理大文件集群调到256MB，不要拍脑袋。
4.3 用API完成配置修改与客户端配置部署
界面操作适合交互式修改，要做变更审计或批量调整时，走API更稳妥。先查当前值，再PUT修改，最后触发部署客户端配置。
# 查询HDFS当前配置中dfs.blocksize的值 curl -s -u admin:admin \ "http://cm-host:7180/api/v19/clusters/BI/services/hdfs/config" \ | jq '.config[] | select(.name == "dfs.blocksize")' # 将dfs.blocksize修改为268435456字节（256MB） curl -s -X PUT -u admin:admin \ -H "Content-Type: application/json" \ -d '{"items":[{"name":"dfs.blocksize","value":"268435456"}]}' \ "http://cm-host:7180/api/v19/clusters/BI/services/hdfs/config"PUT请求里的items数组可以放多个name/value对，一次完成批量修改。不同CM版本对PUT的语义有差异，部分版本是局部更新，个别版本是全量覆盖；保险做法是先GET全量配置存一份文件，再改掉目标字段后整体PUT，避免把其他参数冲掉。修改完成后执行部署客户端配置命令：
# 触发deployClientConfig，将最新配置推送到所有节点 curl -s -X POST -u admin:admin \ "http://cm-host:7180/api/v19/clusters/BI/services/hdfs/commands/deployClientConfig"这条命令做的事是把CM内存中的配置渲染成XML，推送到各主机的/etc/hadoop/conf目录，替换core-site.xml、hdfs-site.xml等文件。它不会重启任何进程，新配置要等进程重新启动或热加载才真正生效。每次改完配置，无论界面是否提示重启，我都建议先执行这一步，否则远程提交作业的客户端机器可能还挂着旧参数。
4.4 为什么改blocksize会带动Hive和MapReduce一起重启
CM能在配置保存后自动分析出需要重启的服务边界，靠的是组件依赖图和参数引用关系。dfs.blocksize被HDFS客户端在创建文件时读取，也影响MapReduce输入分片的生成逻辑，Hive则通过HDFS客户端读写数据，因此CM判定这三个服务的角色进程都需要重新加载配置。判断逻辑的参考维度包括：配置项是否被进程启动参数引用、是否在JVM启动时缓存、是否有运行时刷新机制。
下表是结合我维护集群经验总结的配置修改后提示类型，最终以你环境里CM界面实际提示为准：
| 修改后的提示 | 典型场景 | 处理方式 |
|---|---|---|
| 无需重启 | 日志级别、监控告警阈值 | 保存后立即生效 |
| 仅重启单个服务 | HDFS数据目录变更、JVM堆参数 | 重启对应服务实例 |
| 联动重启多个服务 | dfs.blocksize、HDFS客户端配置 | 选择低峰期按提示联动重启 |
需要注意，CM的提示逻辑未必覆盖所有边界，例如某些通过hadoop conf命令手动下发的参数，CM并不知情。所以修改配置后，我会顺手在任意一个DataNode上执行一次配置校验：
# 在DataNode节点上确认推下来的hdfs-site.xml内容 grep -n "dfs.blocksize" /etc/hadoop/conf/hdfs-site.xml如果节点上的配置文件还是旧值，说明agent没有把新配置拉到本机，此时排查cloudera-scm-agent日志，而不是急着重启服务。
5. 用CM API做状态巡检与配置基线回滚
5.1 全集群健康巡检脚本
日常巡检不需要登录页面肉眼扫一遍，写一个基于API的巡检脚本，输出所有不健康的服务，挂到crontab里每天跑一次，比人工盯着可靠得多。脚本逻辑是：先动态获取API版本，避免版本号写死，再遍历服务列表，过滤出healthSummary不为GOOD的项。
#!/bin/bash # 每天巡检全集群服务健康状态，输出异常项 CM_HOST=cm-host API_VERSION=$(curl -s -u admin:admin "http://${CM_HOST}:7180/api/version" | awk '{print $NF}') curl -s -u admin:admin \ "http://${CM_HOST}:7180/api/${API_VERSION}/clusters/BI/services" \ | jq -r '.items[] | select(.healthSummary != "GOOD") | "\(.type) 状态=\(.serviceState) 健康=\(.healthSummary)"'脚本中的CM_HOST换成YUCLIENT地址；awk '{print $NF}'取版本号最后一段，因为返回的v19前面可能带提示信息；select(.healthSummary != "GOOD")只保留异常服务。没有输出就是好消息，有输出再登到CM上看告警详情。
5.2 配置基线导出与回滚
修改配置之前先导出一份全集群配置基线，这个动作成本极低，收益极高。CM提供了export接口，一条命令就能把集群所有服务的配置快照拉下来。
# 导出集群完整配置作为可审计基线 curl -s -u admin:admin \ "http://cm-host:7180/api/v19/clusters/BI/export" > cm-config-baseline.json改配置后如果集群表现异常，先用diff对比变更前后差异，定位到具体参数后改回去，再走“部署客户端配置 + 重启服务”的标准动作。把基线文件提交到git仓库，每次变更前更新一份，比在UI里肉眼对比靠谱得多。
5.3 角色启动失败的日志定位技巧
角色启动失败时，界面上给出的信息是摘要级别的，完整的异常都落在节点本地。先看agent日志，再看角色日志，顺序不要反。agent日志记录与CM server的通信状态，角色日志记录进程本身的启动异常。
# 查看agent级通信日志，过滤错误关键字 grep -i "error\|exception" /var/log/cloudera-scm-agent/cloudera-scm-agent.log | tail -50结合CM的事件页和这份agent日志，基本能定位九成角色启动问题。对照关系是：事件页告诉你“什么时候发生了什么”，agent日志告诉你“agent是否收到了指令、执行时卡在哪一步”，角色日志告诉你“进程为何没有起来”。三条线索在时间轴上对齐，故障原因通常就浮出来了。
本文还有配套的精品资源，点击获取
