①背景
昨晚UAT环境应用故障，定位到问题是CDH某个节点磁盘空间满了。巧的是这个节点上同时装了mysql和SCM，/var总空间10G，SCM的cloudera-scm-eventserver文件夹占用了8个多G，经过大家一起讨论，方案有下面几个：
1、给cloudera-scm-eventserver建软链
目前在投产前冲刺阶段，有CDH崩溃的风险，不敢尝试，简单讨论后被毙掉了这个方案。规划先在自己本机实验，成功后，等最近一次投产后，再用这种方法处理。
2、停掉CDH,清理日志文件，腾挪出来部分空间。
可以删除的日志文件比较少，预估坚持不了多长时间，不能从根本上解决问题。
3、向甲方申请挂一块10G的盘，然后将空间合并到/var上
可以从根本上解决这个问题，需要走流程，等待。另外涉及底层磁盘挂载，也存在数据丢失的风险，毕竟不是专业运维，不敢搞啊。
最终的结论是，大家都懂得，优先保障应用使用，先把CDH清理了部分日志缓存文件，先把应用启动了支撑过最近一次重要投产。
①问题解决过程1
早上好奇想了解下这个cloudera-scm-eventserver到底是干啥的？浏览过程中发现一个帖子和我昨晚遇到的问题高度相似：
CDH系统中cloudera-scm-eventserver目录占用磁盘空间大，修改配置即可解决_经验充电_废柴博客 (fcblog.cn)
小伙伴参考上面链接，使用该方法：
1、进入CMS的配置界面，
2、使用关键字搜索到事件日志记录的路径和保存事件条目最大值
路径保存不变，将最大事件数改小，然后进行保存。
3、保存完成后，按照提示重启管理服务即可生效，重启后管理服务会按照最新配置的最大事件数对路径中保存的历史事件进行清理，这样磁盘空间就清理出来了。
重启过程中报错了。emo了 ~~~
②问题解决过程2
经过简单分析报错信息和日志，定位到还是该节点磁盘空间满导致的SCM停止不了。
1、清理/var下面可以清理的文件
查看/var 目录下最大的10个文件或目录
du -h var | sort -hr | head -n 10
发现SCM相关的日志转存文件可以删除，清理掉了大概100M左右的文件。
2、再次尝试重启SCM
good job ！very done！重启成功，此刻内心开心到飞起。
3、启动CDH其他服务
也正常启动成功。
4、查看磁盘空间情况
非常棒！/var使用率已降到了很低，已经不影响正常使用。打完收工！
