步步惊心，Zookeeper集群运维“避坑”指南

摘要：京东云一直致力于大集群的稳定性建设，监控系统也经历了多次完善迭代，本文将重点讨论对Zookeeper集群的监控。

整体介绍

基于京东云丰富的实战经验，我们将陆续分享运维方面的干货，帮助小伙伴们进阶为运维达人，欢迎持续关注。首先带来的是“监控”专题系列。

监控专题介绍

监控，可以判断服务的健康程度、定位服务问题、透视系统内部状态，是运维工作中极其重要的一环。该系列内容将分享京东云在服务监控方面的最佳实践。

本期讲解内容的介绍

本期我们重点讲述Zookeeper集群的监控。

Zookeeper（文中简称ZK）是一个开放源码的分布式应用程序协调服务，是Google公司Chubby服务的开源实现，同时也是Hadoop和Hbase等开源软件的重要组件。enjoy：

服务故障案例

• 容量问题：部分follower处于非同步状态后，手工重启异常的follower，结果follower依然无法加入集群。怀疑是集群有问题，因此重启整个集群，重启后集群始终无法进入正常状态，没有leader导致服务瘫痪。事后查看，快照体积达到GB级别，而initLimit默认值仅为20s，follower重启后无法在20s内同步完GB级别的数据，因此被踢出集群。而重启操作又加剧了这一问题，导致集群整体崩溃。最终，通过将故障前leader节点的快照手工同步到所有节点，并调大了cfg的同步时间相关的参数，服务才恢复。在这个案例中，快照体积过大是故障的主要原因，我们需要优化initLimit和syncLimit参数、规范业务对ZK的使用方式、避免把ZK当作通用的文件存储系统，同时也需要添加对快照体积（zk_approximate_data_size）的监控，超过1GB就需要报警。类似的问题，如果ZK的节点数过多，也会造成集群性能严重下降，因此也需要添加对ZK集群的节点数（zk_znode_count）的监控，超过10万个节点就需要报警。
• 资源问题：ZK集群和Hadoop部署在同一批物理机上，当Hadoop计算任务增