ADM106 SYSTEM MONITORING USING CCMS I – zwischen den Zeilen

ADM106 SYSTEM MONITORING USING CCMS I


Dieser Artikel ist eine Zusammenfassung des Kursbesuches bei der SAP in Waldorf. Stand September 2011.
#Tag 1

1.    Grundlagen

1.1.        Einstieg

 

–       Grund für das Monitoring: Fürherkennung von Problemen, Problemanalyse, Verfügbarkeit, SLA-Überprüfung/Abgleich Soll-Ist

–       Outsourcingprobleme: Aussagen des Dienstleisters überfprüfen

–       4 Ebenen die überwacht werden wollen:

  1. Frontend: User
  2. Internetmiddleware: Java, TREX, Webserver
  3. CRM-Application: R/3
  4. Backends: OS, DB, PI

–       Problem: unterschiedliche Technologien, nicht wirklich kompatibel, eigene Monitoringsysteme

–       Ziel: Vereinheitlichung des Monitoring

–       Warum? Geschäftsprozesse sicherstellen, systemübergreifendes Monitoring, Alarmierungsmechanismen

–       CCMS ist Management und Basisaufgabe

–       Alle „RZ“-Transaktionen gehören zur CCMS Infrastruktur

–       Monitoring ist nur ein Teilbereich (Analyse, Alerting,…)

–       BPM ist SolutionManager Aufgabe, greift auf CCMS Abfragen zurück, daher ist ein sauberes CCMS nötig

–       Monitoring ist nur mit Alerting sinnvoll

–       Daher: Alertingkonzept erstellen aber: „Abstumpfung“ und „Überinformation“ vermeiden

1.2.        Architektur

 

–       CEN = zentrale Monitoringeinheit,keine SID, kein System, kann auf Solution Manager oder auf jedem ABAP-System laufen

–       Fremdsysteme  benötigen Agenten

–       Monitoring-Segment ist Teil der SAP-Infrastruktur und automatisch dabei

–       Non-SAP-Systeme (ohne ABAP Stack) haben kein Monitoring Segment, benötigen Agenten

1.3.        Shared Memory Bereich

–       Wird mit Datensammler gefüllt

–       Das Monitoring Segment ist immer lokal, die physikalische Abgrenzung ist der eigene Server, pro physikalische Maschine 1 Monitoring Segment, maximal so groß wie der vorhandene RAM, also auch Speicherüberwachen (Hardware: Checksum, Threshold), bei virtualisierten Maschinen zählt der dedizierte Bereich

–       Datensammler für das SAP-System auf Fremdsystem sind z.B. der SAPSCOL

–       1. Schritte: Alerting > Nachricht, Anlays, Auswertung durch 3d Party

–       Monitoring Objekte sind die zwingende Basis um SAP-Systeme zu monitoren „kleinstes gemeinsames vielfaches“

–       Es lasse sich ca. 200 Funktionen Monitoren

1.4.        Alert Monitor

 

–       Überblick der Komponenten in einer Baumstruktur

–       Alle Objekte gehören zur MTE

–       Attribut ist ein Unterteil eines Objektes

–       Attribute  liefern Daten, kann Farbstatus nach Richtwerten ausgeben

–       Objekt (oberhalb) hat die Farbe des „schlimmsten“ vorhandenen Status z.B. rot

1.5.        Shared Memory Bereich

2.    Basis

2.1.        Das Monitoring

 

–       Einstieg über RZ20, Ansicht ist immer lokal, Monitoring Sets sehen in jedem System anders aus

–       SAP Vorlagen sind gesperrt, read-only, dienen als Vorlagen, daher: eigene Monitoringset daher nicht mit „SAP…“ beginnen!, besser mit „Z_…“

–       Aufbau: Monitoring Set > Objekte > Attribut (liefert Werte) direkt aus dem Shared Memory des Applikation Servers

–       Kreuze im Kreis hinter einem Namen weisen darauf hin, dass der Knoten keine weitere Funktion hat – keinen Wert

