共计 3429 个字符，预计需要花费 9 分钟才能阅读完成。
本篇文章给大家分享的是有关 Zookeeper 集群运维避坑指南是怎么样的，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。
首先带来的是“监控”专题系列。
监控，可以判断服务的健康程度、定位服务问题、透视系统内部状态，是运维工作中极其重要的一环。该系列内容将分享京东云在服务监控方面的最佳实践。
本期我们重点讲述 Zookeeper 集群监控
Zookeeper（文中简称 ZK）是一个开放源码的分布式应用程序协调服务，是 Google 公司 Chubby 服务的开源实现，同时也是 Hadoop 和 Hbase 等开源软件的重要组件。文章将从 ZK 监控案例的角度出发，让大家了解 ZK 的一些重要监控指标。enjoy：
服务故障案例
容量问题：
部分 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 集群，造成 ZK 集群无法处理如此海量请求，集群直接崩溃。该客户端也不得不全部回滚。虽然，这个 ZK 集群当时设置 leader 不接收请求，且对单个 IP 最高并发请求数也进行了限制，但这依然无法改变集群面对海量请求直接崩溃的结果。
在这个案例中，如果及早添加了流量相关的监控，如 ZK 节点连接数（zk_num_alive_connections）以及 ZK 节点流量（zk_packets_received/zk_packert_sent），可以提前感知到集群流量突增的问题。
服务异常：
follower 故障未及时处理，导致单个集群故障的 follower 数量超过了集群可以容忍的最大值，集群彻底崩溃。这时候需要立即修复故障的 follower。结果发现之前的 follower 因为硬件故障等原因短时间内无法恢复，而业务方大多是直连 IP，因此也无法快速修改。此时集群压力还比较大，即使强行转为单机模式，也需要进行限流。无论如何处理，都会导致服务受损较长时间。
在这个案例中，如果及早添加了 follower 相关的监控，如 zk_followers /zk_synced_followers 以及 zk_server_state，并能保证报警发生后立即处理并恢复服务，则不会出现这种惨剧。
容量问题：
ZK 集群的文件句柄数，使用了系统默认的 10240，而系统实际的压力远不止于此，因此会出现 ZK 无法处理部分新的请求，而问题定位的成本和耗时也会增加。发现问题后，通过调整 ZK 运行账号的文件句柄数限制并重启服务即可解决。
在这个案例中，如果及早添加了 zk_open_file_descriptor_count/zk_max_file_descriptor_count，则能够避免该问题。同时，很多开源软件都会遇到文件句柄数的问题，且多次引发各类系统的重大故障，所以还是要谨慎对待。
隔离问题：
ZK 集群提供了全地域的协调服务，当 ZK 集群出现故障后，导致服务在全国所有地域不可用。这时候，应该对 ZK 集群进行拆分，每个地域均部署一套独立的集群，将故障范围控制在单一地域。在这个案例中，监控并非主要的问题和解决方案，而讲述该案例的目的，主要是让大家对 ZK 集群故障有一个更加全面的认识。
运维仪表盘
采集项筛选
上面通过和大家分享一些 ZK 故障，让大家了解了一些核心指标的重要性。接下来，我们按照 Google SRE 的监控理论，将 ZK 监控进行系统性的梳理和总结：
黑盒监控
集群功能
创建 / 删除 / 读取节点
说明：在 /zookeeper_monitor 节点下，定期创建 / 删除节点，确保该功能可用
建议：创建 /zookeeper_monitor 节点，不要使用业务节点，避免互相影响
经验值：模拟用户请求的节点至少 3 个，从而确保覆盖 ZK 所有节点
读取 / 更新内容
说明：在 /zookeeper_monitor 节点下，定期对内容读取和更新
建议：可以将时间戳写入，从而便于判断写入延时
白盒监控
采集方式
方式 1：zookeeper 四字命令 mntr
方式 2：JMX 接口
错误
zk_server_state
说明：集群中有且只能有一个 leader，没有 leader，则集群无法正常工作；两个或以上的 leader，则视为脑裂，会导致数据不一致问题
重要性：高
zk_followers /zk_synced_followers
说明：如果上述两个值不相等，就表示部分 follower 异常了需要立即处理，很多低级事故，都是因为单个集群故障了太多的 follower 未及时处理导致
重要性：高
zk_outstanding_requests
说明：常态下该值应该持续为 0，不应该有未处理请求
重要性：高
zk_pending_syncs
说明：常态下该值应该持续为 0，不应该有未同步的数据
重要性：高
容量
zk_znode_count
说明：节点数越多，集群的压力越大，性能会随之急剧下降
重要性：高
经验值：不要超过 100 万
建议：当节点数过多时，需要考虑以机房 / 地域 / 业务等维度进行拆分
zk_approximate_data_size
说明：当快照体积过大时，ZK 的节点重启后，会因为在 initLimit 的时间内同步不完整个快照而无法加入集群
重要性：高
经验值：不要超过 1GB 体积
建议：不要把 ZK 当做文件存储系统来使用
zk_open_file_descriptor_count/zk_max_file_descriptor_count
说明：当上述两个值相等时，集群无法接收并处理新的请求
重要性：高
建议：修改 /etc/security/limits.conf，将线上账号的文件句柄数调整到 100 万
zk_watch_count
说明：对于 watch 的数量较多，那么变更后 ZK 的通知压力也会较大
重要性：中
流量
zk_packets_received/zk_packert_sent
说明：ZK 节点接收 / 发送的 packet 的数量，每个节点的具体值均不同，通过求和的方式来获取集群的整体值
建议：通过两次命令执行间隔 1s 来获取差值
重要性：中
zk_num_alive_connections
说明：ZK 节点的客户端连接数量，每个节点的具体值均不同，通过求和的方式来获取集群的整体值
建议：通过两次命令执行间隔 1s 来获取差值
重要性：中
延时
zk_avg_latency/zk_max_latency/zk_min_latency
说明：需要关注平均延时的剧烈变化，业务上对延时有明确要求的，则可以针对具体阈值进行设置
其他监控
进程监控（JVM 监控）
端口监控
日志监控
主机监控
TIPS
Zookeeper 四字命令
mntr
stat
以上就是 Zookeeper 集群运维避坑指南是怎么样的，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。
