1、
https://zhuanlan.zhihu.com/p/617685164?utm_id=0
服务器相关
告警：Disk read/write request responses are too high
vda: Disk read/write request responses are too high (read > 20 ms for 15m or write > 20 ms for 15m)
表达式解释为:
最近15分钟的对应磁盘的Disk read request avg waiting time (r_await)大于20ms或者 Disk write request avg waiting time (w_await) 大于20ms
解决方案
a、模板Linux block devices by Zabbix agent 中的提高宏{$VFS.DEV.READ.AWAIT.WARN} 和 宏 {$VFS.DEV.WRITE.AWAIT.WARN}的值 默认是20。
b、上SSD系统盘、大容量数据盘。
c、以上两种方法只能解决提示，但解决为何读写高的问题才是根本。
# 查读写io进程 iotop # 查io高的pid和进程 pidstat -d 1 10
告警：High memory utilization ( >90% for 5m)
Linux系统内存占用90%以上、
Linux/Unix系统管理内存的方式和windows是不一样的，即便是一个负载很小的linux，跑几天后， 内存占用量也将达到90%以上，即便无人访问，这个数字是完全正常的。但是，这个内存占用量不会达到100%的，
每天夜里系统都会执行/etc/cron.daily进行内存优化。 Linux/Unix系统是非常稳健的，虽然内存占用显示90%以上，但依然可保证365天以上无须重启。 对于Linux系统，评估其压力的主要指标是最近5分钟的负载指数：比如用top去看， 可以看到“0.70 0.35 0.01”这样的数字，分别表示5分钟内的、10分钟内的、15分钟内排队的进程数， 只要第一个数字即5分钟内的负载不大于5，系统就是健康的，不用做任何维护；如果这个数字大于了5， 那么通常系统速度就会变慢，一般有如下几种可能：
1） 有程序占用大量CPU，使用top命令来检查（看看是否有java程序锁死之类的故障）
2） 有程序占用大量内存，使得内存真正不够用了（这个才是真正需要加内存的时候），比如由于MySQL在较大负载下运行容量为GB级别的数据库导致内存不够用，需要给服务器插入更多物理内存
3） 磁盘系统读写故障，IO吞吐错误造成CPU负载上升，需要光盘引导进入单用户模式扫描修复磁盘，修不好就只能更换新硬盘了
因此，对于Linux/Unix系统内存占用的百分比，无须过于关心，一般检查系统负载参数即可
但也可以手动进行内存释放，具体操作如下：
cat /proc/sys/vm/drop_caches
0
首先,/proc/sys/vm/drop_caches的值,默认为0
Mysql 相关
告警：MySQL: Number of internal temporary tables created per second is high (over 30 for 5m)
解决方案：
Possibly the application using the database is in need of query optimization.
使用数据库的应用程序可能需要查询优化。需要开发人员对使用数据库的应用进行查询逻辑优化。
告警：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在合理计划范围内、增加缓冲池字节大小有利于提高性能。
$ vim /usr/local/mysql/conf/my.cnf #默认安装路径在 /etc/my.cnf innodb_buffer_pool_size = 128M #降低此值即可解决利用率太低的告警
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 用于轮询不可到达到的设备。
可能情况：
通过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。
告警：Zabbix server is not running the information displayed may not be current
原因：监控对象占满了trapper进程导致前端与server无法通信
解决方案：
将server端zabbix配置文件中StartTrappers值调大，然后重启zabbix-server
“At least one trapper process must be running to display server availability and view queue in the frontend.”——Trapper进程用于接收前端查询server可用性及队列的请求将StartTrappers=20调整到StartTrappers=100，重启zabbix-server。
2、
