Sie sind auf Seite 1von 13

ADM106 SYSTEM MONITORING USING CCMS I

#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 Monitor ing

- 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 is t 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 Monitor ingeinheit,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 S egment, 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

- Attri but 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 (lief ert 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 Mem ory 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 detail l iert e 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übers icht (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 gefun den 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 ab gestimmt 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 Prior ität

3. In der Übersichtliste steht der Höchstpriorisi erte 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

- MAXD B: 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 Ben utzer (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

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 si nnvoll

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 share d 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 d er 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 Ze itfaktor 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 Schritt e. RZ21 > Tec hnical 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. RZ 21 > 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 (hie r: 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) eb enfalls 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 Verbindung en werden angelegt

4. COLLECT wird m it Benut z er 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 d ennoch 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 Re mote - Verbindung nicht zugelassen

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

5. 4. Agenten einrichten

6. Pull-System über RFC – Verbindung um Daten zu ermitteln und Analyse zu starten

7. Test : eigenes statisches Monitoring

1. RZ20 steht „ Maintenance Functions off “ einschalten > Extras > Main t enance Functions on

2. System wählen ( dynamischer Knoten )

3. „selectea b le 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

8. Systemgruppen pflegen nach Themen, z.B. Release, Datenbank, Betriebssystem

1. Sollte bereits vorher passieren um ein ordentliches regelbasie rtes 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 übe rwacht 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 verteilte r 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

6. In der CMD

7. Installationsbefehl: sapccm4x – R – pf=G: \ usr \ sap \ <SID> \

1. 1. Frage: SID

2. 2. Frage: Zusätzliches System

3.

Liefert profile - Para meter 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 CSMRE GUSER 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 = sapgw0 0, 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. F rage: 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 übe r 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 Mon itore (für große Systemlandschaften)

- Viele werden bereits mit Templates ausgeliefert

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

- 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. Vorla ge 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

a.

<ALL> - nimmt alle als Remote System überwachen Komponenten

b.

<CURRENT> nur das System über das gerade die RZ20 ausgeführt wird, wichtig

c.

oder besser als die direkte SID wenn das Monitoring Set transportiert wird <SID>

d.

Sys temgruppen tauschen hier auch auf, sehr hilfreich

4.

MTE Class wählen, hohe Zahl!, zeigt nur die Systemklassen die das lokale System kennt, nicht die entfernten

a.

Tipp: neuer Modus auf dem entfernten (zu monitorenden System) auswählen

b.

RZ20

c.

z.B. R/3 Services > R esponsezeit > Properties > Namen der Systemklasse kopieren

d.

auch Systemklassen die das lokale System nicht kennt sind eintragbar

e.

„Display virtual summary nodes in the monitor“ wählen

f.

„Display long MTE Name“

g.

Speichern

5.

Monitornamen vergeben

6.

Test in der Übersi cht

7.

Editieren aus <CURRENT> zu <ALL>

8. 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 N ode 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 m it 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 Nag ios 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äh ig

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 Tabell e 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 ni cht 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 > Dien ste 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

3. Availabity auswählen

4. System hinzufügen AB AP 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

2. Description: Textmodus

3. Parent variant: * (Tipp)

4. 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ähle n, 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 attribute s Werte: sinnvoll wählen!

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 eine m 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: Datencollectionmeth ode 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 Anle gen [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

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 e igene 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>:<User name>

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