步步惊心，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计算任务增加后，将物理机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监控）
端口监控
日志监控
主机监控

ZK监控

功能监控：https://github.com/cloud-op/monitor/tree/master/zookeeper

Zookeeper四字命令

mntr

stat
crst、dump、envi、ruok、srst、srvr、cons、wchs、wchc、wchp、conf

步步惊心，Zookeeper集群运维“避坑”指南相关推荐

etcd 集群运维实践
[编者的话]etcd 是 Kubernetes 集群的数据核心,最严重的情况是,当 etcd 出问题彻底无法恢复的时候,解决问题的办法可能只有重新搭建一个环境.因此围绕 etcd 相关的运维知识就比较 ...
Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级)
推荐一款非常好用的kafka管理平台,kafka的灵魂伴侣滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台技术交流有想进滴滴LogI开源用户群的加我个人微信: jjdl ...
阿里巴巴大规模神龙裸金属 Kubernetes 集群运维实践
戳蓝字"CSDN云计算"关注我们哦! 导读:值得阿里巴巴技术人骄傲的是 2019 年阿里巴巴双11 核心系统 100% 以云原生的方式上云,完美支撑了 54.4w 峰值流量以及 ...
管理大规模容器集群能力包括_阿里巴巴大规模神龙裸金属 Kubernetes 集群运维实践...
导读:值得阿里巴巴技术人骄傲的是 2019 年阿里巴巴双11 核心系统 100% 以云原生的方式上云,完美支撑了 54.4w 峰值流量以及 2684 亿的成交量.背后承载海量交易的计算力就是来源于容 ...
集群运维：All datanodes DatanodeInfoWithStorage[10.21.131.179:50010,DS-6fca3fba-7b13-4855-b483-342df8432e
规划出一个集群日常维护系列,分享各种奇葩案例,集群运维事故,欢迎大家交流投稿.集群的运维故障排查是一个任重而道远的事情. 1.集群故障现象 Error: java.lang.RuntimeExcept ...
第二课 ceph基础学习-OSD扩容换盘和集群运维
第二课 ceph基础学习-OSD扩容换盘和集群运维文章目录第二课 ceph基础学习-OSD扩容换盘和集群运维第一节 OSD扩容 1.1 扩容背景 1.2 横向扩容 1.3 纵向扩容 1.4 数据 ...
阿里云注册集群+Prometheus 解决多云容器集群运维痛点
作者:左知容器集群可观测现状随着 Kubernetes(K8s)容器编排工具已经成为事实上行业通用技术底座,容器集群监控经历多种方案实践后,Prometheus 最终成为容器集群监控的事实标准. ...
quarts集群运维_分布式定时任务调度系统技术解决方案(xxl-job、Elastic-job、Saturn)...
1.业务场景保险人管系统每月工资结算,平安有150万代理人,如何快速的进行工资结算(数据运算型) 保险短信开门红/电商双十一 1000w+短信发送(短时汇聚型) 工作中业务场景非常多,所涉及到的场景 ...
升腾威讯怎么恢复集群_PB级大规模Elasticsearch集群运维与调优实践
导语 | 腾讯云Elasticsearch 被广泛应用于日志实时分析.结构化数据分析.全文检索等场景中,本文将以情景植入的方式,向大家介绍与腾讯云客户合作过程中遇到的各种典型问题,以及相应的解决思路与 ...
PB 级大规模 Elasticsearch 集群运维与调优实践
作者:bellen,腾讯云大数据研发工程师. 腾讯云 Elasticsearch 被广泛应用于日志实时分析.结构化数据分析.全文检索等场景中,本文将以情景植入的方式,向大家介绍与腾讯云客户合作过程中遇 ...

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

步步惊心，Zookeeper集群运维“避坑”指南相关推荐

最新文章

热门文章