SAPTRAINING: ADM106 System Monitoring Using CCMS I

download SAPTRAINING: ADM106 System Monitoring Using CCMS I

of 13

description

Mitschrift einer SAP-Administratorshulung.Stand 09/11, Schulungsort Walldorf

Transcript of SAPTRAINING: ADM106 System Monitoring Using CCMS I

ADM106 SYSTEM MONITORING USING CCMS I #Tag 1

1. Grundlagen 1.1. Grund fr das Monitoring: Frherkennung von Problemen, Problemanalyse, Verfgbarkeit, SLA-berprfung/Abgleich Soll-Ist Outsourcingprobleme: Aussagen des Dienstleisters berfprfen 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? Geschftsprozesse sicherstellen, systembergreifendes Monitoring, Alarmierungsmechanismen CCMS ist Management und Basisaufgabe Alle RZ-Transaktionen gehren zur CCMS Infrastruktur Monitoring ist nur ein Teilbereich (Analyse, Alerting,) BPM ist SolutionManager Aufgabe, greift auf CCMS Abfragen zurck, daher ist ein sauberes CCMS ntig Monitoring ist nur mit Alerting sinnvoll Daher: Alertingkonzept erstellen aber: Abstumpfung und berinformation vermeiden

Einstieg

-

1.2. -

Architektur

CEN = zentrale Monitoringeinheit,keine SID, kein System, kann auf Solution Manager oder auf jedem ABAP-System laufen Fremdsysteme bentigen Agenten Monitoring-Segment ist Teil der SAP-Infrastruktur und automatisch dabei Non-SAP-Systeme (ohne ABAP Stack) haben kein Monitoring Segment, bentigen Agenten

1.3.-

Shared Memory Bereich

Wird mit Datensammler gefllt 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 Speicherberwachen (Hardware: Checksum, Threshold), bei virtualisierten Maschinen zhlt der dedizierte Bereich Datensammler fr 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 gehren 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. 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 fr 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 Listbersicht (alle offenen), alle Ergebnisse aus dem Shared Memory Bereich Fehler markiert + [complete Alerts] schliet 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

Das Monitoring

-

-

-

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 gelscht

2.2. -

Analyse

-

-

Doppelklick auf das Objekt springt zur Analyse oder zur Alarmierungsbersicht ab, wenn vorhanden Standardansicht + severity ist sinnvoll, severity = Eskalationswert + Prioritt, Standard = 50, range 0 255 Parameter ndern: Objekt auswhlen > Properties wichtig! Administratoren mssen sich abstimmen, Schwellwerte mssen gemeinsam abgestimmt werden. Jedes Objekt gibt es nur einmal im Speicher und nderungen gelten systemweit 1. Severity (Prioritt des Alerts) 1. Range 0 255 (s.o.) 2. Farbauswahl der oberen Ebenen richtet sich nach der Prioritt 3. In der bersichtliste steht der Hchstpriorisierte 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 auswhlen > Edit > Nodes (MTE): deactivate Oracle DB: BR-Connect muss vorhanden und gestartet sein. Attribut br-connect wird vom ABAP System berwacht. (Auch Berechtigungen prfen) 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 knnen angepasst werden Status Attribute Nodes: z.B. SAPOSCOLL luft ja/nein 1. Liefert eine Mitteilungsnummer zurck

-

-

-

-

2. Keine Schwellwerte mglich, nur mchte ich etwas wissen / nicht wissen 3. Farbgebung mglich Log Attribute Nodes: z.B. komm eine/keine Meldung 1. Wertet Inhalte aus 2. Schwellwerte: wie lange zurck soll ausgewertet werden, wieviele Meldungen in der Liste sollen fr die Meldung genutzt werden (die in den Alert mit einflieen) 3. Prft 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 schlgt Attribute, kein Filter definiert -> Standard gilt 7. Shared Memory Bereich muss vorhanden sein! Sonst ist nichts sichtbar. Fllt 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. mglich, knnen den Status der darunterliegenden Objekte annehmen 3. Hilfreich um Strukturen aufzubauen Information Attribut Nodes: z.B. Versionsnummer 1. I-Symbol, Abfrage mglich, kein Status, dienen hufig anderen Reports zur Analyse (Oracel, Nagios. Skripte) z.B. Releaseinformationen, Datenbankstruktur, DUMB wre fr 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 bercksichtigt 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 durchfhren 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. 4.

