一次悲剧的hdfs故障排查

[cjuexuan]

昨天发生了一次非常严重的hdfs故障，这里总结一下昨天的事故

问题描述

首先在下午1点的时候发现datanode到namenode的心跳时长变长了很多，陆续有任务出现hdfs的cmd超时，所以赶紧紧急的排查了下

初步诊断

当时namenode的heap接近90%，出现了多次full gc，但是因为这一块的告警并没接入，所以导致我们并没有在问题刚发生的时候定位到这一块，我们又看了下当时的主机内存 主机内存在11点以后出现激增，所以应该是11点的操作导致的问题发生

进一步分析

我们count了下hdfs的文件数，发现突然多了几亿的文件，于是我们找了下昨天的11点左右的StateChange，找到了可能发生的文件夹，并且找业务方确认了下可能产生大量文件的操作

最终问题定位

最终发现是有人误操作的情况下按照设备id做partition，由于有几亿个设备，所以导致了悲剧的发生

总结

1. 对于hdfs需要增加heap的实时监控告警这一指标
2. 对于hdfs需要增加文件数量的实时监控告警这一指标
3. 对于用户的操作要进一步审计，避免这种情况再次发生

[cjuexuan]

另外我司招聘大数据运维，感兴趣可以找我私聊一下，我的工作邮箱是todd.chen@ximalaya.com，微信号是ctxylx

[jianweigai]

有个问题，请教下： 对于用户的操作如何审计呢？是代码review吗？ 感觉这个不好控制

[cjuexuan]

@jianweigai 不是，是接入统一的权限

我们其实以前也有做一些，但是没做的很细化，这次事故给我们提了个醒，让我们把一些数据权限的细化做的更彻底了