本文详细记录了Zabbix Server中遇到的问题，如Utilization of discoverer和unreachable poller processes超过75%的处理办法，以及Linux系统中高负载、高交换空间使用和磁盘读写延迟的解决方案。此外，还提到了Windows类问题和网络设备类问题的关注点。
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使用率通常意味着更高的能源消耗。
扫一扫
3696
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
