zk日常运维管理

清理数据目录

dataDir目录指定了ZK的数据目录，用于存储ZK的快照文件（snapshot）。另外，默认情况下，ZK的事务日志也会存储在这个目录中。在完成若干次事务日志之后（在ZK中，凡是对数据有更新的操作，比如创建节点，删除节点或是对节点数据内容进行更新等，都会记录事务日志），ZK会触发一次快照（snapshot），将当前server上所有节点的状态以快照文件的形式dump到磁盘上去，即snapshot文件。这里的若干次事务日志是可以配置的，默认是100000，具体参看下文中关于配置参数“snapCount”的介绍。
正常运行过程中，ZK会不断地把快照数据和事务日志输出到这两个目录，并且如果没有人为操作的话，ZK自己是不会清理这些文件的，需要管理员来清理，这里介绍4种清理日志的方法。在这4种方法中，推荐使用第一种方法

第一种，也是运维人员最常用的，写一个删除日志脚本，每天定时执行即可：


#!/bin/bash

#snapshot file dir

dataDir=/home/nileader/taokeeper/zk_data/version-2

#tran log dir

dataLogDir=/home/nileader/taokeeper/zk_log/version-2

#zk log dir

logDir=/home/nileader/taokeeper/logs

#Leave 60 files

count=60

count=$[$count+1]

ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f

ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f

ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f

以上这个脚本定义了删除对应两个目录中的文件，保留最新的60个文件，可以将他写到crontab中，设置为每天凌晨2点执行一次就可以了。**

第二种，使用ZK的工具类PurgeTxnLog，它的实现了一种简单的历史文件清理策略，可以在这里看一下他的使用方法：http://zookeeper.apache.org/doc/r3.4.3/api/index.html，可以指定要清理的目录和需要保留的文件数目，简单使用如下：

1.java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir><snapDir> -n <count>

第三种，对于上面这个Java类的执行，ZK自己已经写好了脚本，在bin/zkCleanup.sh中，所以直接使用这个脚本也是可以执行清理工作的。

第四种，从3.4.0开始，zookeeper提供了自动清理snapshot和事务日志的功能，通过配置 autopurge.snapRetainCount 和 autopurge.purgeInterval 这两个参数能够实现定时清理了。这两个参数都是在zoo.cfg中配置的：

autopurge.purgeInterval 这个参数指定了清理频率，单位是小时，需要填写一个1或更大的整数，默认是0，表示不开启自己清理功能。

autopurge.snapRetainCount 这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。

日志输出到指定文件夹

ZK默认是没有向ROLLINGFILE文件输出程序运行时日志的，需要我们自己在conf/log4j.properties中配置日志路径。另外，没有特殊要求的话，日志级别设置为INFO或以上，我曾经测试过，日志级别设置为DEBUG的话，性能影响很大！
具体操作请看:http://www.tuicool.com/articles/MbUb63n

监控

1、 ZK提供一些简单但是功能强大的4字命令，通过对这些4字命令的返回内容进行解析，可以获取不少关于ZK运行时的信息。

常用的四字命令

conf:
输出server的详细配置信息。

echo conf|nc localhost 2181 

clientPort=2181
dataDir=/home/test/taokeeper/zk_data/version-2
dataLogDir=/test/admin/taokeeper/zk_log/version-2
tickTime=2000
maxClientCnxns=1000
minSessionTimeout=4000
maxSessionTimeout=40000
serverId=2
initLimit=10
syncLimit=5
electionAlg=3
electionPort=3888
quorumPort=2888
peerType=0

cons:
输出指定server上所有客户端连接的详细信息，包括客户端IP，会话ID等。 New in 3.3.0类似于这样的信息：

echo cons|nc localhost 2181
/1.2.3.4:43527[1](queued=0,recved=152802,sent=152806,sid=0x2389e662b98c424,lop=PING,est=1350385542196,to=6000,lcxid=0×114,lzxid=0xffffffffffffffff,lresp=1350690663308,llat=0,minlat=0,avglat=0,maxlat=483)
……

crst:
功能性命令。重置所有连接的统计信息。New in 3.3.0

dump:
这个命令针对Leader执行，用于输出所有等待队列中的会话和临时节点的信息。

envi:
用于输出server的环境变量。包括操作系统环境和Java环境。

ruok:
用于测试server是否处于无错状态。如果正常，则返回“imok”,否则没有任何响应。 注意：ruok不是一个特别有用的命令，它不能反映一个server是否处于正常工作。“stat”命令更靠谱。

stat
输出server简要状态和连接的客户端信息。