–       Extras > Anzeigeoptionen um eigene Anzeigen zu definieren

  1. Refresh: Im Shared Memory Bereich werden alle 300 Sek. Geliefert, daher sind kleinere Intervalle nicht sinnvoll
  2. No / No refresh ist sinnvoll bei Dokumentationen (von Fehlern)
  3. Details – sind alle sinnvoll

–       Klick auf den Knoten + F1-Hilfe liefert  für jedes Objekt eine detaillierte Hilfe

–       Standardansicht zeigt immer „nur“ den aktuellen Wert, vorherige Werte lassen sich über [open alerts] anzeigen

–       Open-Alerts zeigt die offenen Alarmierungen inkl. der aktuellen Sicht

–       Markiertes Objekt + [display alerts] zeigt Alerts in einer Listübersicht (alle offenen), alle Ergebnisse aus dem Shared Memory Bereich

–       Fehler markiert + [complete Alerts] schließt Fehler ab und schreibt Fehler aus dem Shared Memory in die Datenbank in die Alerttabelle über [show alerts history] kann der Fehler wieder gefunden werden

–       Schwellenwertschutz: um einen Überlauf zu verhindern, werden die ältesten Alerts aus dem shared memory Bereich geschrieben (durch einen Job) und durch das System „auto completed“, daher: realistische Schwellwerte festlegen

–       Die Vorlagen „SAP CCMS Technical Expert Monitors“  Tipps:  „CCMS Selfmonitoring“

  1. Bereich Runtime: Aktuelle Alerts in der DB (max. 100 000), innerhalb von 24h werden die ältesten gelöscht

 

2.2.        Analyse

 

–       Doppelklick auf das Objekt springt zur Analyse oder zur Alarmierungsübersicht ab, wenn vorhanden

–       Standardansicht + „severity“ ist sinnvoll, severity = Eskalationswert + Priorität, Standard = 50, range 0 – 255

–       Parameter ändern: Objekt auswählen > Properties
wichtig! Administratoren müssen sich abstimmen, Schwellwerte müssen gemeinsam abgestimmt werden. Jedes Objekt gibt es nur einmal im Speicher und Änderungen gelten systemweit

  1. Severity (Priorität des Alerts)
    1. Range 0 – 255 (s.o.)
    2. Farbauswahl der oberen Ebenen richtet sich nach der Priorität
    3. In der Übersichtliste steht der Höchstpriorisierte oben

–       Bei einem Neustart des Systems sind alle Alerts weg, vor einem Neustart das Alert Display überschauen ggf. Alert sichern / exportieren

–        Deaktivieren:  Extras > Maintenance Modus >  Knoten auswählen > Edit > Nodes (MTE): „deactivate“

–       Oracle DB: BR-Connect muss vorhanden und gestartet sein. Attribut br-connect wird vom ABAP System überwacht. (Auch Berechtigungen prüfen) sonst werden keine Daten geliefert (Tabelspace etc.)

–       Windows/LINUX/HPUX: SAPOSCOLL (Dienst) muss laufen um OS-Daten zu liefern

–       MAXDB: Funktion übernimmt die DB50

–       Operating System Monitor:  „value is obsolete“ = Werte gab es mal, sind aber abgelaufen

–       Knoten: Views > „Status data collector“, zeigt den akutellen „IST-Wert“, Doppelklick startet den data collector manuell unter eigenem Benutzer  (sonst unter SAPSYS)

–       Syslog: „no value has yet been reported“ = noch keine Syslog geschrieben, sinnvoll:  „open alerts“ um die Historie zu sehen,

–       CCMS Self-monitoring ist wichtig

 

2.3.        Knoten

 

–       Perfomance Attribute Nodes: z.B. Antwortzeiten, Dialogzeiten

O Schwellwerte können angepasst werden

–       Status Attribute Nodes: z.B. SAPOSCOLL „läuft“ ja/nein

  1. Liefert eine Mitteilungsnummer zurück
  2. Keine Schwellwerte möglich, nur „möchte ich etwas wissen / nicht wissen
  3. Farbgebung möglich