5. 6. 7.

8.

3. Im zu berwachenden System (hier:QAS) ebenfalls einen User anlegen 2. Agent Start File CSMCONF 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 mssen 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 4. Agenten einrichten Pull-System ber RFC Verbindung um Daten zu ermitteln und Analyse zu starten Test: eigenes statisches Monitoring 1. RZ20 steht Maintenance Functions off einschalten > Extras > Maintenance Functions on 2. System whlen (dynamischer Knoten) 3. selecteable MTEs , neues System sollte hier erscheinen, Bume / Knoten auswhlen 4. z.B. Dialogzeiten: > R3 Services > Dialog 5. klick auf Properties fhrt die Aktion direkt auf dem Remotesystem ber RFC aus. Werte werden vom Zielsystem ausgelesen bzw. gepflegt 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 ermglicht es neue system anzulegen create systems

#Tag 2

4. Agenten RZ20 > CCMS Selfmonitoring > Frher: kein zentrales Monitoring von Non-SAP Komponenten mglich, keine berwachung, es gab keinen shared memory Bereich

-

-

Jede Abfrage nutzt eine Dialogprozess, Monitoring sollte nie Grund fr einen Perfomanceverlust sein, daher Agenten Agent = Plattform fr die Informationsprozesse, entkoppelt Monitoring von Dialogprozessen, SAP spricht mit dem Agenten Aufgaben: Betriebssysteme, Java, Log-File Typen & Installationstipps: 1. SAPCM3X: ltester, fr alle 3er basierte (alte) SAP-System, Kommunikation ber den Dispatcher 2. SAPCCM4X: klassischer Agent fr SAP-Systeme, spricht mit dem zentralen System, Grundbedingung fr das aktive Alerting ber ALM / Email 3. SAPCCMSR: fr alle Non-SAP-Komponenten, stellt shared-memory-segment bereit, nutzt SAPOSCOL, mit -j2e anstarten fr alte Java Systeme 4. CCMSPING: testet Remoteverfgbarkeit von SAP-Systemen, arbeitet lokal, wird hufig auf Non-SAP Systemen installiert, einer reicht mehrere sind vorteilhaft bei mehreren Standort um bessere Antwortzeitenqualitt zu ermitteln (WAN-Probleme), kann n Systeme berwachen, sollte nicht auf produktiven Systemen installiert werden: besser auf einer eigenen Instanz, hoher Lastanfall, Virtualisierung mglich 5. SAP NetWeaver Management Agents: 6. Alle Agenten werden mit der Installationsmaske ausgeliefert, nicht nutzen!, hufig alte Agenten, kann zu Problemen bei Patchen fhren, aus dem Service Marketplace verwenden 7. Agenten beim Patchen mit bercksichtigen 8. Am zentralen System immer registrieren 9. MDM-Systeme werden wie Non-SAP-Systeme angebunden 10. Agenten sollten berwacht werden, eigenes Objekt ist fr 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 fr System 4. DCCMS startet den Agenten in der Konsole (Standard Unixkommando) 5. pf (wichtig) hier wird das Profil hinterlegt, fr welche Instanz der Agent verantwortlich ist

4.1.

Installation 6. In der CMD 7. Installationsbefehl: sapccm4x R pf=G:\usr\sap\\... 1. 1. Frage: SID 2. 2. Frage: Zustzliches System

