Zookeeper（文中简称ZK）是一个开放源码的分布式应用程序协调服务，是Google公司Chubby服务的开源实现，同时也是Hadoop和Hbase等开源软件的重要组件。文章将从ZK监控案例的角度出发，让大家了解ZK的一些重要监控指标。
服务故障案例
容量问题：
部分follower处于非同步状态后，手工重启异常的follower，结果follower依然无法加入集群。怀疑是集群有问题，因此重启整个集群，重启后集群始终无法进入正常状态，没有leader导致服务瘫痪。事后查看，快照体积达到GB级别，而initLimit默认值仅为20s，follower重启后无法在20s内同步完GB级别的数据，因此被踢出集群。而重启操作又加剧了这一问题，导致集群整体崩溃。最终，通过将故障前leader节点的快照手工同步到所有节点，并调大了zoo.cfg的同步时间相关的参数，服务才恢复。
在这个案例中，快照体积过大是故障的主要原因，我们需要优化initLimit和syncLimit参数、规范业务对ZK的使用方式、避免把ZK当作通用的文件存储系统，同时也需要添加对快照体积（zk_approximate_data_size）的监控，超过1GB就需要报警。类似的问题，如果ZK的节点数过多，也会造成集群性能严重下降，因此也需要添加对ZK集群的节点数（zk_znode_count）的监控，超过10万个节点就需要报警。
资源问题：
ZK集群和Hadoop部署在同一批物理机上，当Hadoop计算任务增加后，将物理机CPU打满，同机部署的ZK集群就无法响应外部请求，进而所有依赖该ZK的Hadoop服务均会崩溃。不仅仅是CPU，ZK还依赖单机的磁盘空间，磁盘的IO能力，网络等。鉴于此，对于ZK集群还是建议独立部署，不要混部。同时，对ZK所在机器的CPU/MEM/NET/IO等进行监控，避免其资源被占用。
还有就是ZK集群的文件句柄数，使用了系统默认的10240，而系统实际的压力远不止于此，因此会出现ZK无法处理部分新的请求，而问题定位的成本和耗时也会增加。发现问题后，通过调整ZK运行账号的文件句柄数限制并重启服务即可解决。