–       Log Attribute Nodes:  z.B. komm eine/keine Meldung

  1. Wertet Inhalte aus
  2. Schwellwerte: wie lange zurück soll ausgewertet werden, wieviele Meldungen in der Liste sollen für die Meldung genutzt werden (die in den Alert mit einfließen)
  3. Prüft nicht in Echtzeit
  4. „last incoming message“ – nicht sinnvoll
  5. Tipp: Attribute wie vorgegeben bestehen lassen
  6. Filter: über IDs lassen sich Fehler priorisieren, „Filter schlägt Attribute“, kein Filter definiert -> Standard gilt
  7. Shared Memory Bereich muss vorhanden sein! Sonst ist nichts sichtbar. Fällt das shared memory Segment weg  dann steht das Alerting!

–       Virtual Nodes:  dienen zur Übersicht (mit dem Kreuz)

  1. Existieren nicht im shared memory, werden in der DB gehalten
  2. Dienen nur zur Visualisierung: keine Methode, Schwellenwerte, etc. möglich, können den Status der darunterliegenden Objekte annehmen
  3. Hilfreich um Strukturen aufzubauen

–       Information Attribut Nodes: z.B. Versionsnummer

  1. I-Symbol, Abfrage möglich, kein Status, dienen häufig anderen Reports zur Analyse (Oracel, Nagios. Skripte) z.B. Releaseinformationen, Datenbankstruktur,

–       DUMB wäre für ein Status Attribute Node

–       „Number of measurements“ Anzahl der Messungen über „Display Options“

–       Smoothed perfomance = gemittelte Werte über den entsprechenden Zeitraum

–       Perfomance Attribute values, smoothing berechnet den Zeitfaktor mit ein. Z.B. Bootvorgang wird mit berücksichtigt „gewichtetes Mittel“

3.    Remote Komponenten

 

–       Anmelden als DDIC im 000er Mandanten

–       In der RZ21 unter „topology“ > local segments  stehen alle überwachten Applikation Server

–       Zentrale Schritte. RZ21 > Technical Infrastructure > configure central system > create remote monitoring entry

  1. 1. Background Dispatching muss auf jedem System das zentral überwacht werden soll aktiviert sein. Einmalig auf dem CEN und dem Remotesystem durchführen im 000er Mandanten
    1. RZ21 > technical infrastructure > local method execution > activate background“
    2. RZ21 > technical infrastructure  >configure central system > activate central system dispatching (Grundbedingung, sonst kein zentrales Alerting)
    3. Im zu überwachendem System (hier: QAS) auch das lokale Dispatching aktivieren
  2. 2. CSMREG – User muss im 000er Mandanten  vorhanden sein
    1. RZ21 > technical infrastructure > Create CSMREGUSER, Passwort vergeben
    2. Test: am CEN im 000er Mandanten anmelden
    3. Im zu überwachenden System (hier:QAS) ebenfalls einen User anlegen
  3. 2. Agent Start File CSMCONF
  4. 3. Verbindung zum Remote System aufbauen
    1. Verbindung anlegen
    2. RZ21  > Add component to Monitoring über neu Blatt
    3. Systemparameter eingeben, User pflegen, 3 RFC Verbindungen werden angelegt
    4. COLLECT wird mit Benutzer angelegt
    5. ANALYZE wird ohne User angelegt, erfolgt unter angemeldeten Nutzer
    6. CSMREG User of the Central System pflegen
    7. Operating System User on the Host on the Monitored System – Passwort muss nur bei Windowssystem mitgegeben werden, kann aber dennoch gepflegt werden (sollte)
    8. System erschein nun unter Monitored, Remote SAP Systems in der RZ21
    9. [save]

10.  Diese Einstellungen müssen auch vor der Einrichtung eines Agentens zwingend bestehen, da dieser auf die Remoteverbindung zugreifen, sonst wird die Remote-Verbindung nicht zugelassen

