mntr 有四百多个指标,该盯哪几个?这篇不罗列,而是让同一个节点依次处于四种典型状态,把最常用的十几个指标并排打印,看每种状态下哪些数字会变。
指标 空闲(只有 1 个连接) | 稳定写入(串行同步写,约 3 | 突发:异步 30000 个写 | 300 个连接 + 6000 zk_avg_latency 0.0 | 3.0594 | 3.3447 | 2.0 zk_max_latency 0 | 9 | 11 | 2 zk_outstanding_requests 0 | 1 | 22(洪峰中途采样) | 0 zk_num_alive_connections 2 | 2 | 2 | 302 zk_watch_count 0 | 0 | 0 | 6000 zk_znode_count 2005 | 3234 | 33242 | 33243 zk_ephemerals_count 0 | 0 | 0 | 1 zk_open_file_descriptor_count 68 | 68 | 67 | 367 zk_avg_fsynctime 0.0 | 2.0586 | 1.1588 | 0.0 zk_max_fsynctime 0 | 8 | 8 | 0 zk_packets_received 1 | 1231 | 30002 | 2 zk_last_client_response_size -1 | 26 | 27 | 315843 zk_max_client_response_size -1 | 26 | 27 | 315843
· zk_max_latency 是「自上次 srst 以来」的最大值,要告警就必须定期 srst 或用差值; · zk_outstanding_requests 是瞬时值,洪峰过去就回到 0,所以要高频采样(或看 max); · zk_watch_count、zk_num_alive_connections 是状态量,随客户端行为变化,不会随时间自己恢复; · zk_open_file_descriptor_count 要和 zk_max_file_descriptor_count 对照(连接数 + 日志 / 快照文件都占 fd)。
如何设阈值取决于你的负载与硬件(本文没有给出推荐阈值)。监控的通用做法是:延迟看 p99 而不是平均数(mntr 只给平均 / 最大,需要 Prometheus 的分位数,第 63 篇),连接与 watch 数看趋势,积压看是否持续不降。