Intro
Unlike your home PC, critical security servers basically never just restart on their own. But today I got a Zabbix notification that indeed one of ours had done just that. I set out to investigate to learn the root cause and prevent it from recurring. things took a weird turn at some point.
The details
I asked my colleague to investigate the server, He dutifully looked at various logs. There didn’t seem to be anything amiss according to the logs. Then he showed me a screenshot of the CLI prompt. It had been up for 497 days and some hours. So there was no restart.
We speculated that maybe just the ASM module had restarted, but without any real evidence.
System uptime is an SNMP MIB which we monitor in Zabbix.
The graph of this uptime looks like this:

What is the Zabbix trigger expression for this problem? it is:
change(/f5host/snmp.agent[F5-BIGIP-SYSTEM-MIB::sysSystemUptime.0])<0
In words, if the uptime, a linearly increasing value over time, becomes suddenly smaller, then the change from the previous value is negative and it is assumed that signifies a restart.
Then I remembered another way to satisfy that condition. Consider this python math:
>>> 86400*497 42940800 >>> 2**32 4294967296
The first few digits of those two different calculations agree, right? Let me back up. A day has 3600*24 = 86400 seconds. What I’m getting at is that if you assume the uptime units in this MIB are hundredths of a second, then the two numbers become basically the same.
So what happened is that this counter filled up after 497 days and rolled over! So there was no restart after all.
Conclusion
A Zabbix-reported F5 restart on an F5 BIG-IP which had been up for more than 497 days was shown to be a false positive and explained as an artifact of the finite size of the SNMP counter, which rolled over to 0.
Case closed!