目录
一、为什么你的 CDH 总是装不好
二、6 类高频故障排查表
三、通用定位三步法
四、三大易错细节（占故障大半）
五、全系列回顾与索引
六、结语
一、为什么你的 CDH 总是装不好
复盘大量部署案例后会发现：CDH 故障极少是"玄学"，几乎全部源于环境准备遗漏、介质细节出错、资源不足这三类人为因素。也就是说，绝大多数故障可以靠一张表 + 一个方法论定位。
二、6 类高频故障排查表
问题现象可能原因解决方法
17180 无法访问Server 未启动完成（首次要 2~3 分钟）、防火墙未关、驱动缺失等待重试；查防火墙；看 Server 日志；确认 JDBC 驱动在位
2环境检查报"交换分区未关"只用 sysctl -w 临时关闭，重启复原/etc/sysctl.conf 写入 vm.swappiness=0 后 sysctl -p
3节点在控制台失联Agent 未启动、config.ini 的 server_host 配错从节点查 Agent 状态；核对 server_host=master IP
4Parcel 分发/激活失败.sha1 未改名 .sha、网络不通、目录属主不对改名；测连通性；chown cloudera-scm:cloudera-scm /opt/cloudera
5Kafka 服务启动失败内存不足、ZooKeeper 未装或挂了Broker 堆改 256M；先确保 ZooKeeper 健康
6数据库连接测试失败cdh 账号缺 ‘%’ 授权、JDBC 驱动未放对位置补 grant 授权；驱动放 /opt/cm/share/cmf/lib/ 和 /usr/share/java/ 两处
三、通用定位三步法
遇到表里没有的新故障，按这个顺序走：
3.1 先看报错原文
CM Web 界面的报错横幅、服务实例的日志按钮，永远是第一现场。不要凭记忆猜问题，先读完报错全文。
3.2 Server 日志优先
bash
tail -200f /opt/cm/log/cloudera-scm-server/cloudera-scm-server.log
CM 的绝大多数初始化失败、数据库连接失败、CSD 解析失败都会在这里留痕。Agent 侧日志在 /opt/cm/log/cloudera-scm-agent/。
3.3 端口与进程验证
bash
Server 是否活着
netstat -anpt | grep 7180
Agent 是否活着
ps -ef | grep cloudera-scm-agent
Java 进程全景（能看到 NameNode/DataNode/Kafka 等角色进程）
jps
三步走完，故障基本能收敛到"哪个组件、哪类原因"。
四、三大易错细节（占故障大半）
细节一：Parcel 校验文件 .sha1 必须重命名为 .sha。CM 只认 .sha，不改名就永远"分发中"。Kafka Parcel 同理。
细节二：永久配置必须落盘。swap、透明大页这类内核参数，临时命令一执行检查就过，重启即失效，故障隔天复现。写 sysctl.conf 和 rc.local 才算完。
细节三：JDBC 驱动要放两个位置。只放 CM 目录，Hive 测试连接失败；只放 /usr/share/java，CM 自己连不上库。
五、全系列回顾与索引
篇主题一句话要点
一CDH 基础概念CM/Parcel/CSD/Server-Agent 四概念
二集群规划与介质master 内存 6G 起步，介质 7 份
三环境准备 7 步NTP、免密、内核参数永久生效
四MySQL 元数据库临时密码保存，cdh 授权 ‘%’
五CM 离线安装.sha1 改 .sha，server_host 指 master
六Web 向导装集群7 屏走完，环境检查必须全绿
七Kafka 集成先 ZooKeeper 后 Kafka，堆 256M
八排错手册（本篇）一表三步法三细节
六、结语
回顾整个系列，CDH 部署的难度不在单个命令，而在跨节点的操作纪律：哪一步在哪个节点做、哪些配置要永久落盘、哪些文件要改名换位置。把纪律固化为清单，部署就从"玄学"变成"流水线"。
如果你的集群已经全绿跑起来了，下一步可以试着接入真实的物联网数据：设备消息进 Kafka，Flink/Spark 消费计算，结果落 HDFS/Hive——这套平台足以支撑大多数中等规模的数据场景。部署中遇到其他奇葩问题，欢迎评论区交流，我看到会回复。
