Nach Update auf 2.4 ist der geänderte pse_poe verschwunden

Hallo,
pse_poe lieferte für Dell Switche zu hohe Werte, da der Switch Milliwatt ausgibt. Daher wurde (mit eurer Hilfe) der Check nach ~/local/share/check_mk/checks/ kopiert und angepasst.
Nach dem Update auf 2.4 waren die Werte wieder zu hoch. Die geänderte Datei war jetzt aber aus ~/local/share/check_mk/checks/ verschwunden. Ich habe sie dann wieder dort rein kopiert, aber offensichtlich wird dieser check nicht mehr genutzt - zumindest sind die Werte noch immer zu hoch.
Woran kann das liegen?

Gruß Wolfgang

Hallo Wolfgang,

die Pfade für Check-Plugins haben sich geändert: Siehe What’s new in the agent-based Check API v2 | Checkmk

Ich kläre gerne am Freitag mal ab, wie man vorhandene Checks am einfachsten forken kann, wahrscheinlich läuft es auf eine simple Änderung des eindeutigen Namens hinaus, SMTP-Checks abonnieren ja keine Agentensektion.

Ist denn bekannt, welche exakten Switches diese falschen/anderen Einheiten reporten (wir gehen ja meist von SI aus, haben aber schon alles gesehen), dann können wir ggf. im Check selbst differenzieren und eine Korrekturfunktion anbringen.

1 Like

Hallo Matthias,
das sind - zumindest bei uns - Switche von Dell. Das Modell N1108EP-ON und N1548P.
Danke für den Link - werde versuchen, mich da mal einzulesen, wenn ich die Zeit finde.
Gruß
Wolfgang

Hallo Matthias,
ich komme damit leider nicht klar.
Das pse_poe war ein generischer Check, der bereits im Check_MK integriert war. Andreas Döhler hatte mir (und anderen mit dem gleichen Problem) den Hinweis gegeben, den Check im Script selbst durch eine Division durch 1000 zu ergänzen. Dies hatte für uns perfekt funktioniert, da wir ausschließlich Switche mit diesem Problem im Einsatz haben.
Ich dachte jetzt eigentlich, dass es genügen würde, diesen Check wieder im System zu lokalisieren und die Division wieder einzubauen.
Andreas hatte dann etwas später auch eine generellere Anpassung vorgestellt:
Check_mk-pse_poe wrong vaues - Troubleshooting - Checkmk Community
Leider finde ich diesen Check aber nicht mehr bei der 2.4.

Der “pse_poe” Check für die 2.4 befindet sich im Verzeichnis “~/lib/check_mk/plugins/collection/agent_based/”
Die Datei “pse_poe.py” kann dann nach “~/local/lib/check_mk/plugins/collection/agent_based/” kopiert werden (wenn nicht vorhanden muss man halt die Pfade anlegen).
Dort dann die Änderung wie bisher durchführen und sollte tun.

“~/local/lib/check_mk/plugins/” sollte es wenigstens geben der Rest des Pfades muss noch erstellt werden.

1 Like

Hier mal ein find als root:

root@shomon01:~# find / -name "pse_poe*"
/omd/versions/2.3.0p6.cee/lib/python3/cmk/plugins/collection/checkman/pse_poe
/omd/versions/2.3.0p6.cee/share/check_mk/checks/pse_poe
/omd/versions/2.4.0.cee/lib/python3/cmk/plugins/collection/agent_based/pse_poe.py
/omd/versions/2.4.0.cee/lib/python3/cmk/plugins/collection/agent_based/__pycache__/pse_poe.cpython-312.pyc
/omd/versions/2.4.0.cee/lib/python3/cmk/plugins/collection/checkman/pse_poe
/omd/sites/SHO/local/lib/python3/cmk/plugins/collection/agent_based/pse_poe.py
/omd/sites/SHO/local/lib/python3/cmk/plugins/collection/agent_based/__pycache__/pse_poe.cpython-312.pyc
/omd/sites/SHO/local/lib/python3/cmk/base/plugins/agent_based/pse_poe
/omd/sites/SHO_old/var/check_mk/precompiled_checks/local/pse_poe
/omd/sites/SHO_old/local/share/check_mk/checks/pse_poe
/omd/sites/SHO_old1/local/share/check_mk/checks/pse_poe
root@shomon01:~#