11.  Ginge auch über SM59 z.B. bei alter NetWeaver Version vor EHP1

  1. 4. Agenten einrichten
  2. Pull-System über RFC –Verbindung um Daten zu ermitteln und Analyse zu starten
  3. Test: eigenes statisches Monitoring
    1. RZ20 steht „Maintenance Functions off“ einschalten > Extras > Maintenance Functions on
    2. System wählen (dynamischer Knoten)
    3. „selecteable MTEs“ , neues System sollte hier erscheinen, Bäume / Knoten auswählen
    4. z.B. Dialogzeiten: <Systemname>  > R3 Services >  Dialog
    5. klick auf Properties führt die Aktion direkt auf dem Remotesystem über RFC aus. Werte werden vom Zielsystem ausgelesen bzw. gepflegt
  4. Systemgruppen pflegen nach Themen, z.B. Release, Datenbank,  Betriebssystem
    1. Sollte bereits vorher passieren um ein ordentliches regelbasiertes Monitoring aufzubauen
    2. RZ21 > Maintain System Groups
    3. Erscheinen dann unter „System Groups for Alert Monitors
    4. Rechtsklick auf die Gruppe ermöglicht es neue system anzulegen „create systems“

#Tag 2

4.    Agenten

 

–       RZ20 > CCMS Selfmonitoring >

–       Früher:  kein zentrales Monitoring von Non-SAP Komponenten möglich, keine Überwachung, es gab keinen shared memory Bereich

–       Jede Abfrage nutzt eine Dialogprozess, Monitoring sollte nie Grund für einen Perfomanceverlust sein, daher Agenten

–       Agent = Plattform für die Informationsprozesse, entkoppelt Monitoring von Dialogprozessen, SAP spricht mit dem Agenten

–       Aufgaben: Betriebssysteme, Java, Log-File

–       Typen & Installationstipps:

  1. SAPCM3X: ältester, für alle 3er basierte (alte) SAP-System, Kommunikation über den Dispatcher
  2. SAPCCM4X: „klassischer“ Agent für SAP-Systeme, spricht mit dem zentralen System, Grundbedingung für das aktive Alerting über ALM / Email
  3. SAPCCMSR: für alle Non-SAP-Komponenten, stellt shared-memory-segment bereit, nutzt SAPOSCOL, mit -j2e anstarten für „alte“ Java Systeme
  4. CCMSPING: testet Remoteverfügbarkeit von SAP-Systemen, arbeitet lokal, wird häufig auf Non-SAP Systemen installiert, einer reicht mehrere sind vorteilhaft bei mehreren Standort um bessere Antwortzeitenqualität zu ermitteln (WAN-Probleme), kann „n“ Systeme überwachen, sollte nicht auf produktiven Systemen installiert werden: besser auf einer eigenen Instanz, hoher Lastanfall, Virtualisierung möglich
  5. SAP NetWeaver Management Agents:
  6. Alle Agenten werden mit der Installationsmaske ausgeliefert, nicht nutzen!, häufig alte Agenten, kann zu Problemen bei Patchen führen, aus dem Service Marketplace verwenden
  7. Agenten beim Patchen mit berücksichtigen
  8. Am zentralen System immer registrieren
  9. MDM-Systeme werden wie Non-SAP-Systeme angebunden

10.  Agenten sollten überwacht werden, eigenes Objekt ist für jeden Agenten vorhanden

–       Windowsinstallation mit Administratorrechte, empfohlen über den SID-ADM

–       Unixsysteme: über SIDADM, Kommando vorhanden, Init-File, Einpflege des Agenten mit ins Startprofil, Vorteil: bei verteilter Installation (Profildatei wird hinterlegt)

–       Jeder SAPCCM4X Agent kann nur einen Server überwachen, muss auf jedem physikalischen Server laufen

–       CMD / Unix Parameter

  1. –r -u
  2. –u stoppen
  3. –Service für System
  4. – DCCMS startet den Agenten in der Konsole (Standard Unixkommando)
  5. –pf (wichtig) hier wird das Profil hinterlegt, für welche Instanz der Agent verantwortlich ist

