028-zabbix问题处理记录

Zabbix Server类问题：

1、Utilization of discoverer processes over 75%解决办法

zabbix server 在开启Discovery功能后，zabbix web页面报警提示：“Zabbix server ：Ulitization of discoverer processes over 75%”。

原因：
每个discovery任务占用一个discovery进程，但是zabbix server默认只配置了一个discovery。

解决办法：
编辑zabbix server配置文件/etc/zabbix/zabbix_server.conf
找到StartDiscoverers，把注释去掉，值给个3或者5即可，然后重启zabbix server服务。
systemctl restart zabbix-server

2、Zabbix server: Utilization of unreachable poller processes over 75%

原因分析：
zabbix server或者zabbix proxy在获取到agentd数据的时候，由于处理过慢，导致接口轮询器堵死。所以此信息就会升高，然后就会报unreachable poller过高

解决办法：
通过调整轮询器参数
server端调整以下参数

StartPollers=10 
StartPollersUnreachable=10

3、Zabbix server: Utilization of icmp pinger processes over 75%

方法：
编辑zabbix server配置文件/etc/zabbix/zabbix_server.conf
找到StartPingers，把注释去掉，值给个0-1000的值，可以稍微大一点。

linux类

1、Load average is too high (per CPU load over 1.5 for 5m)

在linux系统中，查看系统的负载情况：比如top、uptime、w



最直接显示系统平均负载的命令
cat /proc/loadavg

前三个数字表示平均进程数量，后面的分数，分母表示系统进程总数，分子表示正在运行的进程数；最后一个数字表示最近运行的进程ID

单核CPU-数字在0.00-1.00之间正常

0.00-1.00之间表示情况非常良好，没有拥堵
1.00表示还算正常，但有可能会恶化并造成拥堵。此时系统已经没有多余的资源了，需进行优化
1.00-***表示必必须进行检查

多核CPU-数字/CPU核数在0.00-1.00之间正常

多核CPU的话，满负荷状态的数字为“1.00*CPU核数”，即双核CPU为2.00，四核CPU为4.00

安全负载

一般认为单核负载在0.7以下是安全的，超过0.7就需要进行优化了
一般认为看5min和15min的比较好，即后面的2个数字

查看CPU的核心数目
grep 'model name' /proc/cpuinfo | wc -l

结论
取得CPU核心数目N，观察后面的2个数字，用数字/N，如果得到的值小于0.7即正常

2、High swap space usage ( less than 50% free)

[root@localhost ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8G        802M        264M        226M        2.8G        2.6G
Swap:          8.0G        3.3M        8.0G

解决方案：
手动释放虚拟内存
执行操作前，查看swap分区是否满了，首先先查看实际内存剩余，然后查看swap空间用了多少，保证实际剩余内存大于swap内存空间
查看swap分区的挂载位置

swapon -s

[root@localhost ~]# swapon -s
文件名                          类型            大小    已用    权限
/dev/sda3                               partition       8388604 3380    -2

停掉swap分区

swapoff /dev/sda3

停止需要一段时间，目的是将虚拟内存释放到实际内存中

最后启动swap分区

swapon -a
free -h

3、Disk read/write request responses are too high (read > 60 ms for 15m or write > 60 ms for 15m)

解决方案
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、以上两种方法只能解决提示，但解决为何读写高的问题才是根本。

iotop安装：

yum -y install iotop

 Total DISK READ :       0.00 B/s | Total DISK WRITE :       3.90 K/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND        

输出解释 :

项目	解释
Total DISK READ：	从磁盘中读取的总速率
Total DISK WRITE：	往磁盘里写入的总速率
Actual DISK READ：	从磁盘中读取的实际速率
Actual DISK WRITE：	往磁盘里写入的实际速率
TID：	线程ID，按p可转换成进程ID
PRIO：	优先级
USER：	线程所有者
DISK READ：	从磁盘中读取的速率
DISK WRITE：	往磁盘里写入的速率
SWAPIN：	swap交换百分比
IO>：	IO等待所占用的百分比
COMMAND：	具体的进程命令

命令	解释	示例
-o, --only：	//仅显示实际执行I / O的进程或线程，只显示在划硬盘的程序	iotop -o
-p PID, --pid=PID：	//要监控的进程/线程[全部]	iotop –p 3313（仅监控3313进程)
-d SEC, --delay=SEC：	//设定显示时间间隔[秒]	iotop –d 5
-u USER, --user=USER：	//用户监控[全部]	iotop –u oracle
-P, --processes：	//只显示进程，而不是所有线程
-a, --accumulated：	//显示累积的I / O而不是带宽
-k, --kilobytes：	//使用千字节而不是人性化的单位
-t, --time：	//在每一行上添加一个时间戳（暗示–batch）
-b:	批量显示，无交互，主要用于记录到文件	iotop -b >> iotop.txt

若不使用-b选项启动iotop，是可以交互的，可以在运行期间执行一些命令，如下：

交互命令	描述
左右箭头	改变排序的列
r	反向排序，按io
o	切换至选项–only，只显示有I/O的进程或线程
p	切换至–processes选项
a	切换至–accumulated选项，显示累计使用量
q	退出
i	改变线程的优先级

交互模式下除了以上这些交互命令键之外的任意键都会强制刷新

Windows类

1、CPU privileged time is too high (over 30% for 5m)

如果CPU的特权时间（privileged time）持续保持在较高水平，例如超过30%持续5分钟，这可能是一个性能问题的迹象。高特权时间通常意味着操作系统内核或运行在特权级别的代码（如设备驱动程序、系统服务等）正在大量使用CPU资源。
这种情况可能会导致以下问题：
系统响应延迟：高特权时间可能导致用户级应用程序得不到足够的CPU时间，从而响应变慢。
资源争用：过多的特权级操作可能导致资源（如内存、I/O等）的争用，降低整体系统效率。
系统稳定性问题：长时间的高特权时间可能意味着系统存在不稳定因素，如驱动程序bug或内核问题。
能源消耗增加：高CPU使用率通常意味着更高的能源消耗。

网络设备类