[Check_mk (deutsch)] Bug: SNMP OID für die Uptime - zumindest bei Linux basierenden Systemen

Andreas Döhler andreas.doehler at gmail.com
Di Sep 1 10:05:39 CEST 2015


Hallo Jakub,

in deinen Auszügen stehts doch so wie von Matthias beschrieben drin.
Die "wahre" Uptime ist unter 1.3.6.1.2.1.25.1.1.0 zu finden
und 1.3.6.1.2.1.1.3 zeigt nur die Uptime der Netzwerkdienste respektive des
SNMPD an.
Wie gesagt man müsste beim prüfen welche OID verfügbar ist und je nachdem
den einen oder anderen Check inventarisieren.

Bei Geräten welche nur 1.3.6.1.2.1.1.3 kennen mag das ja anders sein nur
betrifft dieses Verhalten mittlerweile alle Linux basierten Appliances /
Server.

Namensvorschlag wegen hr MIB wäre hier sowas wie hr_uptime für den Check :)
Die Scan Function in snmp_uptime muss hier noch extra prüfen das
1.3.6.1.2.1.25.1.1.0
nix enthält und alles wäre wieder gut.

Gruß
Andreas

Tusz, Jakub <Jakub.Tusz at kvv.karlsruhe.de> schrieb am Di., 1. Sep. 2015 um
09:46 Uhr:

> Laut Standard:
>
> *hrSystemUptime* OBJECT-TYPE
>
>
>
> -- 1.3.6.1.2.1.25.1.1.0
> -- iso(1). org(3). dod(6). internet(1). mgmt(2). mib-2(1). host(25).
> hrSystem(1). hrSystemUptime(1). 0
>
>
>
> SYNTAX
>
> TimeTicks
>
>
>
>
>
> MAX-ACCESS
>
> *read-only*
>
>
>
>
>
> DESCRIPTION
>
>
>
>
>
>
>
> "The amount of time since this host was last
> initialized. Note that this is different from
> sysUpTime in the SNMPv2-MIB [RFC1907] because
> sysUpTime is the uptime of the network management
> portion of the system."
>
> *::= { hrSystem 1  }*
>
>
>
> Bzw. sysUpTime (erst in SNMP v2!)
>
>
>
> *sysUpTime* OBJECT-TYPE
>
>
>
> -- 1.3.6.1.2.1.1.3
> -- iso(1). org(3). dod(6). internet(1). mgmt(2). mib-2(1). system(1).
> sysUpTime(3)
>
>
>
> SYNTAX
>
> TimeTicks
>
>
>
>
>
> MAX-ACCESS
>
> *read-only*
>
>
>
>
>
> DESCRIPTION
>
>
>
>
>
>
>
> "The time (in hundredths of a second) since the network
> management portion of the system was last re-initialized."
>
> *::= { system 3  }*
>
>
>
> Also liegt das Problem eher an der Implementation in den betroffenen
> Systemen.
>
>
>
>
> Mit freundlichen Grüßen
>
> i.A. Jakub Tusz
> ---------------------------------------------------------------------------------------------------------------------------
>
> Jakub Tusz
> Abt.: V5-IT - Verwaltung | Informationstechnologie
>
> VBK - Verkehrsbetriebe Karlsruhe GmbH
> Tullastraße 71, D-76131 Karlsruhe
> Postfach 1140, D-76001 Karlsruhe
>
>
> Telefon:
> Fax:
> E-Mail:
>
>
> +49(721)6107 5905
> +49(721)6107 5909
> jakub.tusz at vbk.karlsruhe.de
>
>
> Kfm. Geschäftsführer: Dr. Alexander Pischon, Techn. Geschäftsführer: Ascan
> Egerer
> Vorsitzender des Aufsichtsrates: Oberbürgermeister Dr. Frank Mentrup
> Amtsgericht Mannheim HRB 107847
> ---------------------------------------------------------------------------------------------------------------------------
>
>
>
>
>
> *Von:* checkmk-de-bounces at lists.mathias-kettner.de [mailto:
> checkmk-de-bounces at lists.mathias-kettner.de] *Im Auftrag von *
> andreas.doehler at gmail.com
> *Gesendet:* Montag, 31. August 2015 21:40
> *An:* Matthias Henze; checkmk-de at lists.mathias-kettner.de
>
>
> *Betreff:* Re: [Check_mk (deutsch)] Bug: SNMP OID für die Uptime -
> zumindest bei Linux basierenden Systemen
>
>
>
> Hallo Matthias,
>
>
>
> hatte das an irgendeinem Gerät auch schon mal "gefunden" bin aber auch auf
> das Problem gestoßen das viele SNMP Geräte nur diesen Wert für
>
> Uptime liefern und sonst nix.
>
>
>
> Mann könnte maximal einen zweiten Uptime Check schreiben und diesen ja
> nach Hosttag zuweisen oder ignorieren lassen.
>
> Ich denke mal ein guter Ansatz wäre bei der Überprüfung der
> Systemdescription OID nach Linux basierten Systemen zu schauen und dann den
> alternativen
>
> Check zu inventarisieren. Normale Netzwerkgeräte sollten damit unberührt
> vom Check bleiben.
>
>
>
> Wie sehen das die restlichen Profis hier - wäre doch über die
> Systemdescription OID / Inhalt derer machbar?
>
>
>
> Gruß
>
> Andreas
>
>
>
> Gesendet von Mail <http://go.microsoft.com/fwlink/?LinkId=550986> für
> Windows 10
>
>
>
>
>
>
> *Von: *Matthias Henze
> *Gesendet: *Montag, 31. August 2015 20:31
> *An: *checkmk-de at lists.mathias-kettner.de
> *Betreff: *Re: [Check_mk (deutsch)]Bug: SNMP OID für die Uptime -
> zumindest bei Linux basierenden Systemen
>
>
>
>
>
> Kleine Korrektur/Nachtrag:
>
>
>
> Die OID für die Systemuptime ist: .1.3.6.1.2.1.25.1.1.0 was aber
>
> iso.3.6.1.2.1.25.1.1.0 entspricht und nichts am Problem ändert.
>
>
>
>
>
> Am 31.08.2015 um 20:18 schrieb Matthias Henze:
>
> > Hallo,
>
> >
>
> > ich pflege die Uptime meiner Systeme zu monitoren und es gibt "critical"
>
> > wenn ein System weniger lange als 2 Stunden läuft. Ausserdem habe ich
>
> > immer mal mit nicht all zu stabilen SNMPDs zu tun und ich bin gezwungen
>
> > diese täglich neu zu starten, damit sie mir nach 3 Tagen nicht ganz den
>
> > Geist aufgeben. Diesem Umstand ist es zu verdanken, dass ich auf eine
>
> > falsch verendete OID gestossen bin. CMK verwendet für die Uptime die OID
>
> > "1.3.6.1.2.1.1.3.0". Diese gibt aber nicht, wie man annehmen könnte über
>
> > die Laufzeit des Systems sondern über die Laufzeit des SNMPD Auskunft.
>
> > Bei meinen Problemsystemen ist die aber nicht die selbe. Die korrekte
>
> > OID für die Laufzeit des Systems ist die "iso.3.6.1.2.1.25.1.1.0". Hier
>
> > ein Beispiel:
>
> >
>
> > # snmpwalk -v 2c -c public gw .1.3.6.1.2.1.1.3.0
>
> > iso.3.6.1.2.1.1.3.0 = Timeticks: (346620) 0:57:46.20
>
> >
>
> > # snmpwalk -v 2c -c public gw iso.3.6.1.2.1.25.1.1.0
>
> > iso.3.6.1.2.1.25.1.1.0 = Timeticks: (27133912) 3 days, 3:22:19.12
>
> >
>
> > Eben ist mir das wieder mal ins Auge gesprungen, da einen neu
>
> > Linux-Appliance von sich aus den SNMPD alle 6 Stunden neu startet und
>
> > ich mich über die Uptime gewundert habe.
>
> >
>
> > Konkret habe ich das Problem bei Synology Diskstations und Securepoint
>
> > Firewalls. Beides Linux basierend. Man könnte noch überlegen, ob das
>
> > nicht vielleicht eher ein Bug des SNMPD und nicht von CMK ist.
>
> >
>
> > Dumm dabei ist, dass z.B. Cisco-Switche die OID "iso.3.6.1.2.1.25.1.1.0"
>
> > nicht kennen sondern nur bei der "1.3.6.1.2.1.1.3.0" einen Wert liefern.
>
> > Im Moment habe ich keine Idee wie sich das in CMK fixen liesse.
>
> >
>
> > cheers
>
> > Matthias
>
> >
>
> >
>
>
>
>
>
>
>
> --
>
>
>
> MHC SoftWare GmbH
>
> Fichtera 17
>
> 96274 Itzgrund/Germany
>
>
>
> voice: +49-(0)9533-92006-0
>
> fax: +49-(0)9533-92006-6
>
> e-mail: info at mhcsoftware.de
>
>
>
> HR Coburg: B2242
>
> Geschäftsführer: Matthias Henze
>
>
>
>
>
>
>
> _______________________________________________
>
> checkmk-de mailing list
>
> checkmk-de at lists.mathias-kettner.de
>
> http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de
>
>
>
> Wir treffen uns zur 2. Check_MK-Konferenz in München!
>
> Rechtzeitig buchen und dabei sein!
>
> 18.-20. Oktober 2015
>
> http://mathias-kettner.de/conference
>
>
>
>
>
> ------------------------------
> Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen
> enthalten. Wenn Sie nicht der richtige Adressat sind, so bitten wir Sie,
> sofort den Absender zu informieren und diese E-Mail vollständig zu löschen.
> Das unerlaubte Kopieren, Weiterleiten, Verbreiten oder Verwenden dieser
> E-Mail und deren Inhalte ist nicht gestattet.
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.mathias-kettner.de/pipermail/checkmk-de/attachments/20150901/ee332d3e/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : image001.jpg
Dateityp    : image/jpeg
Dateigröße  : 5889 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.mathias-kettner.de/pipermail/checkmk-de/attachments/20150901/ee332d3e/attachment.jpg>


Mehr Informationen über die Mailingliste checkmk-de