4.1.        Installation

 

  1. In der CMD
  2. Installationsbefehl: sapccm4x –R –pf=G:\usr\sap\<SID>\…
    1. 1. Frage: SID
    2. 2. Frage: Zusätzliches System
    3. Liefert profile-Parameter u.a. für das Shared-Memory-System aus – überprüfen
    4. 3. Frage: Regristrierungsname für den 000er Mandanten. Nicht DDIC, aber SAPALL User, Vorsicht! Passwort / Name direkt überprüfen am LogonPad, sonst Nacharbeiten notwendig, Passwortänderung beim CSMREGUSER vermeiden
    5. 4. Frage: Sprache – Standard
    6. 5. Frage: Hostname
    7. 6. Frage: Loadbalancer
    8. 7. Frage: Systemnummer
    9. 8. Frage: Routerstring

10.  9. Frage: Tracelevel (Standard behalten)

11.  10. Frage: Passwort

12.  11. Frage: Gatewayinfo (Rück-RFC-Verbindung), Service = sapgw00, Non-SAP-Systeme möchten auch über die Services sprechen, Einträge müssen vorhanden sein z.B. SAPOSCOL – Ports müssen zur Verfügung stehen

13.  Alertverbindung einrichten für die ständige Kommunikation

14.  12. Frage: User CSMREG verwenden

15.  13. Frage: Sprache

16.  14. Frage: Hostname

17.  15. Frage: Systemnummer

18.  16 .Frage: Routerstring

19.  17. Frage: Tracelevel

20.  18. Frage: Systemgruppe (optional) kann später nachgepflegt werden über die RZ21

21.  Service wird angelegt

22.  19. Frage: automatisch / manuell, Standard automatisch, manuell nur bei Microsoftcluster

23.  20. Frage: Domain User / lokales System, lokalen User verwenden

24.  Fertig!

25.  In den Services von Windows sollte der Agentenname.<Systemnummer> als Dienst erscheinen

26.  RZ21 auf dem CEN System, Agent sollte erscheinen

27.  Systemabfragen laufen über den Agenten, Dialogprozess wird nicht mehr genutzt, Grundbedingung für zentrales Alerting, Agent markieren > Log File ist über die RZ20 auslesbar, direkter Zugriff auf die Log-Files

 

5.    Monitore erzeugen

 

–       Es gibt statische (Klassiker) und rollenbasierte Monitore (für große Systemlandschaften)

–       Viele werden bereits mit Templates ausgeliefert

–       Innerhalb eines Monitoring Sets können keine weiteren angelegt werden

5.1.        Statischer Monitor

 

–       Eigener Monitor

  1. RZ20
  2. Wartungsfunktion einschalten
  3. Neues Set anlegen über „Blatt“
  4. Namen vergeben ohne „SAP“ Präfix
  5. „public“ am besten erst bei fertigen Monitoren
  6. Entweder „neu“ gestalten oder über Template
  7. Das Template auswählen z.B. SAP CCMES Monitor Templates > Database
  8. Kopieren nach <Wunschname>
  9. In den eigenen Monitor wechseln

10.  Vorlage gilt nur für das lokale System

11.  Fremdsysteme über „editiern“ ändern, vorher Knoten ausählen

12.  Selectable MTE’s auswählen (Abfrage läuft über den Agenten)

13.  Knoten auswählen

14.  Edit note

15.  Virtual Node (zur Übersicht)

16.  Knoten nach Wunsch auswählen

17.  Knoten erscheint strukturiert unter der Virtual Node

18.  Idee: nach dem Daily-Check aufbauen

 

5.2.        Regelbasierte Monitore

 

