Zabbix误报交换机重启Uptime问题

原创 已于 2023-10-09 11:00:08 修改 · 1.8k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#zabbix

于 2023-10-09 10:27:26 首次发布
文章讲述了作者在使用Zabbix监控时，发现交换机的Uptime值溢出导致误报。通过分析SNMP的sysUpTimeInstance和snmpEngineId计数值，发现后者能更准确地反映设备运行时间。最后，作者指导如何在Zabbix模板项中修改SNMPOID以解决此问题。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
 
1、检查是否是交换机重启导致，使用默认OID

1.1 login zabbix server or zabbix proxy check
[root@zbx-proxy01 ~]# snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5261304) 14:36:53.04
 
1.2 login switch check
WL-4507# uptime           ----执行查看
WL-4507 uptime is 1 year, 18 weeks, 6 days, 3 hours, 29 minutes
Uptime for this control processor is 1 year, 18 weeks, 6 days, 3 hours, 31 minutes
System returned to ROM by power-on
System restarted at 11:14:10 BeiJing Tue Jan 12 2016

结果发现交换机并没有重启，这台设备Uptime是1年18周6天，大概就是497天。
 
2、验证

原因分析
经过查阅相关资料，得知UpTime是

最低0.47元/天 解锁文章
Zabbix探索：关于网络设备SysUpTime监控的问题
weixin_34242658的博客
05-22 2431
2019独角兽企业重金招聘Python工程师标准>>> ...
Zabbix --- Snmp Trap监控详细教程
z的博客
08-24 1万+
Zabbix --- Snmp Trap监控教程
zabbix监控交换机sysuptime误报问题
gaodi2002的博客
11-27 516
交换机的sysUpTime是由一个32-bit的counter来计数的，单位是0.01秒，所以最大时间为496天，过了496天就溢出，变成0，然后又重新计算时间，所以zabbix误报。可以使用另一个计数值来计算时间，那就是snmpEngineld (1.3.6.1.6.3.10.2.1.3.0)，其同样是32-bit的值，...
Zabbix监控误报交换机重启问题
weixin_33725807的博客
04-11 1873
Zabbix监控误报交换机重启问题 问题描述 最近时不时无规律的收到zabbix的监控报警，是不同的交换机重启的误报，提示交换机重启了，但检查看后发现实际并没有重启。 我们发现监控是否重启是监控交换机的引导时间，使用的是如下OID： [root@rds ~]# snmpwalk -v 2c -c public 192.168.1.9 1.3.6.1.2.1.1.3.0 DISMAN-EVENT...
zabbix误报交换机重启
01-11 712
交换机的sysUpTime是由一个32-bit的counter来计数的，单位是0.01秒，所以最大时间为496天，过了496天就溢出，变成0，然后又重新计算时间，所以zabbix误报。 snmpwalk -v 3 -u zfop -a MD5 -A zfop2016 -x DES -X zfop2016 -l authPriv 172.82.10.234 1.3.6.1.2.1.1...
zabbix图表时间与服务器时间不一致问题
tootsy_you的博客
04-02 1631
部署完zabbix后，有时候会发现zabbix服务器的时间明明是对的，但是图标的时间不对，通过以下的配置可以快速解决。
zabbix企业应用之监控oracle
weixin_33885676的博客
06-30 320
本次介绍如何使用zabbix监控oracle，主要使用pyora这个python脚本来监控，具体地址可以参考https://github.com/bicofino/Pyora 我的zabbix版本为2.0.6，oracle为11g下面是部分效果图1、Oracle/Active user count2、Oracle/Bytes sent and received via SQL*Net to Cli...
【网络监控与管理】：使用Nagios和Zabbix，掌握网络的脉搏
随后，深入探讨了两大主流监控工具Nagios和Zabbix的安装、配置以及高级优化方法。同时，通过实践案例分析，展示了如何使用这些工具对网络设备、服务器和服务进行有效监控。本文还着重讨论了网络监控自动化的实践与...
运维攻城狮面试题汇总
tian1345的博客
05-22 2万+
面试题汇总 什么是运维?什么是游戏运维? 1）运维是指大型组织已经建立好的网络软硬件的维护，就是要保证业务的上线与运作的正常，在他运转的过程中，对他进行维护，他集合了网络、系统、数据库、开发、安全、监控于一身的技术，运维又包括很多种，有DBA运维、网站运维、虚拟化运维、监控运维、游戏运维等等 2）游戏运维又有分工，分为开发运维、应用运维（业务运维）和系统运维 开发运维：是给应用运维开发运维工具和运维平台的 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查 系
zabbix报错总结
zhanghengwei1995的博客
01-03 932
zabbix报错 https://www.cnblogs.com/losbyday/category/876878.html作者总结的很全棒 1.在启动zabbix-agent 时系统日志输出 PID file /run/zabbix/zabbix_agentd.pid not readable (yet?) after star zabbix-agent.service never wrote ...
zabbix监控系统时间的问题
weixin_34204057的博客
01-23 1685
分类： 监控 2013-03-19 21:40:11 发现zabbix监控系统时间的一个问题！zabbix监控系统时间用的key是system.localtime，返回当前的系统时间，而配置tigger报警时是用的fuzzytime(N)方法，该方法是将返回的系统时间与监控服务器的时间进行对比，如果大于N，则报警。这样的逻辑就存在两个问题：1.监控服务器并不一定是ntp服务器...
zabbix server is running | No.解决方法
热门推荐
极致，细节
05-27 4万+
登陆报错解决    zabbix server is running | No. 解决方法1 关闭selinux 永久关闭vi /etc/selinux/config #SELINUX=disabled #SELINUXTYPE=targeted 临时关闭 setenforce 0  关闭防火墙 永久关闭 chkconfig iptables off 临时生效 ipta
系统学习 Zabbix 系统监控（二）
weixin_54750412的博客
01-26 1220
本系列文章介绍了zabbix 基本概念及其特点，阐述 zabbix 系统环境搭建与基础安装，如何实现对各类操作系统、硬件设备、应用软件监控告警。本文为系列第二篇，内容包括Windows 系统硬件信息获取、Linux 系统监控、Linux 系统硬件信息获取。前文点此：系统学习 Zabbix 系统监控（一） 5 windows 系统硬件信息获取 本文通过在 OS 操作系统层面上，主要获取 windows 服务器下 CPU 信息、内存信息、硬盘信息、操作系统、服务器信息。信息获取的实现方式是通过在 windows
H3C交换机系统时间设置漏洞
weixin_30701575的博客
05-04 2121
H3C交换机系统时间设置存在漏洞 1. 背景说明 由于在编写《主机房网络延伸实施方案》，调试H3C S5120S-28P-EI交换机时，发现交换机设置成现在的时间后，导致本地用户通过ssh或者console口不能登录，只能通过重启机器才能再次登录。而交换机重启之后，交换机的时间统一重写写入系统时间为2000年。该时间肯定跟我们目前的时间不一致，不利于以后排查问题。 2. 排查导致不可登录造成...
Zabbix优化深信服AC的设备运行时间监控项
傻笑zz的博客
06-09 3774
前言 今天醒来通过微信，看到了客户环境的深信服上网行为管理（AC）在凌晨1点30左右发生了告警信息，说这台设备重启了。但通过设备的Web端查看设备的流量情况，是没有进行重启的。 微信告警信息： 排查思路： 一、查看设备中的流量信息 ###由于深信服的无线上网行为管理在Web端的管理界面上无法直观的看到设备的运行时间，现在我们查看有时间节点，可以反应出设备没有发生过重启的图 ###可以看到，在2019-12-19的凌晨1点30往后或者往前，流量都是有的，现在就可以确定是Zabbix监控项的问题了 二
zabbix监控系统平均负载的值和uptime的值出入很大
chenxun1522的博客
06-29 1000
"1 min average per core " 是每个core 的平均值，不是CPU 的平均值。 一个cpu可以有多个 core. grep proc /proc/cpuinfo发现为24core,找template 里的Item ,找到这个template "Template O...
zabbix默认自带模板检测cpu load和uptime不一致说明
08-28 745
zabbix默认自带模板检测cpu load和uptime不一致说明 发表评论 2,897 A+ 所属分类：监控 "1 min average per core "是每个core 的平均值，不是CPU 的平均值。 一个cpu可以有多个 c...
zabbix 不停重启问题
hxiang613的专栏
09-27 997
最近遇到了zabbix 一直自动重启（差不多十分钟重启一次）的问题。 查看日志： 初步判定是文件数打开过多，由此想到zabbix的配置参数StartPollers和StartPreprocessors 经测试：减小这两参数，隔了1小时，仍未自动重启。 后续仍需观察。 另外还有可能和数据库有关，可以适当增加数据库的max-connections ...
zabbix监控系统客户端安装
weixin_34194551的博客
08-17 153
下载http://www.zabbix.com/downloads/2.0.3/zabbix_agents_2.0.3.linux2_6.i386.tar.gzhttp://www.zabbix.com/documentation/2.0/manual/installation安装1)创建用户groupaddzabbixuseradd-gzabbixzabbix2)解...
如何解决zabbix监控交换机重启状态报警时间太短的问题
最新发布
10-27
<think>根据提供的引用，特别是引用[3]，提到交换机重启误报的原因是sysUpTime计数器溢出问题（最大计数时间为496天）。用户的问题是关于zabbix监控交换机重启状态报警时间太短，需要解决方法。 分析引用[3]中的信息：当sysUpTime计数器达到最大值（约496天）后会重新计数，导致zabbix误认为交换机重启而触发报警。这是因为zabbix默认的触发器可能设置为检测sysUpTime的突然大幅度减少（比如从一个大数变为0或很小的值），但溢出也会导致同样现象。 解决思路： 1. 延长触发器的检测时间窗口，避免因瞬时波动或计数器溢出而误报。 2. 针对计数器溢出的特殊情况，修改触发器表达式，排除计数器重置（即从高值变为0）的情况。 具体步骤： - 修改触发器的表达式，在检测到sysUpTime突然变小时，检查它是否是由于溢出（即当前值小于某个阈值且之前的值接近最大值）导致的。 - 或者，设置一个合理的阈值，比如当sysUpTime从大于一个阈值（例如400天）突然变为小于100秒，才认为是重启，这样可以避免计数器重置导致的误报。 参考引用[4]中的触发器表达式写法，我们可以设计一个触发器表达式，例如： ``` {交换机:system.sysUpTime.last()} < 86400 and {交换机:system.sysUpTime.last(1h)} > 4147200000 ``` 解释： - `system.sysUpTime`的单位是0.01秒，所以86400秒（1天）对应的值是8640000（单位0.01秒）。 - 4147200000（0.01秒）约等于496天（最大值），这里取一个接近最大值的数（比如400天对应的值为3456000000，但为了保险可以取比496天小一点的值）。 - 表达式含义：当当前sysUpTime小于1天，并且1小时前的sysUpTime大于400天（或其他设定的接近最大值的阈值）时，才触发报警。这样可以避免计数器溢出导致的误报。 然而，由于计数器溢出后重新从0开始，所以1小时前的值我们无法获取（因为当前值已经重置），所以上述表达式可能需要调整时间点。另一种方式是使用`delta`函数计算变化量，但要注意溢出会导致变化量为负且绝对值很大。 更严谨的方法是： ``` {交换机:system.sysUpTime.change()} < -8640000 ``` 但是这样同样会捕获到溢出（因为溢出会导致change为一个很大的负数）。因此，我们需要排除溢出情况，即当变化量小于一个很大的负数（比如-400天的值）时，不触发报警。 所以综合解决方案： 1. 创建两个触发器： a. 触发器1：检测sysUpTime的减少量超过阈值（比如1天对应的值8640000）且当前值不为0（避免刚启动时误报）。 b. 触发器2：排除计数器溢出的情况（即变化量小于一个很大的负数，比如-400天对应的负数）。 但这样可能复杂，我们可以用一个表达式同时处理： 改进的触发器表达式： ``` {交换机:system.sysUpTime.change()} < 0 and ({交换机:system.sysUpTime.last()} < 86400 and {交换机:system.sysUpTime.nodata(60s)}=0) and abs({交换机:system.sysUpTime.change()}) < 4147200000 ``` 解释： - `change() < 0`：sysUpTime减少了（可能是重启或溢出重置）。 - `last() < 86400`：当前sysUpTime小于1天（8640000*0.01秒=86400秒）。 - `nodata(60s)=0`：确保数据是新的（60秒内没有数据则忽略）。 - `abs(change()) < 4147200000`：变化量的绝对值小于最大可能值（这里取接近最大值，比如400天对应的3456000000，但用4147200000更接近496天最大值），这样排除计数器溢出（因为溢出的变化量是一个接近最大值的负数，其绝对值会大于这个阈值）。 但注意：计数器溢出时，变化量是`当前值（0或很小） - 之前值（接近最大值）`，所以变化量会是一个接近负最大值的数，其绝对值很大。而正常重启的变化量绝对值相对较小（比如从几周到0）。 因此，我们可以设置一个阈值，比如变化量的绝对值大于400天对应的值（3456000000）时，认为是计数器溢出，不报警；只有变化量的绝对值小于这个阈值且为负数时，才认为是重启。 最终表达式： ``` {交换机:system.sysUpTime.change()} < 0 and abs({交换机:system.sysUpTime.change()}) < 3456000000 and {交换机:system.sysUpTime.last()} < 86400 ``` 说明： - 变化量为负（表明时间减少）。 - 变化量的绝对值小于400天对应的值（3456000000，单位0.01秒），这样排除计数器溢出（因为溢出时变化量绝对值会大于400天的值）。 - 当前sysUpTime小于1天（8640000*0.01秒=86400秒=1天），确保是最近重启。 注意：400天（3456000000）这个阈值可以根据实际情况调整，建议小于最大值的80%左右。 另外，引用[3]中提到的问题是误报，所以我们实际上要避免误报，因此这个触发器表达式应该能够有效区分重启和计数器溢出。 步骤总结： 1. 登录Zabbix Web界面，找到监控交换机的触发器。 2. 修改触发器的表达式为上述表达式（需要根据实际监控项名称调整）。 3. 可以设置触发器的告警级别和通知方式。 此外，如果交换机确实在496天左右溢出，可以建议定期重启交换机以避免溢出（但这不是最佳实践）。 相关问题： 1. 如何监控交换机的其他指标（如端口状态、带宽等）？ 2. Zabbix监控中如何处理其他类似的计数器溢出问题？ 3. 如何优化Zabbix触发器的表达式以减少误报？ </think>### 解决Zabbix监控交换机重启状态报警时间太短问题的方法 根据引用[3]的分析，Zabbix误报交换机重启的根本原因是 **SNMP的`sysUpTime`计数器溢出问题**。这是一个32位计数器，单位是1/100秒，最大计时约496天（$497.1 \text{天} = 2^{32}/100/86400$）。当计数器溢出归零时，Zabbix会误判为设备重启。以下是解决方案： #### 解决步骤 1. **修改触发器逻辑**（核心方案） 在触发器表达式中添加**时间窗口判断**，避免瞬时变化误报： ```plaintext {交换机:system.sysUpTime.change(0)} < 0 and {交换机:system.sysUpTime.last(0)} < 86400 // 小于1天视为重启 ``` - `change(0) < 0` 检测时间戳减小（重启特征） - `last(0) < 86400` 确保当前运行时间小于1天（86400秒） - **优化点**：将`86400`调整为实际业务允许的最小重启时间（如$3600$秒=1小时） 2. **忽略计数器溢出事件** 通过表达式排除计数器归零的误报： ```plaintext ({交换机:system.sysUpTime.change(0)} < -3456000000) // 400天阈值 and ({交换机:system.sysUpTime.last(0)} > 0) ``` - `-3456000000` 对应400天（$400 \times 86400 \times 100$），当时间跳跃超过此值时判定为溢出而非重启[^3] 3. **增加延迟报警机制** 在触发器设置中启用 **"问题生成延迟"**： ```mermaid graph LR A[检测到sysUpTime变化] --> B{延迟60秒} B -- 变化持续 --> C[触发报警] B -- 变化恢复 --> D[取消报警] ``` - 通过`zabbix_agentd.conf`配置：`Timeout=30` 延长检测超时时间[^2] #### 验证方法 1. 模拟测试： ```bash # 强制修改sysUpTime（测试用） snmpset -v2c -c community 交换机IP sysUpTime.0 = 0 ``` 2. 观察Zabbix日志： ```log tail -f /var/log/zabbix/zabbix_server.log | grep "resolved" ``` > **注意**：对于接近496天的设备，建议定期重启交换机或升级固件（部分厂商提供64位计数器固件）规避溢出问题[^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值