2026/9/19 12:28:27
FEATURED · 精选文章 
简介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 ServiceCM自己也是一套分布式服务从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没有起来时启动HadoopCM收不到角色心跳和指标即使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集群里就是YUCLIENTadmin:admin是登录账号与密码BI是集群名如果创建时没有改过名一般是Cluster 1可以直接在CM主页URL里看到。返回的JSON中serviceState字段表示CM记录的服务期望状态取值STARTED或STOPPEDhealthSummary表示实际健康状态取值GOOD、CONCERNING、BAD。服务是否真正可用不能只看serviceState要serviceStateSTARTED且healthSummaryGOOD同时满足才算数。3. Hadoop全服务启停、单服务重启与单节点角色控制3.1 全集群启停的依赖顺序与绿灯判定CM把“启动所有服务”做成了单按钮但按钮背后的执行顺序是有讲究的CM会按服务依赖关系逆序启动典型序列是ZooKeeper先起HDFS跟上然后是YARN和Hive这类上层组件。手动操作也应按这个顺序反过来先启动HiveHive 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、SECONDARYNAMENODEhostRef.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/configPUT请求里的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_HOSTcm-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是否收到了指令、执行时卡在哪一步”角色日志告诉你“进程为何没有起来”。三条线索在时间轴上对齐故障原因通常就浮出来了。本文还有配套的精品资源点击获取
Cloudera Manager运维实战：从CMS到Hadoop服务管理的关键操作与API实践
简介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 ServiceCM自己也是一套分布式服务从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没有起来时启动HadoopCM收不到角色心跳和指标即使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集群里就是YUCLIENTadmin:admin是登录账号与密码BI是集群名如果创建时没有改过名一般是Cluster 1可以直接在CM主页URL里看到。返回的JSON中serviceState字段表示CM记录的服务期望状态取值STARTED或STOPPEDhealthSummary表示实际健康状态取值GOOD、CONCERNING、BAD。服务是否真正可用不能只看serviceState要serviceStateSTARTED且healthSummaryGOOD同时满足才算数。3. Hadoop全服务启停、单服务重启与单节点角色控制3.1 全集群启停的依赖顺序与绿灯判定CM把“启动所有服务”做成了单按钮但按钮背后的执行顺序是有讲究的CM会按服务依赖关系逆序启动典型序列是ZooKeeper先起HDFS跟上然后是YARN和Hive这类上层组件。手动操作也应按这个顺序反过来先启动HiveHive 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、SECONDARYNAMENODEhostRef.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/configPUT请求里的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_HOSTcm-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是否收到了指令、执行时卡在哪一步”角色日志告诉你“进程为何没有起来”。三条线索在时间轴上对齐故障原因通常就浮出来了。本文还有配套的精品资源点击获取 
