AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

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

  • 2019-08-13
  • 本文字数:2780 字

    阅读完需:约 9 分钟

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

Zookeeper(文中简称 ZK)是一个开放源码的分布式应用程序协调服务,是 Google 公司 Chubby 服务的开源实现,同时也是 Hadoop 和 Hbase 等开源软件的重要组件。文章将从 ZK 监控案例的角度出发,让大家了解 ZK 的一些重要监控指标。

服务故障案例

容量问题:

部分 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 集群的文件句柄数,使用了系统默认的 10240,而系统实际的压力远不止于此,因此会出现 ZK 无法处理部分新的请求,而问题定位的成本和耗时也会增加。发现问题后,通过调整 ZK 运行账号的文件句柄数限制并重启服务即可解决。


在这个案例中,如果及早添加了 zk_open_file_descriptor_count/zk_max_file_descriptor_count,则能够避免该问题。同时,很多开源软件都会遇到文件句柄数的问题,且多次引发各类系统的重大故障,所以还是要谨慎对待。

流量问题:

一个分布式系统上线新功能,其客户端在前几日逐步更新后未发现问题,因此在某一日对客户端进行了全量更新,所有客户端均会定期请求 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 集群提供了全地域的协调服务,当 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 监控)

  • 端口监控

  • 日志监控

  • 主机监控


附录:Zookeeper 四字命令


  • mntr



  • stat



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


相关阅读


阿里巴巴为什么不用 ZooKeeper 做服务发现?


2019-08-13 10:588263

评论 1 条评论

发布
用户头像
Exhibitor,ZooKeeper 的运维工具,提供了监控、日志清理、备份、集群配置、自动实例管理、可视化、REST API 等诸多功能,还可以和 Curator 进行集成。
2019-10-30 14:27
回复
没有更多了
发现更多内容

天下武功,唯快不破

CloudStudio

cloudstudio

YashanDB数据操作

YashanDB

数据库 yashandb

如何建设IT运维管理体系

易成研发中心

IT运维管理

企业必备工具:15款员工绩效管理系统推荐

易成研发中心

绩效考核系统

今晚 8 点直播:Alexa+ 让 6 亿终端瞬间获得 AI 能力!端侧智能都有哪些开发者机会?丨 RTE Dev Talk

声网

一台电脑如何搞定手机矩阵(教你从网络搭建开始做矩阵)

kookeey代理严选

亚马逊 TikTok 跨境矩阵 跨进电商

IT项目管理中开发项目时都有哪些角色

易成研发中心

项目管理

AI听力练习APP的测试

北京木奇移动技术有限公司

软件外包公司 AI口语练习 AI英语口语

巨日禄AI:一站式创作漫画故事视频,百种画风赋美创作

编程猫

2025年企业级网盘推荐:10款适合多人共享的工具

易成研发中心

云盘 网盘 企业网盘

YashanDB索引操作

YashanDB

数据库 yashandb

用精准与效率说话,一招解决 SQL Server 迁移痛点

NineData

SqlServer NineData 国产化替代 云原生智能数据管理平台 上云迁移

AI时代,Java程序员该何去何从

飞算JavaAI开发助手

写在2025 MWC前夕:AI与移动网络融合的“奇点时刻”

Alter

AI 5G

除了DeepSeek,还有哪些好用的AI软件呢?

职场工具箱

人工智能 职场 AI软件 AIGC DeepSeek

基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成

Apache Flink

flink kafka 实时计算 数据集成

【万字长文】开源之播对话白鲸开源CEO郭炜--乐观主义的开源精神走得更远

Apache SeaTunnel

开源社区 人物访谈 开源商业

Apache SeaTunnel 构建实时数据同步管道(最新版)

Apache SeaTunnel

数据同步 数据集成 CDC Seatunnel

精选案例展|《金融电子化》:打造郑州银行一体化及可观测的智能运维体系

博睿数据

YashanDB事务操作

YashanDB

数据库 yashandb

YashanDB数据操作

YashanDB

数据库 yashandb

NocoBase 本周更新汇总:新增路由管理

NocoBase

开源 低代码 零代码 无代码 版本更新

蚂蚁技术研究院发布推理大模型强化学习框架,邀请开发者共同助力 AGI 生态

蚂蚁开源

AGI RL 蚂蚁开源 LRM

懒猫微服无缝连接你所有的设备

玄兴梦影

NAS 远程连接 异地组网 懒猫微服 设备互联

大模型驱动智能合规 | 构建企业个保审计新范式

百度安全

步步惊心,Zookeeper集群运维“避坑”指南_软件工程_京东云应用研发部_InfoQ精选文章