Is there any plan to fix this in Checkmk and have SNMP uptime handled properly? One solution could involve calculating whether the uptime exactly matches the old one when you add exactly 2^32
hundredths of seconds (any number of times since the problem comes back after 994 days and so on) and if so, assume that it didn’t reboot? There would be the rare corner case where a system reboots exactly (to the hundredth of a second) at that same value but statistically speaking that would still be much better than resetting the counter like it does currently (tested in 1.6 but I didn’t see any werk regarding that in 2.0).
The only solution would be to create an new uptime check what uses the OID 1.3.6.1.6.3.10.2.1.3.0
I would not recommend to modify the existing check. Write a new one using this OID.
Or with the 2.0 plugin model you can also create an overwrite for the old uptime check if the OID is found on a device.
Thank you, didn’t know SNMP had a fix of their own. Still would appreciate some sort of setting for older devices that can’t be updated to avoid the false alarm every once in a while.
And maybe OID 1.3.6.1.6.3.10.2.1.3.0 could be used by default for uptime when available… I’m no expert with SNMP and pretty much just use the default configuration Checkmk provides (but I’ll learn).
This is not possible. If your device doesn’t know the mentioned OID for the new check you cannot see if the device is rolled over or not. Also in your linked article from the PRTG knowledge base they say you must stay with the current behavoir.
That’s what i mean with my overwrite statement. In 2.0 it is possible to have a check superseeding another check if the data is available.
I’m wondering, to replace the current check, can I just create /opt/omd/sites/home/local/lib/nagios/plugins/check_uptime? I tried that and made it executable but it doesn’t seem like Checkmk is using the script at all. In fact, even if I delete say /opt/omd/versions/<version>/lib/nagios/plugins/check_uptime, that still doesn’t change anything at all. I noticed in /opt/omd/sites/home/etc/nagios/conf.d/check_mk_objects.cfg that check_mk-uptime is used for pretty much any host (SNMP or agent).
I also spotted /opt/omd/versions/<version>/lib/python3/cmk/base/plugins/agent_based/snmp_uptime.py.
I installed the package which created /opt/omd/sites/<site>/local/lib/python3/cmk/base/plugins/agent_based/snmp_uptime.py. It didn’t change the uptime value of my modern managed Netgear switch however (still showing uptime of 9 days while it should be 506 days). It’s as if 1.3.6.1.2.1.1.3.0 was still prioritized over 1.3.6.1.6.3.10.2.1.3.0.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Copyright (C) 2019 tribe29 GmbH - License: GNU General Public License v2
# This file is part of Checkmk (https://checkmk.com). It is subject to the terms and
# conditions defined in the file COPYING, which is part of this source code package.
# 2022-03-06: extended to use snmpEngineTime if available
# snmpEngineTime : The number of seconds since the value of the snmpEngineBoots object last changed. When
# incrementing this object's value would cause it to exceed its maximum, snmpEngineBoots is
# incremented as if a re-initialization had occurred, and this object's value consequently
# reverts to zero.
# snmpEngineBoots: The number of times that the SNMP engine has (re-)initialized itself since snmpEngineID was
# last configured. On Cisco Device this gives the number of reboots
#
from typing import Optional
from cmk.base.plugins.agent_based.agent_based_api.v1 import exists, register, SNMPTree
from cmk.base.plugins.agent_based.agent_based_api.v1.type_defs import StringTable
from cmk.base.plugins.agent_based.utils import uptime
def parse_snmp_uptime(string_table: StringTable) -> Optional[uptime.Section]:
"""
>>> parse_snmp_uptime([['2297331594', '']])
Section(uptime_sec=22973315, message=None)
>>> parse_snmp_uptime([['124:21:26:42.03', '124:21:29:01.14']])
Section(uptime_sec=10790941, message=None)
>>> None is parse_snmp_uptime([[u'', u'Fortigate 80C']]) # nonsense
True
"""
if not string_table:
return None
sysUpTime, hrSystemUptime, snmpEngineTime = string_table[0]
ticks = sysUpTime or hrSystemUptime
if len(ticks) < 3:
return None
try:
return uptime.Section(int(snmpEngineTime), None)
except ValueError:
pass
# try:
# return uptime.Section(int(ticks[:-2]), None)
# except ValueError:
# pass
# try:
# days, h, m, s = ticks.split(":")
# return uptime.Section(
# (int(days) * 86400) + (int(h) * 3600) + (int(m) * 60) + int(float(s)),
# None,
# )
# except ValueError:
# pass
return None
register.snmp_section(
name="snmp_uptime",
parsed_section_name="uptime",
parse_function=parse_snmp_uptime,
fetch=SNMPTree(
base=".1.3.6.1",
oids=[
# On Linux appliances: .1.3.6.1.2.1.1.3.0 means uptime of snmpd
# .1.3.6.1.2.1.25.1.1.0 means system uptime
"2.1.1.3", # DISMAN-EVENT-MIB::sysUpTime
"2.1.25.1.1", # HOST-RESOURCES-MIB::hrSystemUptime
"6.3.10.2.1.3", # SNMP-FRAMEWORK-MIB::snmpEngineTime
],
),
detect=exists(".1.3.6.1.2.1.1.1.0"),
)
OMD[home]:~$ snmpget -v2c -c public 10.1.1.2 1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (86551404) 10 days, 0:25:14.04
OMD[home]:~$ snmpget -v2c -c public 10.1.1.2 1.3.6.1.2.1.25.1.1.0
SNMPv2-SMI::mib-2.25.1.1.0 = No Such Object available on this agent at this OID
OMD[home]:~$ snmpget -v2c -c public 10.1.1.2 1.3.6.1.6.3.10.2.1.3.0
SNMPv2-SMI::snmpModules.10.2.1.3.0 = No Such Object available on this agent at this OID
I’m surprised modern networking components don’t have this. Are there separate OIDs for SNMPv3 or is it all the same? SNMPv3 is supported on my switch.
Here is additionally a list of supported MIBs by my switch:
Name Description
DIFFSERV-DSCP-TC The Textual Conventions defined in this module should be used whenever a Differentiated Services Code Point is used in a MIB.
DNS-SERVER-MIB The MIB module for entities implementing the server side of the Domain Name System (DNS) protocol.
HC-RMON-MIB The original version of this MIB, published as RFC3273.
IANA-ADDRESS-FAMILY-NUMBERS-MIB The MIB module defines the AddressFamilyNumbers textual convention.
IANAifType-MIB This MIB module defines the IANAifType Textual Convention
LAG-MIB The Link Aggregation module for managing IEEE 802.3ad
LLDP-EXT-MED-MIB The LLDP Management Information Base extension module for TIA-TR41.4 Media Endpoint Discovery information.
MAU-MIB Management information for 802.3 MAUs.
NETGEAR-BOXSERVICES-PRIVATE-MIB The NETGEAR Private MIB for NETGEAR Box Services Feature.
NETGEAR-DHCPCLIENT-PRIVATE-MIB The NETGEAR Private MIB for NETGEAR DHCP Client
NETGEAR-G8032-MIB The NETGEAR Private MIB for NETGEAR G8032
NETGEAR-INVENTORY-MIB Unit and Slot configuration.
NETGEAR-LOGGING-MIB This MIB provides objects to configure and display events logged on this system.
NETGEAR-MGMT-SECURITY-MIB The NETGEAR Private MIB for NETGEAR Mgmt Security
NETGEAR-POWER-ETHERNET-MIB NETGEAR Power Ethernet Extensions MIB
NETGEAR-QOS-AUTOVOIP-MIB NETGEAR Flex QOS VOIP
NETGEAR-QOS-DIFFSERV-PRIVATE-MIB NETGEAR Flex QOS DiffServ Private MIBs' definitions
NETGEAR-RADIUS-AUTH-CLIENT-MIB The NETGEAR Private MIB for NETGEAR Radius Authentication Client.
NETGEAR-SNTP-CLIENT-MIB Defines NETGEAR Corporation enterprise OID pertaining to SNTP client configuration and statistical collection.
NETGEAR-TIMERANGE-MIB The NETGEAR Private MIB for NETGEAR Time Ranges
POWER-ETHERNET-MIB Power Ethernet MIB
RADIUS-AUTH-CLIENT-MIB RADIUS Authentication Client MIB
RFC 1493 - BRIDGE-MIB Definitions of Managed Objects for Bridges (dot1d)
RFC 2674 - P-BRIDGE-MIB The Bridge MIB Extension module for managing Priority and Multicast Filtering, defined by IEEE 802.1D-1998.
RFC 2737 - ENTITY-MIB Entity MIB (Version 2)
RFC 2863 - IF-MIB The Interfaces Group MIB using SMIv2
SMON-MIB The MIB module for managing remote monitoring device implementations for Switched Networks
SNMP-FRAMEWORK-MIB The SNMP Management Architecture MIB
SNMP-NOTIFICATION-MIB The Notification MIB Module
SNMP-USER-BASED-SM-MIB The management information definitions for the SNMP User-based Security Model.
SR-AGENT-INFO-MIB SNMP Research, Inc.
I updated to the latest firmware released in 2021 just in case with no luck. I intend to keep the plugin going anyways for my other SNMP devices, I think it’s good in general to use 1.3.6.1.6.3.10.2.1.3.0 if available.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