3. Liefert profile-Parameter u.a. fr das Shared-Memory-System aus berprfen 4. 3. Frage: Regristrierungsname fr den 000er Mandanten. Nicht DDIC, aber SAPALL User, Vorsicht! Passwort / Name direkt berprfen am LogonPad, sonst Nacharbeiten notwendig, Passwortnderung 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 (Rck-RFC-Verbindung), Service = sapgw00, Non-SAP- Systeme mchten auch ber die Services sprechen, Eintrge mssen vorhanden sein z.B. SAPOSCOL Ports mssen zur Verfgung stehen 13. Alertverbindung einrichten fr die stndige 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 spter 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. als Dienst erscheinen 26. RZ21 auf dem CEN System, Agent sollte erscheinen 27. Systemabfragen laufen ber den Agenten, Dialogprozess wird nicht mehr genutzt, Grundbedingung fr 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 (fr groe Systemlandschaften) Viele werden bereits mit Templates ausgeliefert Innerhalb eines Monitoring Sets knnen 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 Prfix 5. public am besten erst bei fertigen Monitoren 6. Entweder neu gestalten oder ber Template 7. Das Template auswhlen z.B. SAP CCMES Monitor Templates > Database 8. Kopieren nach 9. In den eigenen Monitor wechseln 10. Vorlage gilt nur fr das lokale System 11. Fremdsysteme ber editiern ndern, vorher Knoten aushlen 12. Selectable MTEs auswhlen (Abfrage luft ber den Agenten) 13. Knoten auswhlen 14. Edit note 15. Virtual Node (zur bersicht) 16. Knoten nach Wunsch auswhlen 17. Knoten erscheint strukturiert unter der Virtual Node 18. Idee: nach dem Daily-Check aufbauen

5.2. -

Regelbasierte Monitore

Prft welches MTE zum System passt und erzeugt diese Adhoc 1. [neu] Regel Node 2. Regel whlen, hier: CCMS_GET_MMTE_BY_CLASS, Beispiel fr eine Klasse wre Database, 3. Paramter values R/3 System whlen a. - nimmt alle als Remote System berwachen Komponenten b. nur das System ber das gerade die RZ20 ausgefhrt wird, wichtig oder besser als die direkte SID wenn das Monitoring Set transportiert wird c. d. Systemgruppen tauschen hier auch auf, sehr hilfreich 4. MTE Class whlen, hohe Zahl!, zeigt nur die Systemklassen die das lokale System kennt, nicht die entfernten a. Tipp: neuer Modus auf dem entfernten (zu monitorenden System) auswhlen b. RZ20 c. z.B. R/3 Services > Responsezeit > Properties > Namen der Systemklasse kopieren d. auch Systemklassen die das lokale System nicht kennt sind eintragbar e. Display virtual summary nodes in the monitor whlen f. Display long MTE Name g. Speichern 5. Monitornamen vergeben 6. Test in der bersicht 7. Editieren aus zu

-

-

8. Alle Systeme werden angezeigt RZ21, Gruppen ndern > ndert auch die Auswertung im Template fr das Regelset, Monitore werden automatisch angelegt, dient auch als Grundlage z.B. fr Nagios bersicht verbessern 1. Virtual Node kreieren nicht sinnvol ist statisch 2. Regel kreieren- CCMS_DEFINE_R3_SYSTEMS 3. R3 System auswhlen 4. Display virtual summary auswhlen 5. Greift fr jedes System das der Regel entspricht sortiert nach System 6. Im Edit monitor definitons Kntoen auswhlen > neu > neue Regel > CCMS_GET_BY_CLASS 7. MTEClass einfgen 8. Regelstruktur ist aufgebaut: oberste Ebene welche Systeme, tiefere Ebene Tipp bei vielen Regeln: in der obersten Regel nur Systeme definieren mit In der nchsten Ebene die System nach Klassen mit Hilfe von 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 verkrzen

5.3. -

Spezielle Komponenten berwachen

-

-