–       Prüft welches MTE zum System passt und erzeugt diese Adhoc

  1. [neu] Regel Node
  2. Regel wählen, hier: CCMS_GET_MMTE_BY_CLASS, Beispiel für eine Klasse wäre Database,
  3. Paramter values R/3 System wählen
  4. <ALL> – nimmt alle als Remote System überwachen Komponenten
  5. <CURRENT> nur das System über das gerade die RZ20 ausgeführt wird, wichtig oder besser als die direkte SID wenn das Monitoring Set transportiert wird
  6. c. <SID>
  7. Systemgruppen tauschen hier auch auf, sehr hilfreich
  8. MTE Class wählen, hohe Zahl!, zeigt nur die Systemklassen die das lokale System kennt, nicht die entfernten
  9. Tipp: neuer Modus auf dem entfernten (zu monitorenden System) auswählen
  10. RZ20
  11. z.B. R/3 Services > Responsezeit > Properties > Namen der Systemklasse kopieren
  12. auch Systemklassen die das lokale System nicht kennt sind eintragbar
  13. „Display virtual summary nodes in the monitor“ wählen
  14. „Display long MTE Name“
  15. Speichern
  16. Monitornamen vergeben
  17. Test in der Übersicht
  18. Editieren aus <CURRENT> zu <ALL>
  19. Alle Systeme werden angezeigt

–       RZ21, Gruppen ändern > ändert auch die Auswertung im Template für das Regelset, Monitore werden automatisch angelegt, dient auch als Grundlage z.B. für Nagios

–       Übersicht verbessern

  1. Virtual Node kreieren – nicht sinnvol ist statisch
  2. Regel kreieren- „CCMS_DEFINE_R3_SYSTEMS“
  3. R3 System auswählen
  4. „Display virtual summary…“ auswählen
  5. Greift für jedes System das der Regel entspricht sortiert nach System
  6. Im Edit monitor definitons Kntoen auswählen > neu > neue Regel > CCMS_GET_BY_CLASS
  7. MTEClass einfügen
  8. Regelstruktur ist aufgebaut: oberste Ebene welche Systeme, tiefere Ebene

–       Tipp bei vielen Regeln:

–        in der obersten Regel nur Systeme definieren mit  <ALL>

–       In der nächsten Ebene die System nach Klassen mit Hilfe von <CLASS>

–       Monitoring Sets mit virtuellen Nodes verwenden keinen Speicher

–       F1-Taste hilft

–       Regelbasierte Abfragen werden erst im Moment der Abfrage im Shared-Memory-Bereich gelegt

–       Bei Nagios-Systemen empfohlen die Systeme direkt abzufragen via Nagios CCMS-Plug-In um die Antwortzeiten zu verkürzen

5.3.        Spezielle Komponenten überwachen

 

–       Zusätzliche Monitoringbereiche benötigen evt. Customizing, liefern bei Standard keine Ergebnisse

–       Bevor neue spezielle Komponenten den vorhandenen Platz der MTE Komponenten überprüfen, ggf. werden neue MTEs nicht angelegt, beim Neustart könnten MTEs willkürlich wegfallen

–       Beispiel Emailüberwachung „SCOT“

  1. TA: SCOT
  2. Utilities > Alertmonitor >start datacollector
  3. Erst jetzt werden Datensammler MTEs angelegt
  4. Daher auch bei Anderen Komponenten überprüfen ob die MTEs erzeugt werden müssen

–       Beispiel Transaktionen überwachen “Transaction-Specific Dialog Monitor“

  1. Tabelle plfegen
  2. SE16 > Tabelle ALTRAMONI „Alert Transaktion Monitoring“, Tabelle muss lokal vorhanden sein, ist transportierfähig
  3. Maske füllen
    1. MON CLIENT: * oder 000, 001
    2. TCODE: Transaktion z.B. „Z“-Transaktionen (genau das, was am Frontend passiert) hier: RZ20
    3. MO NAME: Name des Monitoring Objekts hier: TRARZ20
    4. MTECLASS: optional kann ein MTEKlassenname vergebe werden, sinnvoll!, z.B. analog zur MO NAME
    5. SERVER ID: am besten <CURRENT> pflegen
    6. Speichern > Datensatz ist angelegt
    7. Tabelle ist gepflegt, wird beim Start neu angelegt
    8. Daher: RZ21 im betroffenem System, mandantenunabhängig
    9. System Overview > Local Segments >Segment auswählen > editieren > [Reset Segment in „WARMUP“ Status], aber aktuelle Werte werden nicht geschrieben

10.  Virtueller Neustart der Monitoring Infrastruktur ist abgeschlossen, Objekte vorhanden

