标签:
问题源自于最近监控的一个告警,根据我们之前对SysUpTime进行监控的策略,启动时间为0时,需要发送设备重启的告警通知,之前我们是对网管说明过这个问题的。网管同意监控,是因为有时候网络设备重启很快,但是还是会对业务系统产生影响。
现在,换了一个新的网管,对此表示质疑:
我登陆设备看到时间是
uptime is 213 weeks, 0 day, 7 hours, 49 minutes
服务器设置的计时器有问题?
随后进行解释,对方表示:
不能监控到正确的启动时间,就不如不监控了。
其实对于工作来说,在当前环境中这种结果很好呀,毕竟:
- 我们提供的信息网管不接受;
- 网管自己也不会提供更加准确的数据;
产生这种问题的根源就是,H3C、Cisco提供的工具太好用啦,除了某些对我们来说比较致命的问题:
- 贵;
- 还是贵;
所以,我们的Admin养成了下面的习惯:
- 有好工具就用;
- 没好工具就凑合着;
- 不愿意研究;
当然,一个企业,有钻研的人还是有的,就是——太TMD少了点。
吐槽结束,转入正题。
在RFC 1907的第2.1节中定义如下:
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
“The time (in hundredths of a second) since the network management portion of the system was last re-initialized.”
::= { system 3 }
首先,是一个只读的时间计数器,其次,记录了设备上次初始化后的运行时间,以百分之一秒为单位,也就是10毫秒。
再次,目前多数设备使用的都是32位的计数器,也就是:
2 ^ 32 = 4294967296 * 10 毫秒 = 497.1 天
上面的计算也就是说明使用32位计数器,每隔497.1天会重置一次。
搜索了很久,发现没有地方是记录那个计数器的重置次数——但是为什么管理端(自带的网络管理软件)就能够正常获取这些数据呢?应该还是有记录的。
为了尽快解决问题,只能曲线救国了:
{Network:sysUpTime.last(0)}<120 and {Network:sysUpTime.max(#10)}< 42949036
标签:
原文地址:http://my.oschina.net/rexkang/blog/418573