Zabbix告警问题记录与解决

Zabbix告警问题记录与解决

• • Mysql 相关
  • • `告警：MySQL: Replication lag is too high (over 30m for 5m)`
    • `告警：MySQL: Buffer pool utilization is too low (less 50% for 5m)`
  • Zabbix Server相关
  • • `告警：More than 100 items having missing data for more than 10 minutes `
    • • 解决方案
    • `告警：Zabbix poller processes more than 75% busy`
    • • 解决方案
  • Redis相关
  • • `告警：Redis: Memory fragmentation ratio is too high (over 1.5 in 15m)`
    • • 解决方案
      • 衍生问题①：开启内存碎片整理`activedefrag yes`报错(error)
      • 解决方案
      • 衍生问题②：即使开启自动碎片整理后，仍然会告警。
      • 解决方案
  • 性能相关
  • • `告警：sda: Disk read/write request responses are too high (read > 20 ms for 15m or write > 20 ms for 15m)`
    • • 解决方案（暂未解决）

Mysql 相关 告警：MySQL: Replication lag is too high (over 30m for 5m)

Seconds_Behind_Master时长超过1800秒，具体实际情况进行恢复主从延迟即可。

告警：MySQL: Buffer pool utilization is too low (less 50% for 5m)

由于分配了比实际需要更多的 RAM。结合实际情况，降低其严重性即可。
因为对存储服务器分配更多的RAM在合理计划范围内、增加缓冲池字节大小有利于提高性能。
Mysql官网innodb_buffer_pool_size参数详解

Zabbix Server相关 告警：More than 100 items having missing data for more than 10 minutes

为轮询器的数量不足以监控监控项

解决方案

StartPollers 轮询器实例数量。根据具体情况设置大小，默认为5
修改zabbix_server.conf中StartPollers=5为StartPollers=100。

告警：Zabbix poller processes more than 75% busy

unreachable poller processes 一直在处于busy的状态，那这个具体代表什么意思呢，查看官方文档zabbix internal process、unreachable poller - poller for unreachable devices 用于轮询不可到达到的设备。
可能情况：

1. 通过Zabbix agent采集数据的设备处于moniting的状态但是此时机器死机或其他原因导致zabbix agent死掉server获取不到数据，此时unreachable poller就会升高。
2. 通过Zabbix agent采集数据的设备处于moniting的状态但是server向agent获取数据时时间过长，经常超过server设置的timeout时间，此时unreachable poller就会升高。
3. 支撑Zabbix的MySQL卡住了，Zabbix服务器的IO卡住了都有可能，Zabbix进程分配到内存不足都有可能。
   一个简单的方法是增加Zabbix Server启动时初始化的进程数量，这样直接增加了轮询的负载量，从比例上来讲忙的情况就少了。

解决方案

CacheSize:缓存大小, 单位字节.用于存储主机、监控项、触发器数据的共享内存大小。

修改zabbix_server.conf中CacheSize=8M为CacheSize=2048M。

Redis相关 告警：Redis: Memory fragmentation ratio is too high (over 1.5 in 15m)

内存碎片率：mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory ：Redis使用其分配器分配的内存大小
used_memory_rss ：操作系统分配给Redis实例的内存大小，表示该进程所占物理内存的大小
两者包括了实际缓存占用的内存和Redis自身运行所占用的内存，used_memory_rss指标还包含了内存碎片的开销，内存碎片是由操作系统低效的分配/回收物理内存导致的。
mem_fragmentation_ratio < 1 表示Redis内存分配超出了物理内存，操作系统正在进行内存交换，内存交换会引起非常明显的响应延迟；
mem_fragmentation_ratio > 1 是合理的；
mem_fragmentation_ratio > 1.5 说明Redis消耗了实际需要物理内存的150%以上，其中50%是内存碎片率，可
内存碎片率略高于1是属于正常，但超出1.5的时候就说明redis的内存管理变差了
分析实际环境，因为该redis主要是存储频繁更新的数据，每次更新数据之前，redis会删除旧的数据，实际上，由于Redis释放了内存块，但内存分配器并没有返回内存给操作系统。

解决方案

开启碎片整理为redis.conf中，修改# activedefrag no为activedefrag yes。

# 开启碎片整理
activedefrag yes
# 当碎片达到 100mb 时，开启内存碎片整理
#active-defrag-ignore-bytes 100mb
# 当碎片超过 10% 时，开启内存碎片整理
#active-defrag-threshold-lower 10
# 内存碎片超过 100%，则尽最大努力整理
active-defrag-threshold-upper 100
# 内存自动整理占用资源最小百分比
active-defrag-cycle-min 25
# # 内存自动整理占用资源最大百分比
active-defrag-cycle-max 75

衍生问题①：开启内存碎片整理activedefrag yes报错(error)

ERR Active defragmentation cannot be enabled: it requires a Redis server compiled with a modified Jemalloc like the one shipped by default with the Redis source distribution

这个内存分配器是在编译时指定的，可以是libc、jemalloc或者tcmalloc。used_memory_rss会越来越大，导致mem_fragmentation_ratio越来越高

解决方案

因编译的时候内存分配器非jemalloc，需要重新使用jemalloc编译。编译以后问题解决。

衍生问题②：即使开启自动碎片整理后，仍然会告警。 解决方案

考虑提高阈值。

性能相关 告警：sda: Disk read/write request responses are too high (read > 20 ms for 15m or write > 20 ms for 15m)

装有Clickhouse服务器A1、A2、S1、S2磁盘写入等待时间高于默认20ms

r_await：每个读操作平均所需的时间=[Δrd_ticks/Δrd_ios]
不仅包括硬盘设备读操作的时间，还包括了在kernel队列中等待的时间。
w_await：每个写操作平均所需的时间=[Δwr_ticks/Δwr_ios]
不仅包括硬盘设备写操作的时间，还包括了在kernel队列中等待的时间。

解决方案（暂未解决）

根据读r_await基本没有延迟。

1. 可能是clikchouse数据库特性导致，考虑优化clickhouse配置。
2. 或者修改连接clickhouse程序代码高频低量写入改为流式写入。
3. 2021年08月30日18:31:09将告警阈值改为100，