srvr
和stat类似，New in 3.3.0

echo stat|nc localhost 2181 

Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT
Clients:
/10.2.3.4:59179[1](queued=0,recved=44845,sent=44845) 

Latency min/avg/max: 0/0/1036
Received: 2274602238
Sent: 2277795620
Outstanding: 0
Zxid: 0xa1b3503dd
Mode: leader
Node count: 37473

echo srvr|nc localhost 2181 

Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT
Latency min/avg/max: 0/0/980
Received: 2592698547
Sent: 2597713974
Outstanding: 0
Zxid: 0xa1b356b5b
Mode: follower
Node count: 37473

srst:
重置server的统计信息。

wchs:
列出所有watcher信息概要信息，数量等

wchc:
出所有watcher信息，以watcher的session为归组单元排列

echo wchc|nc localhost 2181 

0x2389e662b97917f
/mytest/test/path1/node1
0x3389e65c83cd790
/mytest/test/path1/node2
0x1389e65c7ef6313
/mytest/test/path1/node3
/mytest/test/path1/node1

wchp
列出所有watcher信息，以watcher的path为归组单元排列

echo wchp|nc localhost 2181 

/mytest/test/path1/node
0x1389e65c7eea4f5
0x1389e65c7ee2f68
/mytest/test/path1/node2
0x2389e662b967c29
/mytest/test/path1/node3
0x3389e65c83dd2e0
0x1389e65c7f0c37c
0x1389e65c7f0c364

注意，wchc和wchp这两个命令执行的输出结果都是针对session的，对于运维人员来说可视化效果并不理想，可以尝试将cons命令执行输出的信息整合起来，就可以用客户端IP来代替会话ID了，具体可以看这个实现：http://rdc.taobao.com/team/jm/archives/1450

mntr:
输出一些ZK运行时信息，通过对这些返回结果的解析，可以达到监控的效果。

$ echo mntr | nc localhost 2185
zk_version 3.4.0
zk_avg_latency 0
zk_max_latency 0
zk_min_latency 0
zk_packets_received 70
zk_packets_sent 69
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count 4
zk_watch_count 0
zk_ephemerals_count 0
zk_approximate_data_size 27
zk_followers 4 – only exposed by the Leader
zk_synced_followers 4 – only exposed by the Leader
zk_pending_syncs 0 – only exposed by the Leader
zk_open_file_descriptor_count 23 – only available on Unix platforms
zk_max_file_descriptor_count 1024 – only available on Unix platforms

JMX方式

用jmx也能够获取一些运行时信息，详细可以查看这里：http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html
**第一种方式 :参数配置：java.env
**

$ cd $ZK_HOME/conf
$ vi java.env
JVMFLAGS=" -Djava.rmi.server.hostname=192.168.56.112 -Dcom.sun.management.jmxremote.port=8988 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xms512m -Xmx512m $JVMFLAGS"
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"
ZOO_LOG_DIR="/var/log/zookeeper/"

**第二种方式:打开%ZK_HOME%/bin目录下的zkServer.sh文件.找到如下配置
**

找到zkServer.sh文件
ZOOMAIN="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=$JMXLOCALONLY org.apache.zookeeper.server.quorum.QuorumPeerMain"

在这个配置中并没有打开远程连接jmx的端口命令,通常需要再加上以下三个配置才能开启远程jmx
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8988
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
````

当配置 JMX 后，可以使用 jconsole 工具连接监控 zookeeper

<div class="se-preview-section-delimiter"></div>

###工具监控
1. 查看内存中的节点信息:ZooInspector
2. 查看并修改节点信息:node-zk-brower
3. 性能监控的工具 zookeeper-benchmark,zk-smoketest

<div class="se-preview-section-delimiter"></div>

###查看快照文件及事务日志文件

<div class="se-preview-section-delimiter"></div>

$ java -cp zookeeper-3.4.6.jar:lib/log4j-1.2.16.jar:lib/slf4j-log4j12-1.6.1.jar:lib/slf4j-api-1.6.1.jar org.apache.zookeeper.server.LogFormatter ./datalog/version-2/log.30060aab4

