30. 03. 2017
NetEye, Unified Monitoring
30. 03. 2017
Patrick Zambelli
Nagios Plugins, NetEye
SAP Monitoring: Erfahrungen mit SAPControl und check_SAP_health
In SAP Systemen werden Business-Abläufe abgebildet, welche für die Organisation von großer Wichtigkeit sind. Daher entstehen besondere Anforderungen an das Monitoring. Nicht nur die Infrastruktur dieser Systeme soll überwacht werden, sondern auch Applikationsschichten, Jobabläufe und -abbrüche. Wo sammeln sich Probleme an, welche sich in Form von verlangsamten Jobs, fehlerhaften Dokumenten oder Verbuchungsabbrüchen ansammeln und sich im Laufe der Zeit zu konkreten Zwischenfällen führen können?
Werden solche Anzeichen nicht frühzeitig erkannt, erfolgt reaktives Monitoring – der Kunde bzw. der Endanwender meldet sich! Um solche Situationen zu vermeiden, haben Herr Andreas Förster und ich bei einem unserer Kunden einen Workshop zum Thema SAP Monitoring organisiert. Während des eintägigen Workshops wurde in einem ersten Teil die Systemarchitektur von SAP erläutert und erklärt welche Ansätze des Monitorings auf den Ebenen der Server und den darüberliegenden Applikationsschichten bestehen. Im zweiten, praktischen Teil wurde das Monitoring samt notwendiger vorbereitender Maßnahmen umgesetzt. In diesem Artikel möchte ich einige der Monitoring-Ansätze für SAP näher beleuchten und Einsatzszenarien des SAP Monitorings mit NetEye aufzeigen:
- SAP-externes Monitoring: Systeminstanzen und Prozesse prüfen mit “SAPControl”
- SAP-internes Monitoring: CCMS Alert Monitor zur Abfrage von Laufzeitdaten, Ressourcenverwendung und Jobabläufen
SAP-externes Monitoring: Systeminstanzen und Prozess prüfen mit “SAPControl”
Dieser Ansatz zielt auf das Monitoring im Applicaton Layer ab. Prinzipiell ist es möglich über dieses Tool Instanzen zu starten und zu stoppen, Prüfungen der Laufzeitumgebung zu machen oder das Systemlog auszulesen. Die Anfragen basieren auf SOAP WebServices und können mittels HTTP, aber auch mit Zertifikat-gesichertem HTTPS gemacht werden.
Die Konfiguration von ACLs ( Access Lists ) auf SAP-Seite, erlaubt die Kontrolle der Monitoring-Systeme, welche Zugang erhalten sollen. Mit diesem Ansatz wird kein Login am SAP-System gemacht.
Anwendungsfälle für ein SAP-externes Monitoring können beispielsweise Abfragen zur Version der Kernel der SAP Instanzen sein. Dadurch kann nach dem Ausrollen von Updates sichergestellt werden, dass alle Systeme auf der gleichen Version betrieben werden. Eine weitere, häufige Fehlerquelle ist das Ablaufen der Zertifikate, aber auch das kann über diesen Weg überwacht werden.
Die für das Monitoring zugelassenen SAPControl Webservices sollten über den SAP-Profilparameter „service/protectedwebmethods“ eingeschränkt werden, z.B. folgendermaßen:
service/protectedwebmethods = SDEFAULT -GetVersionInfo -GetAlertTree -GetAlerts -EnqGetStatistic -GetQueueStatistic -GetInstanceProperties -GetSystemInstanceList -ReadLogFile -ListLogFiles -AnalyseLogFiles -ABAPReadSyslog -ABAPGetComponentList
Details hierzu finden Sie im SAP-Hinweis “1439348 – Erweiterte Sicherheitseinstellungen für sapstartsrv”. Vorbereitung der Monitoring-Infrastruktur: Es wird das SAPEXE benötigt, welches am Kundenportal von SAP bezogen werden kann. Aus dem SAPEXE werden schließlich das SAPControl und die benötigten Bibliotheken ( Libraries ) extrahiert.
# ./SAPCAR -xvf SAPEXE_400-20012215.SAR sapcontrol libicuuc.so.50 libicudata.so.50 libicui18n.so
Hinweis: Die Versionen und Abhängigkeiten können sich in den verschiedenen Versionen unterscheiden.
Sind das SAPControl und die Bibliotheken bereit, kann noch die “LD_LIBRARY_PATH” mittels export LD_LIBRARY_PATH=/opt/sap/lib mitgeteilt und der Aufruf gemacht werden. Hier werden der SAP-Host, die Systemnummer und die aufzurufende Funktion benötigt. Ein erster Schritt könnte hier die Abfrage der Systemversion sein.
./sapcontrol -nr 01 -host sap.mydomain.lan -prot NI_HTTP -function GetVersionInfo 15.11.2016 10:10:06 GetVersionInfo OK Filename, VersionInfo, Time /usr/sap/SID/DVEBMGS15/exe/sapstartsrv, 742, patch 223, changelist 1614561, RKS compatibility level 0, optU (Oct 2 2015, 19:45:59), rs6000_64, 2015 10 02 20:56:11 /usr/sap/SID/DVEBMGS15/exe/disp+work, 742, patch 223, changelist 1614561, RKS compatibility level 0, optU (Oct 2 2015, 19:45:59), rs6000_64, 2015 10 03 00:25:54 /usr/sap/SID/DVEBMGS15/exe/gwrd, 742, patch 223, changelist 1614561, RKS compatibility level 0, optU (Oct 2 2015, 19:45:59), rs6000_64, 2015 10 02 19:56:49 ...
Weitere Möglichkeiten sind die Abfrage der laufenden Prozesse, der Auslastung des Arbeitsspeichers oder der Einträge der Sperrtabelle.
./sapcontrol -nr 01 -host sap.mydomain.lan -prot NI_HTTP -function GetProcessList 15.11.2016 10:12:06 GetProcessList OK name, description, dispstatus, textstatus, starttime, elapsedtime, pid disp+work, Dispatcher, GREEN, Running, 2016 10 16 17:56:50, 67:52:08, 9242666 igswd_mt, IGS Watchdog, GREEN, Running, 2016 10 16 17:56:50, 67:52:08, 4522234 gwrd, Gateway, GREEN, Running, 2016 10 16 17:56:52, 67:52:06, 20251724 icman, ICM, GREEN, Running, 2016 10 16 17:56:52, 67:52:06, 17107024
SAP-internes Monitoring: CCMS Alert Monitor zur Abfrage von Laufzeitdaten, Ressourcenverwendung und Jobabläufen
Die Auswertung von Job-Laufzeiten oder verfügbaren RFC-Verbindungen wird hingegen über die SAP-interne Betrachtungsweise gemacht. Hierzu werden SAP-Monitoring-Metriken ausgelesen, welche bereits standardmäßig von SAP gesammelt werden. Diese Metriken werden vom Computing Center Management System (CCMS) gesammelt und via RFC Anfrage ausgelesen.
In dieser Ausführung werden die Anfragen direkt an den CCMS-Dienst auf der SAP-Instanz gerichtet. Damit ist eine aufwendige Konfiguration einer zentralen Solution Manager Architektur, wie z.B. einem Landscape Virtualization Management (LVM), nicht notwendig. Ein weiterer Vorteil einer solchen dezentralen Abfrage-Architektur besteht in der direkten Verwaltung der SAP-Monitore innerhalb der SAP-Instanz. Gleichzeitig werden auch die Wege zur Abfrage verschlankt, da Informationen direkt auf den Systemen abgegriffen werden, auf welchen sie entstehen und ein “single point of failure” vermieden.
Hinweis zur Konfiguration: Für die Konfiguration der Zugriffsberechtigungen ist es vorzuziehen, den User für NetEye im “000” Mandanten anzulegen. Der Mandant “000” gibt Einsicht auf alle Informationen zum SAP-System. Wobei hier keine Benutzer- und Kundendaten abgelegt sind.
Das Auslesen der Metriken via CCMS kann mittels check_sap_health gemacht werden. Check_sap_health wird als Community Projekt entwickelt (https://labs.consol.de/nagios/check_sap_health/) und bietet eine Vielzahl an Abfragemethoden.
Aufruf von check_sap_health
Diese Aufruf verbindet sich mittels User mit dem SAP-System, wodurch ein gültiger User mit Zugangsdaten für das System und dem Mandanten angelegt werden muss. Damit die Konfiguration vereinfacht wird, haben wir ein Wrapper-Script dazwischen geklemmt, welches diese Daten aus einer Konfigurationsdatei im System liest. Dadurch ist nur die Angabe der SID notwendig. Daten zu Mandant, SystemNr, Username und Password werden aus der Konfigurationsdatei gelesen.
cat /etc/nagios/neteye/sap/nag_sap.cfg SID SYSNR MANDANT SAP-USER PASSWORD
Sind die Zugangsdaten und das wrapper-script “check_sap_health_run.sh” hinterlegt, kann mit “–mode connection-time” ein erster Verbindungsaufbau getestet werden. Ist dieser erfolgreich, kann mit der sehr praktischen Methode “list-ccms-monitors” die Baumstruktur der verfügbaren Monitore ausgelesen werden.
./check_sap_health_run.sh --mode list-ccms-monitors --r3name SID SAP CCMS Monitor Templates Availability and Performance Overview Background Processing Buffers Change Transport System Communications Data Archiving Database Dialog Overview Dialog per Application Server Enqueue Entire System Filesystems J2EE Applications J2EE Engine Operating System Performance Overview Process Integration Remote Databases
Eine exemplarische Ansicht der CCMS Monitore im RZ20-Modul:
Nun kann mit Argument “name2” eine weitere Vertiefung ausgelesen werden: “list-ccms-mtes” erlaubt z.B. das Auslesen der Monitore im Bereich “Performance Overview”:
./check_sap_health_run.sh --r3name SID --mode=list-ccms-mtes --name "SAP CCMS Monitor Templates" --name2 "Performance Overview" SID_appsap01_SID_10_CPU_CPU_Utilization 100 SID_appsap01_SID_10_CPU_Utilization 100 SID_appsap01_SID_10_Dialog_DBRequestTime 100 SID_appsap01_SID_10_Dialog_Load+GenTime 100 SID_appsap01_SID_10_Dialog_QueueTime 100 SID_appsap01_SID_10_Dialog_ResponseTime 100 SID_appsap01_SID_10_Dialog_UsersLoggedIn 100 SID_appsap01_SID_10_Paging_Page_In 100 SID_appsap01_SID_10_Paging_Page_Out 100 SID_appsap01_SID_10_Program_Swap 100 SID_appsap01_SID_10_R3MemMgmtResources_EsAct 100 SID_appsap01_SID_10_R3MemMgmtResources_HeapAct 100 SID_appsap01_SID_10_R3RollPaging_R3RollUsed 100 _Dialog 199 _Memory Management 199 _Operating System 199 _Performance Overview 199 _SID\app01_SID_10 199 OK
Hier wiederum kann mit “name3” ein spezifischer Monitor ausgelesen und mit Schwellwerten belegt werden. Als Mode wird nun “ccms-mte-check” verwendet:
./check_sap_health_run.sh --ashost sap.mydomain.lan --r3name SID --mode=ccms-mte-check --name "SAP CCMS Monitor Templates" --name2 "Performance Overview" --name3 "SID_appsap01_SID_10_CPU_Utilization" OK - CPU Utilization = 0% | 'CPU_Utilization'=0%;90;98;0;100
In diesem Beispiel wird nun auch der vom CCMS mitgelieferte Schwellwert überschrieben:
./check_sap_health_run.sh --ashost sap.mydomain.lan --r3name SID --mode=ccms-mte-check --name "SAP CCMS Monitor Templates" --name2 "Performance Overview" --name3 "SID_appsap01_SID_10_CPU_Utilization" --warning 80 --critical 90 OK - CPU Utilization = 0% | 'CPU_Utilization'=0%;80;90;0;100
Durch den kompakten Wissenstransfer während dieses praxisnahen Workshops konnten die Teilnehmer im weiteren Verlauf den Ausbau des Monitorings auf weitere Bereiche im SAP-Umfeld autonom vornehmen.
Abschließend blicke ich auf einen produktiven Tag zurück und kann diese Iniziative allen empfehlen, die sich mit der Umsetzung eines effizienten Monitorings im SAP-Umfeld befassen möchten. Für weitere Informationen können Sie uns gerne unverbindlich kontaktieren: neteye@wuerth-phoenix.com
Patrick Zambelli
Project Manager at Würth Phoenix
After my graduation in Applied Computer Science at the Free University of Bolzano I decided to start my professional career outside the province. With a bit of good timing and good luck I went into the booming IT-Dept. of Geox in the shoe district of Montebelluna, where I realized how a big IT infrastructure has to grow and adapt to quickly changing requirements. During this experience I had also the nice possibility to travel the world, while setting up the various production and retail areas of this company. Arrived at Würth Phoenix I started developing on our monitoring solution NetEye. Today, in my position as Consulting an Project Manager I am continuously heading to implement our solutions to meet the expectation of your enterprise customers.
Author
Latest posts by Patrick Zambelli
16. 01. 2024
NetEye, Unified Monitoring
Icinga 2 DSL for Defining the Monitoring Status of Objects with Director
23. 12. 2020
NetEye
Tornado – Getting in Action with Sample Rules
05. 05. 2020
NetEye, Unified Monitoring
Import Data Correlation and Automation with Icinga2 Director