Hallo @all,
Das Plugin " “mk_sap” funktioniert nur sauber mit Python2
Es kann nicht mit Python3 gestartet werden. Auch das kompilieren der NWRFC Librarys mit Python3 (hier bei mir mit 3.6 getestet) schlägt fehl.
Schon jemand mit Python3 zum laufen gebracht?
Danke
Hallo,
vielleicht läuft ja diese Version aus dem github-Repository mit Python 3:
https://github.com/tribe29/checkmk/blob/master/agents/plugins/mk_sap
Ich denke es ist auch ein Problem, es wird die uralte sapnwrfc-0.19.tar.gz aus https://github.com/piersharding/python-sapnwrfc verwendet (von Anfang 2012).
Eventuell muss hier auch mal etwas Arbeit rein fließen um das Python 3 kompatibel zu machen. Weil wir haben immer mehr Linux Systeme die einfach kein Python 2 mehr haben und haben sollen, wenn Python dann 3.
Hat vielleicht hier schon jemand das mk_sap auf das PyRFC von SAP selbst umgebaut? Wäre natürlich noch besser.
Interessant zu lesen, dass es doch Nutzer gibt, die mk_sap mit dem sapnwrfc-0.19 zum Laufen gebracht haben und damit SAP überwachen.
Neben den geschilderten Problemen wg Python3 ist v.a. der Punkt zu nennen, dass das mk_sap auf CCMS von SAP aufsetzt, was eigentl seit Jahren nicht mehr weiterentwickelt wird. Problematisch ist auch, dass Knoten aus der RZ20 (via CCMS) unserer Erfahrung nach regelmäßig nicht abfragbar waren und es zu vielen Fehlalarmen kommen kann.
Vieles, aber leider nicht alles, kann (oder: sollte?) man eher mit sapcontrol abfragen.
In der Tat wäre hier eine Monitoring-Lösung (bzw. ein Plugin) für SAP etwas sehr vorteilhaftes und wünscheswertes - Frage bzgl. SAP-Monitoring mit checkmk werden zwar regelm im Forum gepostet, scheinen aber leider keinen besonders hohen Stellenwert zu haben.
Wir nutzen das auch nur für die rudimentäre Notfallüberwachung und das funktioniert auch Problemlos und ohne Fehlalarme. Die RZ20 ist zwar alt und seit jahren von der SAP abgekündigt, funktioniert aber Problemlos wenn man weiß was man macht.
Das richtige Monitoring für SAP läuft sowieso über den SAP Solution Manager. Aber auch der hat eben mal Wartung und Ausfallzeiten in denen man eben etwas rudimentäres braucht.
Darf ich fragen von welchen Hausnummern wir in deinem Fall reden? Also, wie viele SolMan und wie viele daran angebundene SAP Systeme?
Ich höre nur immer wieder, dass die Pflege und Konfiguration im SolMan sehr aufwändig und intensiv sein soll?
Im Moment werden ca. 80 ABAP Systeme direkt via CheckMK abgefragt, hinzu kommt natürlich noch der Rest drumherum (router, oracle, hana etc.).
Außerdem noch einige SolMans.
Die Initiale Einrichtung ist Aufwendig ja, aber sobald man seine Templates mal gebaut hat ists OK.
Das check_mk ist wie gesagt nur der Notfall.
Tatsächlich habe ich das ganze gestern auf pyrfc (2.4.0) umgeschrieben, da wir letzte Woche auf CheckMK 2.0.0p3 migriert haben mit python3.
Ich schau mal, dass ich es dir die Tage zur Verfügung stellen kann.
Das wäre super wenn sie das hochladen können. Eventuell direkt bei GitHub (GitHub - tribe29/checkmk: Checkmk - Best-in-class infrastructure & application monitoring) einreichen? Ich denke schon das vielen mit einer aktuellen Version für PyRFC geholfen wäre.
Hi Stefan,
habe bei uns seit kurzem den gleichen Aufbau mit Python3 und CheckMK2.
Würde mich sehr für deine Lösung interessieren.
Aktuell läuft es noch auf sapnwrfc-0.19 auf einen alten Server den ich gerne abbauen würde.
Viele Grüße
Hi Zusammen,
habs nun mal im github hochgeladen: checkmk/mk_sap.py at master · stefan7018/checkmk · GitHub
getestet auf einem RHEL8 mit pyrfc (2.1.0 und 2.4.0) und SAP nwrfc750P_8-70002752.
Ich hab auch einen Pullrequest bei tribe29 aufgemacht, vielleicht wird es ja gemerged. 
Viele Grüße,
Stefan
Danke sehr
Erfolgreich getestet auf Ubuntu 20.04 mit pyrfc 2.4.0 und 750P_8-70002752
Auch hier nochmal Danke, getestet inzwischen auch mit nwrfc750P_8-70002752, dem aktuellen pyrfc 2.4.0 und 2.4.2 auf SLES 12 SP5 und SLES 15 SP2
Zur Info, mittlerweile auch auf Ubuntu 20.04.3 LTS mit nwrfc750P_9-70002752 und pyrfc-2.5.0.tar.gz erfolgreich getestet.
Jetzt stellt sich aber die Frage ob das nicht mal vom Check_MK Team (also @tribe29) aufgegriffen und in den Standard überführt wird. Weil aktuell das ausgelieferte Paket immer noch Python2 haben möchte und das ist einfach nicht mehr machbar.
Außerdem sollten ein Paar Themen angepasst werden:
Danke und Grüße