11.  Im CCMS Monitor steht nun das Objekt „TRARZ20“ zur Verfügung

–       Analog  Tabelle für den Joblog lautet „ALBTCMON“

–       Reports lassen sich nicht direkt überwachen

–       Beispiel: CCMS PING Monitor wird mit einer Liste von Systemen gefüllt die überwacht werden sollen

  1. RZ21
  2. CCMSPING Agent muss (wie CCMS4X) installiert werden, egal wo, empfohlen nicht auf dem Produktivsystem, muss nicht zwingend ein SAP-System sein
    1. In der CMD
    2. ccmsping –r
    3. SAP System ID: SID
    4. Client
    5. Language
    6. Hostname: SID
    7. Balancing: n
    8. Etc. vgl Installation anderer Agent
    9. Agent registriet sich selber, ist im Computer Management > Dienste als CCMSPING zu finden

10.  Ggf. mit der Push-Option nachhelfen

11.  Mit –n kann mitgegeben werden, sinnvoll dann, wenn auf einem System mehrere Pingstationen gesammelt werden, Instanznummern möglich von 00-99

  1. Availabity auswählen
  2. System hinzufügen ABAP und JAVA Systeme sind pingbar
    1. RZ21 > Techn. Infrastruktur > Verfügbarkeitsüberwachung > CCMSPING Verfügbarkeitsüberwachung aktivieren
    2. SYSTEM: SID
    3. DESCRIPTION: frei wählbar
    4. MESSAGESERVER
    5. IP Service Name: aus der Services z.B. sapmsQAS
    6. Optional JAVA-Daten pflegen
    7. Monitoring Options: Monitor All Application Servers
    8. Destination … hier CCMS-Agent auswählen
    9. Test Ping

10.  Es ist möglich Systemgruppen hinzuzufügen

11.  Es besteht die Möglichkeit unter Windows die saplogon.ini zu importieren, erscheinen dann unter Unmonitored Systems

–       ALE Monitoring werden über die Transaktion BDMO aktiviert, Monitoring Objekte existieren nicht, werden angelegt

–       QRFC Monitoring über RZ20

6.    Property Varianten

 

–       Varianten kreieren, anpassen, Betriebsvarianten einsetzen

6.1.        Varianten erzeugen

 

  1. RZ21 > Properties Variants Standard ist „*“ = Kundendefault Variante ist ausgewählt
  2. Ist ein Wert nicht definiert, wird der Wert der Vater-Variante ausgewählt
  3. SAP-DEFAULT wird durch Patchprozesse ausgetauscht, daher diese nicht verändern
  4. Beispiel: Eigene Variante Variant > create >
    1. Variant Name: Tagmodus
      1. Description: Textmodus
      2. Parent variant: * (Tipp)
      3. Fertig
  5. Werden Ranges in Attributen Thresholds values geändert, dann wird jetzt nach der Variante gefragt
  6. Soll Variante = Standardvariante werden, dann RZ21, Variante auswählen, activate
  7. Tipp: am besten die Pflegen die abweichen

–       Varianten sind immer nur lokal und gelten für das aktive System

–       In der RZ21 overview oft he Class name > zeigt alle definierten Werte > Liste nach Variante  durchsuchen und so können die Werte aufgeschlüsselt werden

–       Varianten können transportiert werden

–       Variante muss im Zielsystem aktiviert werden

–       Am sinnvollsten sind z.B. Tagmodus und Nachtmodus die an den Betriebsmodus koppeln, sind Varianten angelegt erscheinen diese nun unter dem Betriebsmodus

6.2.       Thresholds verwenden

–       RZ20 > Monitoring Overview > Wert auswählen > editieren > Werte anpassen >dem gewünschten Modus hinzufügen

–       Neueste überschreibt immer!

–       Schwellwert genau definieren, sinnvoll ist es niedrigere Schwellwerte bei Verbesserungen einzupflegen BSP: grün 0-200, Verbesserung aber erst bei 100, sinnvoll um den alten Wert zu behalten bei Nacharbeiten

–       Vorsicht! Falsche Zeitenangabe z.B. bei den Responsezeiten werden nicht auf Plausibilität überprüft

