zookeeper运维

网络

不能在一台物理机器、一个机柜或一个交换机挂掉后影响整个集群，所以节点的网络结构也要考虑。

分Group，保护核心Group

要确保zookeeper整个集群可靠运行，就是要确保投票集群可靠。那在我们这里，将一个zookeeper集群划分为多个小的Group，我们称Leader+Follower为核心Group，核心Group我们一般是不向外提供服务的，然后我们会根据不同的业务再加一些Observer，比如一个Zookeeper集群为服务发现、消息、定时任务三个不同的组件提供服务，那么我们为建立三个Observer Group，分别给这三个组件使用，而client只会连接分配给它的Observer Group，不去连接核心Group。这样核心Group就不会给Client提供长连接服务，也不负责长连接的忙啥，这大大的减轻了核心Group的压力，因为在实际环境中，一个Zookeeper集群要为上万台机器提供服务，维持长连接和心跳还要消耗一定的资源 。因为Obsrever是不参与投票的，所以Observer并不会降低整体的吞吐量，而且observer挂掉也不会影响整个集群的健康。

但是这里要注意的是，分Observer Group只能解决部分问题，因为毕竟所有写入还要交给核心Group来处理的，所以对于写入量特别大的应用来说，还是需要进行集群上的隔离。

内存

因为Zookeeper将所有数据都放在内存里，所以对JVM以及机器的内存也要预先计划，如果出现Swap那将严重的影响Zookeeper集群的性通信，所以一般不怎么推荐将Zookeeper用作通用的配置管理服务，因为一般配置数据还是挺大的。

日志清理

因为Zookeeper要频繁的写txlog以及定期dump内存snapshot到磁盘，这样磁盘占用就越来越大，所以Zookeeper提供了清理这些文件的机制，但是这种机器并不太合理，它只能设置 间隔多久清理，而不能设置具体的时间段，那么就有可能碰到高峰期间清理，所以建议关闭autopurge.purgeInterval=0，然后使用crontab等机制，在业务低谷的地候清理。

日志、JVM配置

从官网直接下载的包如果直接启动运行是很糟糕的，这个包默认的配置日志是不会轮转的，而且是直接输出到终端。除此之外，这个默认设置还没有设置任何jvm相关的参数，这是不可取的。不要直接修改Zookeeper自带的脚本 ，Zookeeper会加载conf文件夹下一个名为zookeeper-env.sh的脚本，可以将一些定制的配置写在这里。

　#!/usr/bin/env bash　　JAVA_HOME= #java home　　ZOO_LOG_DIR= #日志文件放置的路径　　ZOO_LOG4J_PROP="INFO,ROLLINGFILE" #设置日志轮转　　JVMFLAGS="jvm的一些设置，比如堆大小，开gc log等"

监控

1.影响Zookeeper工作的主要因素

（1）用于zookeeper写事务日志的目录要有足够大小，并且强烈建议在单独的磁盘上，这是影响zk性最大因素之一。

（2）连接数。

（3）注册的watcher数。

（4）znode是否可读、可写。

（5）zk事件通知的延时是否过大。

可以使用阿里开源的TaoKeeper监控框架。

TaoKeeper

（1）CPU、MEM、LOAD的监控

（2）ZK日志目录所在磁盘剩余空间监控。

（3）单机连接数的峰值报警。

（4）单机Watcher数的峰值报警。

（5）节点自检：对集群中每个IP所在zk节点上的path:/YINSHI.MONITOR.ALIVE.CHECK定期进行三次如下流程：节点连接-》数据发布0》修改通知-》获取数据-》数据对比，在指定的延时内，三次流程均成功视为该节点处于正常状态。

工作原理

Taokeeper通过SSH连接到Zookeeper部署的机器上，再在上面执行zookeeper的四字命令来得到统计信息，再分析保存到mysql数据库中。

注意：

监控的每台机器需要安装nc命令。

Zookeeper告警

（1）Zookeeper宕机告警。

（2）单机连接数超过阀值告警。

（3）单机watch数据超过阀值告警。

（4）磁盘，cpu、内存超过阀值告警。