Zookeeper集群运维避坑指南是怎么样的
本篇文章给大家分享的是有关Zookeeper集群运维避坑指南是怎么样的,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
创新互联服务项目包括岳西网站建设、岳西网站制作、岳西网页制作以及岳西网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,岳西网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到岳西省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!
首先带来的是“监控”专题系列。
监控,可以判断服务的健康程度、定位服务问题、透视系统内部状态,是运维工作中极其重要的一环。该系列内容将分享京东云在服务监控方面的最佳实践。
本期我们重点讲述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集群运维避坑指南是怎么样的,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。
文章题目:Zookeeper集群运维避坑指南是怎么样的
分享链接:http://scyanting.com/article/pchhcj.html