集群管理：包括集群监控（侧重对运行时状态的手机）和集群控制（对集群进行操作与控制）
ZooKeeper具有两大特性，可以实现集群机器活性监控的系统。
- 客户端如果对ZooKeeper的一个数据节点注册Watcher监听，那么当该数据节点内容或者是其子节点发生变更的时候，ZooKeeper服务器就会向订阅的客户端发送变更通知。
- 对在ZooKeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点也就被自动删除
举个例子：监控系统在/clusterServers节点上注册一个Watcher监听，那么一旦进行动态添加的机器操作，就会在/clusterServers节点下创建一个临时节点：/clusterServers/[host-name]。这样一来，监控系统久能够检测到机器的变动情况，至于后续处理就是监控系统的业务了。
分布式日志收集系统
分布式日志收集系统的核心就是收集分布在不同机器上的系统日志。在一个典型的日志系统的架构设计中，整个日志系统会把所有需要收集的日志机器（称为“日志源机器”）分为多个组别，每个收集器其实就是一个后台机器（称为“收集器机器”），用于收集日志。对于大规模的分布式日志收集系统，需要解决如下两个问题：
变化的日志源机器
机器的硬件问题、扩容、机房迁移或者是网络问题都会导致一个应用的机器变化，也就是说每个组别中的日志源机器通常是不断在变化的变化的收集器机器
新的收集器加入或者是老的收集器退出的情况。
注册收集器机器
使用ZooKeeper来进行日志系统的注册，典型做法是在ZooKeeper上创建一个节点作为收集器的根节点，例如/logs/collector，每个收集器机器在启动的时候，都会在该收集器根节点下创建自己的节点，例如/logs/coolector/[host-name]
任务分发
进程根据收集器根节点下的子节点个数，将所有的日志源机器分成对应的若干组，然后将分组后的机器列表分别写到这些收集器机器（例如/logs/collector/host-1）的节点上。这样一来，每个收集器机器都能够从自己对应的收集器根节点上获取日志源机器列表，进而开始日志收集工作。
状态汇报
考虑到收集器机器有可能会挂掉的情况，需要一个收集器的状态汇报机制：每个收集器在创建完自己的专属节点后，还需要在对应的子节点上创建一个状态子节点，例如“/logs/collector/host-1/status”，每个收集器机器都需要定期向该节点写入自己的状态信息，也可以把该策略看成是一种心跳机制，状态信息通常包括日志收集进度信息。
动态分配
如果收集器机器挂掉，或者加入新机器，就需要动态地进行收集任务的分配。日志系统始终关注着/logs/collector这个节点下所有子节点的变更，一旦检测到变更，需要将之前分配给该收集器的所有任务进行转移。
全局动态分配
这是一种简单粗暴的做法，在出现收集器机器挂掉或是新机器加入的时候，日志系统需要根据新的收集器机器列表，立即对所有的日志源机器重新进行一次分组，然后将其分配给剩下的收集器机器。
弊端：一个或部分收集器机器的变更，就会导致全局动态任务的分配，影响面比较大，因此风险也就比较大。局部动态分配
所谓的局部动态分配，就是在小范围内进行任务的动态分配。每个收集器机器在汇报自己日志收集状态的同时，也会把自己的负载汇报上去。如果一个收集器机器挂了，那么日志系统会将其任务分配给负载较低的机器；同样，新加入的机器会分担负载较高的机器的任务。
注意事项
节点类型
/logs/collector这个节点下面的子节点代表了每个收集器机器，并将其创建为临时节点，原因是：日志系统可以根据这些临时节点来判断收集器机器的存活性。但是在分布式日志系统中，一旦收集器机器挂掉，会话在一段时间之后失效，该节点的日志源机器列表及其数据也会随之被删除。
由此可见，临时节点并不能满足业务的需求，所以选择永久节点来标识每一个收集器机器，同时在这个持久节点下面分别创建/logs/collector/[hostname]/status节点来表征每一个收集器机器的状态。一旦收集器机器挂掉之后，依然能够准确地将分配于其中的任务还原。日志系统节点监听
在实际生产中，每一个收集器机器更改自己状态节点的频率可能非常高（如每秒１次或者更短），而且收集器数量可能非常大。如果让日志系统监听所有的收集器机器，那么系统会接受大量的消息；另一方面，大部分的状态变更通知都是无关紧要的。
所有，使用日志系统主动轮询所有的收集器机器的策略，虽然有一定的延时，但是可能节省不少的网络流量。