Hallo zusammen,
ich habe ein Update von der Version 2.0.0p20 auf die Version 2.0.0p22 gemacht.
Anschließend bekomme ich bei meinen MPLS Routern folgende Meldung:
[snmp] Success, Missing monitoring data for check plugins: cisco_cpu_multiitemWARN , execution time 0.0 sec
Ist das ein Problem meiner Konfiguration oder stimmt etwas mit dem neuen Patch nicht?
LG
Lars
Ich denke mal hier hat dieses Werk zugeschlagen.
Findet er bei dir nun gar keine CPU Checks mehr oder nur den MultiItem nicht mehr?
Scheinbar sind nur die MultiItem betroffen.
Naja ist aber so wie ich meine. Es gibt gar keine CPU Checks mehr.
Ich hab mir mal das Werk dazu angeschaut und die Beschreibung im Werk ist einfach mal falsch.
Begründung im Werk
Before this change a Service <tt>CPU utilization 0</tt> was created, although
the corresponding MIB describes that <tt>0</tt> for cpmCPUTotalPhysicalIndex
indicates that this element is not supported.
Those Services will no longer be discovered.
Und völlig gegensätzlich die Beschreibung von Cisco.
The entPhysicalIndex of the physical entity for which the CPU statistics in this
entry are maintained. The physical entity can be a CPU chip, a group of CPUs,
a CPU card etc. The exact type of this entity is described by its
entPhysicalVendorType value. If the CPU statistics in this entry correspond to
more than one physical entity (or to no physical entity), or if the entPhysicalTable
is not supported on the SNMP agent, the value of this object must be zero.
Wie man aus dem Cisco Text lesen kann ist dieser Wert völlig normal manchmal 0. Nicht wie im Werk Text steht - “wenn 0 dann is nix”. Es kann nur die Ausnahme sein, dass hier 0 steht und wirklich nix da ist.
Meiner Meinung nach ein Fall von “kaputt repariert”.
Danke für die Analyse und die klare Aussage!
Gleiches Bild hier mit einer kleinen Cisco 8xx unter IOS 15.9.x: vorher “CPU utilization 0” mit sinnvollen Werten, mit p22 vanished.
Einfacher Workaround erstmal
~/share/check_mk/checks/cisco_cpu_multiitem
nach
~/local/share/check_mk/checks/cisco_cpu_multiitem
kopieren und die folgenden Zeilen einfach löschen. Sollten Zeile 26 bis 29 sein.
# if cpmCPUTotalPhysicalIndex is 0, the element is not supported
# (see CISCO-PROCESS-MIB.txt)
if idx == "0":
continue
Danach müsste alles wie i.O. sein.
36 bis 39, ansonsten perfekt 
(Wobei es bei mir eh nur um ein kleines Test-Setup geht und ich die lokale Anpassung wieder rausgenommen habe, sonst vergess ich das nur bis zum nächsten Update 
)
Das mit den Anpassungen wäre mal was für ein MKP welches man “Hotfix MKP Version pXY” nennt und einfach bei nächsten Update dann deinstalliert. 
Achtung nach dem besagten Patch kam noch was dazu - der Check sieht in der Release Version ja noch anders aus wie nach dem kaputten Patch 
Beim besagten Patch waren das noch Zeile 26 bis 29
Die jetzige Release Version hat niemand getestet würde ich sagen.
In der aktuellen Release Version sieht der Code wie folgt aus.
# if cpmCPUTotalPhysicalIndex is 0, the element is not supported
# (see CISCO-PROCESS-MIB.txt)
if idx == "0" or entity.physical_class != PhysicalClasses.cpu:
continue
try:
dort einfach das idx == "0" entfernen und gut is
# if cpmCPUTotalPhysicalIndex is 0, the element is not supported
# (see CISCO-PROCESS-MIB.txt)
if entity.physical_class != PhysicalClasses.cpu:
continue
try:
Die letzte Änderung mit der PhysicalClass macht ja durchaus Sinn im Gegensatz zu der davor.
Auch an das Deinstallieren muss man ja erstmal drandenken … ob ich das schaffe?
In diesem Fall würde ich die Änderung sogar bewusst direkt in der ausgelieferten Version machen (also ausnahmsweise nicht unter ~/local), weil
Hmm, nein, damit fliegt in meinem Test-Setup die “CPU utilization 0” leider wieder ganz raus.
Ok dann ist das mit der “PhysicalClass” auch nicht so toll. Hab mir schon überlegt, dass die Physical Class überhaupt nicht gesetzt sein muss.
Damit erhärtet sich mein Verdacht, dass die Änderungen überhaupt nicht mit Live Daten oder bestehenden SNMPwalks getestet wurden.
Guten Tag zusammen!
Danke erstmal fürs Reporting.
bzgl. PhysicalIndex == 0
Es macht auch Sinn was ihr beschreibt. Hier haben wir die MIB falsch interpretiert.
bzgl. PhysicalClasses.
Hier gab es den Fall dass ohne dem Fix ziemlich viel “Quark” discovered wurde (CPU utilization FAN, CPU utilization Chassis…) - daher die Einführung der Filterung. @martin.schwarz kannst du das bestätigen, dass die PhysicalClass bei dir nicht gesetzt ist? Die OID wäre die .1.3.6.1.2.1.47.1.1.1.1.5
Grüße
Timi
Danke fürs Kümmern! Ein “snmpget -v2c -c COMMUNITY HOST .1.3.6.1.2.1.47.1.1.1.1.5” liefert:
iso.3.6.1.2.1.47.1.1.1.1.5 = No Such Instance currently exists at this OID
Ich kann @martin.schwarz’s Aussage bestätigen. Die PhysicalClass muss nicht vorhanden sein. Auch laut MIB von Cisco. In der Abfrage wäre wichtig wenn PhysicalClass vorhanden ist dann kann die überprüft werden. Wenn diese gar nicht vorhanden ist dann auch nicht prüfen.
Würde für mich Sinn ergeben.
@Timi die Beschriftung “FAN” usw. dürfte nur überhaupt auftauchen wenn auch eine PhyiscalClass vorhanden ist. Ansonsten sind das nur Nummern.
Hallo zusammen
Wenn ich mich nicht taeusche, dann werden MKPs deaktiviert waehrend man ein 2.x update
einspielt. “Gedankenstuetze” by design…
Auf einer meiner aktuellen sites (allerdings noch auf 1.6), gibt es zwei Cisco ASA die ich damit ueberwache. Deren “CPU utilization” wird vom plugin cisco_cpu_multiitem ermittelt. Besagte OID, ist bei diesen zwei ASA, ebenfalls nicht vorhanden.
Gruesse,
Thomas
@martin.schwarz Ich hab das Thema nochmal mit meinem Kollegen durchgesprochen und hätte eine kleine Bitte: hast du für uns eventuell doch einen vollständigen Walk des Gerätes? Wir müssen dort vermutlich etwas mehr umbauen.
Gerne, schicke ich dir per direkter Nachricht.
Wir haben uns das zusammen mit @andreas-doehler noch mal etwas genauer angeschaut, und hoffen dass das folgende MKP das Problem lösen sollte.
Es wäre uns eine große Hilfe, wenn es die Betroffenen testen könnten:
cisco_cpu_multiitem-0.0.1.mkp (1.9 KB)
Allerdings scheint es so, als ob auch vor der 2.0.0p22 unter bestimmten Bedingungen zu wenige CPU-Services discovered wurden. Der Fix führt dazu, dass die CPU-Services neu discovered werden müssen, da sich der Name des Services ändert (0 → 1 (oder auf eine andere Nummer)).
Läuft seit ein paar Stunden Problemlos bei uns (Catalyst 3850 Stack)
Sieht bei mir ebenfalls gut aus – es wird eine “CPU utilization 1” (statt bisher 0) neu erkannt.
Auch grad in ner größeren Installation probiert. Schaut gut aus.
Nix verschwunden von den bisherigen. Rediscovery ist auch nur bei bisher Index 0 erforderlich alle anderen bleiben wie gehabt bei den gleichen Index Nummern.