$ java -cp zookeeper-3.4.6.jar:lib/log4j-1.2.16.jar:lib/slf4j-log4j12-1.6.1.jar:lib/slf4j-api-1.6.1.jar org.apache.zookeeper.server.SnapshotFormatter ./data/version-2/snapshot.300629b34
“`

加载数据出错

ZK在启动的过程中，首先会根据事务日志中的事务日志记录，从本地磁盘加载最后一次提交时候的快照数据，如果读取事务日志出错或是其它问题（通常在日志中可以看到一些IO异常），将导致server将无法启动。碰到类似于这种数据文件出错导致无法启动服务器的情况，一般按照如下顺序来恢复：
1、确认集群中其它机器是否正常工作，方法是使用“stat”这个命令来检查：echo stat|nc ip 2181
2、如果确认其它机器是正常工作的（这里要说明下，所谓正常工作还是指集群中有过半机器可用），那么可以开始删除本机的一些数据了，删除dataDir/version−2和dataLogDir/version-2 两个目录下的所有文件。
重启server。重启之后，这个机器就会从Leader那里同步到最新数据，然后重新加入到集群中提供服务。

注意事项

1 保持Server地址列表一致
A、客户端使用的server地址列表必须和集群所有server的地址列表一致。（如果客户端配置了集群机器列表的子集的话，也是没有问题的，只是少了客户端的容灾。）
B、集群中每个server的zoo.cfg中配置机器列表必须一致。
2 独立的事务日志输出
对于每个更新操作，ZK都会在确保事务日志已经落盘后，才会返回客户端响应。因此事务日志的输出性能在很大程度上影响ZK的整体吞吐性能。强烈建议是给事务日志的输出分配一个单独的磁盘。
3 配置合理的JVM堆大小
确保设置一个合理的JVM堆大小，如果设置太大，会让内存与磁盘进行交换，这将使ZK的性能大打折扣。例如一个4G内存的机器的，如果你把JVM的堆大小设置为4G或更大，那么会使频繁发生内存与磁盘空间的交换，通常设置成3G就可以了。当然，为了获得一个最好的堆大小值，在特定的使用场景下进行一些压力测试。

注意事项

1 保持Server地址列表一致
A、客户端使用的server地址列表必须和集群所有server的地址列表一致。（如果客户端配置了集群机器列表的子集的话，也是没有问题的，只是少了客户端的容灾。）
B、集群中每个server的zoo.cfg中配置机器列表必须一致。
2 独立的事务日志输出
对于每个更新操作，ZK都会在确保事务日志已经落盘后，才会返回客户端响应。因此事务日志的输出性能在很大程度上影响ZK的整体吞吐性能。强烈建议是给事务日志的输出分配一个单独的磁盘。
3 配置合理的JVM堆大小
确保设置一个合理的JVM堆大小，如果设置太大，会让内存与磁盘进行交换，这将使ZK的性能大打折扣。例如一个4G内存的机器的，如果你把JVM的堆大小设置为4G或更大，那么会使频繁发生内存与磁盘空间的交换，通常设置成3G就可以了。当然，为了获得一个最好的堆大小值，在特定的使用场景下进行一些压力测试。

========广告时间========

鄙人的新书《Tomcat内核设计剖析》已经在京东销售了，有需要的朋友可以到 https://item.jd.com/12185360.html 进行预定。感谢各位朋友。

为什么写《Tomcat内核设计剖析》

=========================

时间： 2024-11-05 16:41:04

zk日常运维管理的相关文章

ITIL与IT运维管理的“前世姻缘”

IT运维管理的由来 在企业IT管理的早期,更侧重于对网络.硬件等设备的管理.那时的IT管理就是通过某种方式对网络进行管理,使网络能正常高效地运行.早期的这种IT管理是NSM的阶段,主要的面向目标就是底层的基础网络设备.NSM系统是对网络中的底层设备进行实时的,统一的监控,当网络中出现了问题或者即将出现问题的时候,NSM向网络管理者提出故障定位和报警,这样做无疑大大方便了网络管理员的工作.但是,NSM系统对于网络上运行的各种业务系统以及业务系统的用户只能做一些简单的管理,这个时期的IT管理,可称之

摩卡IT运维管理(Mocha ITOM)解决方案

方案概述 专家研究和大量企业实践表明,IT项目生命周期中,大约80%的时间与IT项目运营维护有关,而该阶段的投资仅占整个IT投资的20%,形成了典型的"轻服务.重技术"现象.国际著名咨询调查机构Gartner集团的调查发现,在经常出现的问题中,源自技术或产品(包括硬件.软件.网络.电力失常及天灾等)方面的问题其实只占20%,而流程失误问题占40%,人员疏失问题占40%.流程失误包括未做好变更管理.超载.无测试等程序上的错误或不完整,人员疏失包括忘做某些事情.训练不足.备份错误或安全疏忽

大型数据中心如何做运维管理？

摘要:在云大行其道的今天,随着数据中心建设规模的不断扩大,新技术的层出不穷,数据中心变得越来越复杂.大型数据中心往往是由很多规模庞大的集群系统组成,其运维工作需要具备方方面面的知识,包括硬件.网络.服务器.存储.安全以及业务上的东西,需要上下打通地去做运维工作. 当一个数据中心的规模非常大,面临的挑战和问题也比较超前,很多在小环境小体系下不是问题的问题在这样的规模下也就凸显出来了,所以要做好大型数据中心的运维工作,对整个数据中心技术体系的系统学习就要花费比较长的时间,只有对这个数据中心整体非常了

望、闻、问、切”四大技巧轻松搞定IT运维管理

中华医学博大精深,精髓莫过于"望.闻.问.切",这四大法宝成为调查了解疾病过程中重要的手段,可谓各司其职,各尽其能,相辅相成,缺一不可.中医大夫在应诊时,只有将 它们有机地结合起来,即"四诊合参"才可能全面而系统地了解病情,从而做出正确判断,果断采取措施.是否有是曾相识的感觉?事实上 IT运维管理跟中医诊疗法有异曲同工之处,一套完整的.基于事前管理的网络运维管理系统针对日常运维工作的特点,能做到及时发现网络中潜在的故障隐患,并能够进行及时处理,以保证整个系统的正常运

mysql日常运维

DBA运维工作 日常 导数据.数据修改.表结构变更 加权限.问题处理 其它 数据库选型部署.设计.监控.备份.优化等 日常运维工作 导数据及注意事项 数据最终形式(csv.sql文本,还是直接导入到某个库中) 导数据的方法(mysqldump.select into outfile) 导数据注意事项 导出为csv格式需要file权限,并且只能数据库本地导 避免锁库锁表(mysqldump使用–single-transaction选项不锁表) 避免对业务造成影响,尽量在镜像库做 简单案例 数据修改

面向NFV的运维管理，打造绿色“软”网络

NFV网络功能虚拟化是一场正在发生的网络革命.这场变革借助IT先进技术,将对运营商运营业务产生持久深刻的影响.当前,关于虚拟化和云如何用于电信产业以改善架构与运维TCO有颇多论述.从NFV的应用上看,早期的工作集中在利用虚拟化能力优化硬件,现在则逐渐转向运维. NFV重新定义运维 尽管将某些网络功能虚拟化确实会带来CAPEX方面的节省,然而NFV最大的贡献并不在此,而是它提供了一种实现电信能力的新方式,意义远不止对当前流程的效率优化这样简单. 按照NFV 标准架构,为便于虚拟资源的动态管理,特别

“洗衣机之争”与IT运维管理

近年来,随着信息化的发展企业IT系统越来越庞大,应用也越来越 复杂,IT运维管理已经一跃成为信息化的热门领域.然而,一些企业对IT运维管理软件的重视和认识程度还停留在为什么上,"头痛医头,脚痛医脚",不到万不得己,仍然是"能省则省"."IT运维管理对企业来说,不是锦上 添花,而是'必备用品'.就好比,手工洗衣与洗衣机,同样都可以把衣服洗干净, 但是,很少有家庭会因为衣服可以手工洗而不买洗衣机.与其把时间浪费在人工管理还是运维管理的争执上,不如象买洗衣机一样

如何在AWS中落实安全运维管理

安全在传统上总是被当成软件开发过程中"事后再想"的部分.但人人闻之色变Heartbleed漏洞及其相关的补丁困难使安全性被推到了最前线.而一个使用安全 运维管理,或SecOps的安全软件开发周期方式将可以加强AWS应用的安全性. SecOps方法就有如DevOps原则一样,促进了开发者和运营之间更好的沟通,只是对应的是安全方面,Todd Vernon,一家DevOps工具供应商VictorOps的CEO说道.DevOps允许IT团队能够在部署 云应用至生产前快速做出改动.但这也产生了显

只需四步轻松搞定瘦客户机运维管理

为用户挑选合适的设备可以为运行在数据中心的桌面带来诸多益处,但首先,你得选对瘦客户机.在之前的文章中,我们介绍了一些选择瘦客户机的技巧,例如要考虑一致性.内存扩展性等.实际上,企业真正要用好瘦客户机就必须拥有一套集中管理基础设施,这样才能降低长期运维开销. 第一步:找对管理工具 主要的还是你要明白你自己环境中的具体需求,然后看供应商是否有相应工具可用.如果工具不够灵活或者难以使用,就需要考虑更换终端类型或者供应商了.一些供应商针对特殊的瘦客户端类型提供了不同的工具.寻找能够针对瘦客户端应用组策略