Absurde Rückgabewerte beim Plugin apc_symmetra

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen,


    vielleicht hat hier jemand eine Idee...


    Ich habe vor einigen Tagen auf einen neuen Server umgestellt (Debian 8 mit OMD Consol Labs Edition). Laut Webseite habe ich jetzt die Check_MK Version 1.2.6p12 (RAW). Weiterhin läuft noch der "alte" Server (Debian 7) mit der gleichen Version.


    Wir haben jetzt 6 USVen, von denen 4 einen absurden Wert liefern:


    Battery current: 1000000000 A (crit at 1 A)


    Ich habe für eine USV auch mal die Dienste neu inventarisieren lassen. Kurzzeitig fiel der Wert dann auf 13 V, ging dann aber wieder auf den extrem hohen Wert hoch.


    Interessanterweise wird für alle 6 USVen auf dem "alten" Server angezeigt "bat. curr. 0 A".


    Hat jemand so was schon mal gesehen?


    Bis denn


    Thomas

  • Was ich noch vergessen habe: auf dem alten Server habe ich die Umgebung über main.mk konfiguriert; auf der neuen Umgebung über WATO.


    Jetzt haben auf dem "neuen" Server alle USVen bis auf Eine diesen hohen Wert. Diese USV wird aber per SNMPv1 abgefragt.

  • Was auffällt:


    Output of check plugin: [...] Battery current: 1000000000 A (crit at 1 A) [...]


    Service Metrics: [...] Battery electrical current:1000 MA [...]


    Service performance data (source code): [...] batcurr=1000000000 [...]


  • Danke erst mal für den Tipp. Kurzfristig (direkt nach einer Re-Inventarisierung) sah es mal gut aus. Leider hielt das nicht lange. Was mich eben auch stutzig macht: auf beiden Servern ist eigentlich die gleiche Check_MK-Version. Mich wundert, dass auf dem "alten" Server alles gut aussieht.

  • Host löschen und (über WATO) neu anlegen bringt auch nichts. Was mich irritiert: dass es auf einem Server funktioniert und auf dem anderen Server nicht.

  • Was zeigt snmpget auf OID .1.3.6.1.4.1.318.1.1.1.2.2.9.0? (PowerNet-MIB::upsAdvBatteryCurrent).

    Versuche es mal mit SNMPv1 und SNMPv2c. Die Version 1 sorgt immer wieder für Probleme.

  • Eine 13. Verwirrt mich jetzt noch mehr;-)


    SNMPv1 hatte ich auch schon mal versucht: ohne Erfolg. Im Moment nutze ich (denke ich mal) v2c

  • Ich habe jetzt mal mit TCPDUMP mitgelauscht und für mich sieht es so aus als käme der hohe Wert von der Symmetra.


    Simple Network Management Protocol


    version: v2c (1)


    community: ***


    data: get-response (2)


    get-response


    request-id: 1955061195


    error-status: noError (0)


    error-index: 0


    variable-bindings: 10 items


    [...]
    1.3.6.1.4.1.318.1.1.1.2.2.9.0: 1000000000


    Object Name: 1.3.6.1.4.1.318.1.1.1.2.2.9.0 (iso.3.6.1.4.1.318.1.1.1.2.2.9.0)


    Value (Integer32): 1000000000

    [...]


    Frage ich den Wert aber mit dem iReasoning MIB Browser ab, bekomme ich eine 13 zurück...

  • Ich habe jetzt vom Linux-Server aus per snmpget die OID abgefragt. Liefert brav 13 zurück. Mache ich beim Cehck ein "Reschedule", sehe ich im Trace wieder als Wert 1000000000...