摘要
学习过程中整理
本文记录
- 安装zookeeper单机过程
- 安装zookeeper集群、扩容的过程
- zookeeper的监控数据
安装zookeeper
设置环境变量
1 | WORKDIR="/usr/local/src" |
创建zookeeper用户
1 | useradd zookeeper |
下载安装包
1 | cd ${WORKDIR} |
创建配置文件
1 | cd /usr/local/zookeeper/conf |
添加环境变量
1 | echo -e "export ZOOKEEPER_HOME=/usr/local/zookeeper |
启动服务
1 | su - zookeeper |
其他命令
1 | zkServer.sh --help |
zookeeper集群模式
1 | cd /usr/local/zookeeper/conf |
查看节点状态
1 | echo srvr | nc 127.0.0.1 2181 |
扩容
新增两个节点,直接增加配置
1 | cd /usr/local/zookeeper/conf |
先启动新增的节点,然后依次重启所有节点
1 | zkServer.sh |
查看状态
1 | echo srvr | nc 127.0.0.1 2181 |
测试
1 | #zk1 |
监控
zookeeper监控指标
目前zookeeper
获取监控指标已知的有两种方式
- 通过
zookeeper
自带的four letter words command
获取各种各样的监控指标 - 通过
JMX Client
连接zookeeer
对外提供的MBean
来获取监控指标(需要修改启动脚本,使其支持远程JMX连接)
上述两种方式获取的指标大体上是一致的。
本文采用第一种的方式
四字命令
使用方法
1 | echo commands | nc ip port |
conf
能够获取到zookeeper的配置信息
- 客户端端口
- 数据以及日志路径,
- 间隔单位时间,
- 单台server与单个client端的连接数限制,
- 超时时间,
- serverId等等信息,
Follower在启动过程中,会从Leader同步所有最新数据,然后确定自己能够对外服务的起始状态。Leader允许F在initLimit时间内完成这个工作。
在运行过程中,Leader负责与ZK集群中所有机器进行通信,例如通过一些心跳检测机制,来检测机器的存活状态。如果L发出心跳包在syncLimit之后,还没有从F那里收到响应,那么就认为这个F已经不在线了。
cons
连接信息的总览,
- 连接ip
- 端口号
- 该连接的发包数
- 该连接的收包数
- 连接的session Id
- 最后操作方式/命令
- 连接的时间戳
- 超时时间(未确认)
- 最后的zxid
- 最后的响应时间戳
- 连接的时间延时信息
crst
重置连接状态,是一个execute
操作,不是一个select
操作
执行后返回一个状态信息:
1 | Connection stats reset. |
dump
输出所有等待队列中的会话和临时节点的信息
envi
当前server的环境信息:
- 版本信息
- 主机的host
- jvm相关参数:version,classpath,lib等等
- os相关参数:name,version等等
- 当前host用户信息:name,dir等等
ruok
查询当前server状态是否正常 若正常返回imok
imok
srst
同样是一个execute操作而不是select,重置server状态:
srvr
server的简要信息:
- 版本
- 延时
- 收包数
- 发包数
- 连接数
- 状态等信息
stat
一些状态信息和连接信息,是前面一些信息的组合:
wchs
有watch path的连接数 以及watch的path数 和 watcher数
wchc
连接监听的所有path:(考虑吧cons命令 信息整合)
wchp
path被那些连接监听:(考虑把cons命令 信息整合)
mntr
用于监控zookeeper server 健康状态的各种指标:
- 版本
- 延时
- 收包
- 发包
- 连接数
- 未完成客户端请求数
- leader/follower 状态
- znode 数
- watch 数
- 临时节点数
- 近似数据大小 应该是一个总和的值
- 打开文件描述符 数
- 最大文件描述符 数
- fllower数
1 | zk_avg/min/max_latency 响应一个客户端请求的时间,建议这个时间大于10个Tick就报警 |
监控脚本
1 | cat zk_monitor.sh |
1 | # zookeeper.py |