–       Status attributes Werte: sinnvoll wählen!

  1. When should a message cause an alert: always
  2. Change of value upon a alert generation: accept value unchanged, keine Farbänderung, immer grün sinnvoll wenn z.B. ein Nagios im Einsatz ist

7.    Customizing Möglichkeiten

 

–       Jedes MTE Objekt hat Methoden

–       Jedes MTE endet mit einem Attribut, Attributknoten besitzen die Methoden

–       Die drei Methodenarten: Collector, Analyse, Autoreaktion

–       Es gibt zwei Datensammlerarten

  1. Aktiv: sammelt automatisch Daten, auch uneingeplant, z.B. R3 Services, aktive laufen sofort
  2. Passiv: Datencollectionmethode ist/wird definiert vom Batchmode oder SAPMSSYS z.B. CCMS_User_Collect, laufen im regelmäßigen Turnus, Standard = 5 Minuten

–       Anschauen über Auswahl des MTE Knoten > View >  oder über die Properties

–       Method execution: Start the data collection = Zeit wann der Sammler angestartet wird, In the abscene of values deactiviate after XXX – Time Out Zeit, Knoten muss wieder reaktiviert werden

7.1.       Methoden pflegen

 

–       Methoden pflegen werden über die RZ21 gepflegt und können dort eingesehen werden

  • RZ21 > Methods
  • Execution-Registerkarte
  1. Edit
  2. Zeigt Art: Report, Transaktion etc. ….
  3. Call: zeigt wo der Report aufgerufen wird
  • Control-Registerkarte
  1. Backgroundprocess läuft nur dann wenn der Backgroundispatcher läuft
  2. Only in central system – nur bei zentralen Alerting
  3. …
  • Eigene Anlegen [neu]
  1. Name: ZST22
  2. Description: Freitext
  3. Transaktion, Call ST22
  4. Report also manuell anstarten
  5. Release: Typ vergeben -> hier: analysis Methode, ohne Haken keine Freigabe
  6. Methode ist fertig definiert
  7. Eingenen Monitor öffnen
  8. View > gucken wo keine Methode vergeben ist
  9. MTE editieren > Method assignment, Reiter „Analysis“ wählen, Method name: ZST22

10.  Zurück in den current status view

11.  Methode ist mit dem MTE verknüpft

12.  Es ist auch möglich Reports zu hinterlegen, Report muss auf dem Zielsystem liegen, Methoden werden transportiert und lokal

13.  Im Normalfall werden alle Reports auf die zu überwachenden Systeme transportiert

–       Background Dispatcher im 000er Mandaten braucht keinen Datencollector

–       Methoden können einfach über den Release-Reiter wird gesperrt werden (Haken setzen)

7.2.        Auto Reaktionsmethoden

 

–       Sapconnect muss im Client 000 Konfiguriert sein über SCOT

–       Standardmethode heißt CCMS_OnAlert_Email_V2, vorher kopieren!, reicht für die meißten Szenarien aus

–       Bei Parametermüssen gepflegt werden

  • RZ21
  • CCMS_On… kopieren in eigene z.B. Z_Mailalert
  • Parameter pflegen
  1. Sender muss im Mandant 000 vorhanden sein und benötigt im Userfeld eine Emailadresse Typ Internet
  2. RECIPIENTS müssen User im 000 Mandanten sein, soll der User aus einem anderen Mandaten dann wie folgt 001:<SID>:<Username>
  3. TYPEID, U = Email, C=Liste, R=R3, wird über SCOT versendet
  4. REACT_ON_ALERTS: YELLOW, RED, bei leer nimmt er automatisch gelb und rot
  5. SUBJECT_ALERT = Betreffzeile, Parameter (F1-Hilfe) möglich
  6. Es MUSS freigegeben werden! Ansonsten passiert nichts
  7. Dann im MTE bei AUTO Reaction die Methode einpflegen
  8. Ist Auto-reaction method gepflegt, dann wird die Email versendet

 

–       Es lassen sich auch auf übergeordneten MTEs zuweisen