引子

問題源自於最近監控的一個告警，根據我們之前對SysUpTime進行監控的策略，啟動時間為0時，需要發送設備重啟的告警通知，之前我們是對網管說明過這個問題的。網管同意監控，是因為有時候網絡設備重啟很快，但是還是會對業務系統產生影響。

現在，換了一個新的網管，對此表示質疑：

我登陸設備看到時間是
uptime is 213 weeks, 0 day, 7 hours, 49 minutes
服務器設置的計時器有問題？

隨後進行解釋，對方表示：

不能監控到正確的啟動時間，就不如不監控了。

其實對於工作來說，在當前環境中這種結果很好呀，畢竟：
- 我們提供的信息網管不接受；
- 網管自己也不會提供更加准確的數據；

產生這種問題的根源就是，H3C、Cisco提供的工具太好用啦，除了某些對我們來說比較致命的問題：
- 貴；
- 還是貴；

所以，我們的Admin養成了下面的習慣：
- 有好工具就用；
- 沒好工具就湊合著；
- 不願意研究；

當然，一個企業，有鑽研的人還是有的，就是——太TMD少了點。

吐槽結束，轉入正題。

SysUpTime是啥

在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