一、磁盘
1、告警：Disk read/write request responses are too high
表达式解释为:
最近15分钟的对应磁盘的Disk read request avg waiting time (r_await)大于20ms或者 Disk write request avg waiting time (w_await) 大于20ms

min(/Linux block devices by Zabbix agent/vfs.dev.read.await[{#DEVNAME}],15m) > {KaTeX parse error: Expected '}', got '#' at position 27: …D.AWAIT.WARN:"{#̲DEVNAME}"} or m…VFS.DEV.WRITE.AWAIT.WARN:“{#DEVNAME}”}

解决方案
a、模板Linux block devices by Zabbix agent 中的提高宏 {KaTeX parse error: Expected 'EOF', got '}' at position 24: …READ.AWAIT.WARN}̲ 和 宏 {VFS.DEV.WRITE.AWAIT.WARN} 的值 默认是20。
b、上SSD系统盘、大容量数据盘。
c、以上两种方法只能解决提示，但解决为何读写高的问题才是根本。

查读写io进程

iotop

查io高的pid和进程

pidstat -d 1 10

二、数据库相关(Mysql,MariaDB)
1、告警：MySQL: Replication lag is too high (over 30m for 5m)
Seconds_Behind_Master时长超过1800秒，具体实际情况进行恢复主从延迟即可。

2、告警：MySQL: Buffer pool utilization is too low (less 50% for 5m)
由于分配了比实际需要更多的 RAM。结合实际情况，降低其严重性即可。
因为对存储服务器分配更多的RAM在合理计划范围内、增加缓冲池字节大小有利于提高性能。
Mysql官网innodb_buffer_pool_size参数详解

三、Zabbix Server相关
1、告警：More than 100 items having missing data for more than 10 minutes
为轮询器的数量不足以监控监控项

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

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

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

CacheSize:缓存大小, 单位字节.用于存储主机、监控项、触发器数据的共享内存大小。 修改zabbix_server.conf中CacheSize=8M为CacheSize=2048M。

3、告警Zabbix server: Zabbix value cache working in low memory mode

解决方案

修改zabbix_server.conf配置的ValueCacheSize=2048M

四、Redis相关
1、告警：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

2、衍生问题①：开启内存碎片整理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编译。编译以后问题解决。

3、衍生问题②：即使开启自动碎片整理后，仍然会告警。
解决方案
考虑提高阈值。

性能相关
4、告警：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基本没有延迟。

可能是clikchouse数据库特性导致，考虑优化clickhouse配置。
或者修改连接clickhouse程序代码高频低量写入改为流式写入。