zabbix运维告警处理-磁盘读写

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、