Zustzliche Monitoringbereiche bentigen evt. Customizing, liefern bei Standard keine Ergebnisse Bevor neue spezielle Komponenten den vorhandenen Platz der MTE Komponenten berprfen, ggf. werden neue MTEs nicht angelegt, beim Neustart knnten MTEs willkrlich wegfallen Beispiel Emailberwachung SCOT 1. TA: SCOT 2. Utilities > Alertmonitor >start datacollector 3. Erst jetzt werden Datensammler MTEs angelegt 4. Daher auch bei Anderen Komponenten berprfen ob die MTEs erzeugt werden mssen Beispiel Transaktionen berwachen Transaction-Specific Dialog Monitor 1. Tabelle plfegen 2. SE16 > Tabelle ALTRAMONI Alert Transaktion Monitoring, Tabelle muss lokal

vorhanden sein, ist transportierfhig 3. Maske fllen 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 pflegen 6. Speichern > Datensatz ist angelegt 7. Tabelle ist gepflegt, wird beim Start neu angelegt 8. Daher: RZ21 im betroffenem System, mandantenunabhngig 9. System Overview > Local Segments >Segment auswhlen > 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 Verfgung Analog Tabelle fr den Joblog lautet ALBTCMON Reports lassen sich nicht direkt berwachen Beispiel: CCMS PING Monitor wird mit einer Liste von Systemen gefllt 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 mglich von 00-99 3. Availabity auswhlen 4. System hinzufgen ABAP und JAVA Systeme sind pingbar 1. RZ21 > Techn. Infrastruktur > Verfgbarkeitsberwachung > CCMSPING Verfgbarkeitsberwachung aktivieren 2. SYSTEM: SID 3. DESCRIPTION: frei whlbar 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 auswhlen 9. Test Ping 10. Es ist mglich Systemgruppen hinzuzufgen

-

11. Es besteht die Mglichkeit 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. 2. 3. 4.

-

RZ21 > Properties Variants Standard ist * = Kundendefault Variante ist ausgewhlt Ist ein Wert nicht definiert, wird der Wert der Vater-Variante ausgewhlt SAP-DEFAULT wird durch Patchprozesse ausgetauscht, daher diese nicht verndern Beispiel: Eigene Variante Variant > create > 1. Variant Name: Tagmodus 2. Description: Textmodus 3. Parent variant: * (Tipp) 4. Fertig 5. Werden Ranges in Attributen Thresholds values gendert, dann wird jetzt nach der Variante gefragt 6. Soll Variante = Standardvariante werden, dann RZ21, Variante auswhlen, activate 7. Tipp: am besten die Pflegen die abweichen Varianten sind immer nur lokal und gelten fr das aktive System In der RZ21 overview oft he Class name > zeigt alle definierten Werte > Liste nach Variante durchsuchen und so knnen die Werte aufgeschlsselt werden Varianten knnen 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 auswhlen > editieren > Werte anpassen >dem gewnschten Modus hinzufgen Neueste berschreibt immer! Schwellwert genau definieren, sinnvoll ist es niedrigere Schwellwerte bei Verbesserungen einzupflegen BSP: grn 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 Plausibilitt berprft Status attributes Werte: sinnvoll whlen! 1. When should a message cause an alert: always

2. Change of value upon a alert generation: accept value unchanged, keine Farbnderung, immer grn sinnvoll wenn z.B. ein Nagios im Einsatz ist

7. Customizing Mglichkeiten 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 regelmigen 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 knnen 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 luft nur dann wenn der Backgroundispatcher luft 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 whlen, Method name: ZST22 10. Zurck in den current status view 11. Methode ist mit dem MTE verknpft 12. Es ist auch mglich 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 knnen einfach ber den Release-Reiter wird gesperrt werden (Haken setzen)

7.2.-

Auto Reaktionsmethoden

Sapconnect muss im Client 000 Konfiguriert sein ber SCOT Standardmethode heit CCMS_OnAlert_Email_V2, vorher kopieren!, reicht fr die meiten Szenarien aus Bei Parametermssen gepflegt werden RZ21 CCMS_On kopieren in eigene z.B. Z_Mailalert Parameter pflegen 1. Sender muss im Mandant 000 vorhanden sein und bentigt im Userfeld eine Emailadresse Typ Internet 2. RECIPIENTS mssen User im 000 Mandanten sein, soll der User aus einem anderen Mandaten dann wie folgt 001:: 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) mglich 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