Hatte die Datei umkopiert und die 2 Zeilen mit " / 1000" ergänzt.
Jetzt bekomme ich nach einem Servicediscovery POE als vanished und er findet keine neuen POE Werte mehr.

unter keinen Umständen als root arbeiten bei sowas.

Nach einer Änderung an solchen Dateien sollte man immer auf der Shell testen mittels “cmk --debug -vvn HOSTNAME” ob die Änderung irgendwas kaputt gemacht hat.

Das war nur für den find-Befehl :wink:
cmk --debug … lief ohne Fehler. Das sind die letzten Zeilen:

Write data to cache file /omd/sites/SHO/tmp/check_mk/data_source_cache/snmp/checking/SHOVT3SW1
Trying to acquire lock on /omd/sites/SHO/tmp/check_mk/data_source_cache/snmp/checking/SHOVT3SW1
Got lock on /omd/sites/SHO/tmp/check_mk/data_source_cache/snmp/checking/SHOVT3SW1
Releasing lock on /omd/sites/SHO/tmp/check_mk/data_source_cache/snmp/checking/SHOVT3SW1
Released lock on /omd/sites/SHO/tmp/check_mk/data_source_cache/snmp/checking/SHOVT3SW1
[cpu_tracking] Stop [7f5b38b95010 - Snapshot(process=posix.times_result(user=0.06000000000000005, system=0.010000000000000009, children_user=0.0, children_system=0.0, elapsed=244.40000000223517))]
[cpu_tracking] Start [7f5b38f390d0]
+ PARSE FETCHER RESULTS
  HostKey(hostname='SHOVT3SW1', source_type=<SourceType.HOST: 1>)  -> Add sections: ['dell_powerconnect_fans', 'dell_powerconnect_psu', 'if64', 'snmp_info', 'snmp_uptime']
Received no piggyback data
Interface 210        [Link Aggregate 1], (up), MAC: 20:04:0F:5A:A3:1E, Speed: 10 GBit/s, In: 518 kB/s (0.04%), Out: 122 kB/s (<0.01%)
Interface Uplink     [Unit: 1 Slot: 0 Port: 4 10G - Level], (up), MAC: 20:04:0F:5A:A3:1E, Speed: 10 GBit/s, In: 518 kB/s (0.04%), Out: 122 kB/s (<0.01%)
SNMP Info            Dell EMC Networking N1548P, 6.5.3.4, Linux 3.6.5, Not Available, SHOVT3, 
Sensor Fan 1         Condition of FAN "Fan 1" is normal
Sensor Fan 2         Condition of FAN "Fan 2" is normal
Sensor Main          Condition is normal, with source Alternating Current
Sensor System        Condition is normal, with source Alternating Current
Uptime               Up since 2024-06-08 10:16:09, Uptime: 359 days 4 hours
[cpu_tracking] Stop [7f5b38f390d0 - Snapshot(process=posix.times_result(user=0.010000000000000009, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.009999997913837433))]
[snmp] Success, execution time 244.4 sec | execution_time=244.410 user_time=0.070 system_time=0.010 children_user_time=0.000 children_system_time=0.000 cmk_time_snmp=244.330

Jetzt ist mir das noch aufgefallen. Vermutlich war vorher die Anzeige nicht aktualisiert:


Irgendetwas kann da wohl nicht interpretiert werden.

Da ist kein pse_poe Check mehr dabei.
Wenn du für den Host ein “cmk --debug -vvII HOSTNAME” machst solltest entweder wieder einen pse_poe Check finden oder einen Crash erhalten.

  • zu spät gelesen deinen Post :slight_smile:
    Hier wäre nun der Crash wichtig

Jetzt ist die Ausgabe leer:

OMD[SHO]:~$ cmk --debug -vvll SHOVT3SW1

OMD[SHO]:~$

Dafür wird POE1 wieder angezeigt.

Das sind zwei große i keine l’s :wink:

Das gibt immerhin eine Ausgabe :wink:

[cpu_tracking] Stop [7f092c48e360 - Snapshot(process=posix.times_result(user=0.1499999999999999, system=0.07, children_user=0.0, children_system=0.0, elapsed=1.9400000013411045))]
+ PARSE FETCHER RESULTS
  HostKey(hostname='SHOVT3SW1', source_type=<SourceType.HOST: 1>)  -> Add sections: ['dell_om_disks', 'dell_om_esmlog', 'dell_om_fans', 'dell_om_mem', 'dell_om_power', 'dell_om_processors', 'dell_om_sensors', 'dell_powerconnect_cpu', 'dell_powerconnect_fans', 'dell_powerconnect_psu', 'dell_powerconnect_temp', 'if', 'if64', 'inv_if', 'pse_poe', 'snmp_extended_info', 'snmp_info', 'snmp_uptime', 'ucd_cpu_load', 'ucd_cpu_util', 'ucd_disk', 'ucd_diskio', 'ucd_mem', 'ucd_processes']
Received no piggyback data
+ ANALYSE DISCOVERED HOST LABELS
Trying host label discovery with: dell_om_disks, dell_om_fans, dell_om_mem, dell_om_power, dell_om_processors, dell_om_sensors, dell_powerconnect_fans, dell_powerconnect_psu, if64, inv_if, pse_poe, snmp_extended_info, snmp_info, snmp_uptime, ucd_cpu_util, ucd_disk, ucd_diskio, ucd_mem, ucd_processes
Trying host label discovery with:
SUCCESS - Found no host labels
+ ANALYSE DISCOVERED SERVICES
+ EXECUTING DISCOVERY PLUGINS (19)
  Trying discovery with: dell_om_power_unit, ucd_cpu_util, dell_om_mem, ucd_processes, docker_container_status_uptime, snmp_info, ucd_mem, dell_om_disks, dell_om_processors, ucd_diskio, dell_powerconnect_psu, dell_om_sensors, uptime, dell_powerconnect_fans, dell_om_power, if64, pse_poe, ucd_disk, dell_om_fans
  2 dell_powerconnect_fans
  2 dell_powerconnect_psu
119 if64
  1 pse_poe
  1 snmp_info
  1 uptime
SUCCESS - Found 126 services
OMD[SHO]:~$

Da hier kein Fehler kommt - was macht nun das “cmk --debug -vvn HOSTNAME”?

Falls hier auch kein Fehler kommt dann einfach noch ein “cmk -R” und schauen obs im Web auch ohne Fehler angezeigt wird.

Jetzt kommt wieder der POE Wert, wenn auch noch nicht korrekt.
image

Im py-script habe ich (wie bei der 2.3) in den 2 Zeilen ein “/ 1000” eingefügt.

    poe_dict = {}
    for oid_end, poe_max, pse_op_status, poe_used in string_table:
        if not poe_max or not pse_op_status or not poe_used:
            continue
        poe_dict[str(oid_end)] = PoeValues(
            poe_max=int(poe_max) / 1000,
            poe_used=int(poe_used) / 1000,
            poe_status=PoeStatus(int(pse_op_status)),
            poe_status_detail=None,
        )
    return poe_dict

Dann hilft nur debugging auf der Command Line.
Meine damit 1-2 print Statements in der geänderten Datei und dann wieder “cmk --debug -vvn HOSTNAME” um zu schauen was bei den Print Statements so ausgegeben wird. Entweder ist was falsch im Code oder irgend was anderes hängt.

Das ist jetzt sehr seltsam. Offenbar ist nur der Wert von poe_used in Milliwatt, also durch 1000 zu teilen. Der Wert von poe_max scheint tatsächlich in Watt ausgelesen zu werden.
Noch seltsamer ist aber, dass bei der 2.3 beide Werte den Teiler 1000 benötigt haben.
Kann es sein, dass bei der 2.4 ev. andere OIDs verwendet werden?

    poe_dict = {}
    for oid_end, poe_max, pse_op_status, poe_used in string_table:
        if not poe_max or not pse_op_status or not poe_used:
            continue
        poe_dict[str(oid_end)] = PoeValues(
#            poe_max=int(poe_max) / 1000,
#            poe_used=int(poe_used) / 1000,
            poe_max=int(poe_max),
            poe_used=int(poe_used) / 1000,
            poe_status=PoeStatus(int(pse_op_status)),
            poe_status_detail=None,
        )
    return poe_dict

image

Glaub ich eher nicht - siehst aber innerhalb des Checks dort stehen ja die OIDs.