P
Parametersatz
Parameters Sets sind ein Gruppierungsmechanismus für bestimmte Eigenschaften. Ein Parametersatz kann auf eine dynamische oder statische Gruppe von Systemen angewendet werden.
Die verfügbaren Eigenschaften zur Gruppierung sind: Überwachungsparameter, Check-Ausführung, Check-Benachrichtigung und Überwachungsausnahmeparameter.
Wie leicht zu erkennen ist, kann es Situationen geben, in denen ein bestimmtes System zu mehr als einer Gruppe gehört. Wenn Sie dieselbe Eigenschaft in zwei verschiedenen Parametersätzen definieren, die eine gemeinsame Teilmenge eines Systems teilen, müssen Sie die Priorität der Parametersätze festlegen, um zu entscheiden, welcher schließlich wirksam ist.
Darüber hinaus können Sie für jeden Parametersatz festlegen, ob die Definition einer Eigenschaft in einem Parametersatz auf Ebene eines einzelnen Systems überschrieben werden kann oder nicht. Wenn nicht, können Sie eine konsistente Reihe von Eigenschaften für eine Systemklasse festlegen. Aber selbst wenn Sie die Überschreibung zulassen, können Sie die Eigenschaften jederzeit erneut anwenden.
Parametersätze können geplant werden. So ist es beispielsweise möglich, für unterschiedliche Zeiträume unterschiedliche Werte für Überwachungsparameter zu haben. Sie können Zeitpläne oder Servicezeiten verwenden, um den Gültigkeitszeitraum eines Parametersatzes festzulegen.
TIPP: Bitte priorisieren Sie Parametersätze sorgfältig, wenn sie geplant sind!
Leistungserfassung
Systemtyp | Aggregation | Performance-Ressourcentyp | Quelle |
---|---|---|---|
Physischer Server |
Stündlich, täglich und monatlich |
Durchschnittliche CPU-Auslastung gesamt |
|
Gesamtgröße und belegter Speicherplatz (kB) jedes lokalen Dateisystems und kumuliert über alle lokalen Dateisysteme |
|||
Gesamtmenge und belegter virtueller Speicher |
|||
Belegter physischer Speicher |
|||
Netzwerk-I/O übertragene und empfangene Kilobytes |
|||
Festplatten-I/O Anzahl der Lese- und Schreibvorgänge |
|||
Festplatten-I/O gelesene und geschriebene Kilobytes |
|||
Netzwerk-Antwortzeit |
|||
HTTP-Antwortzeit |
|||
SAP-Instanz (ABAP und ABAP+Java) |
Stündlich, täglich und monatlich |
Maximale Anzahl gleichzeitiger Benutzer |
Monitoring Tree ActivitySnapshot ActiveUsersCount |
Täglich und monatlich |
Durchschnittliche Dialogantwortzeit und Anzahl der Dialogschritte |
||
Durchschnittliche Antwortzeit und Anzahl der Dialogschritte für benannte Transaktionen |
|||
Durchschnittliche Antwortzeit und Anzahl der Dialogschritte aller benannten Transaktionen zusammen pro Instanz |
|||
Top-N Transaktionsantwortzeiten sortiert nach durchschnittlicher Antwortzeit und nach Anzahl der Schritte |
|||
CCMS-Leistungszähler |
CCMS und CCMS_MONSET Custom Checks |
||
SAP-Instanz (Java-only) |
Stündlich, täglich und monatlich |
J2EE Garbage Collection Laufzeitverhältnis |
|
J2EE DSR durchschnittliche Aktionsantwortzeit |
Durchschnitt der Summe der Zeiten (cpu, gen, load, net…) pro DSR-Datensatz mit ungleichen Aktionstypen zu 'unknown' |
||
J2EE DSR Anzahl der Aktionen |
|||
JVM-Speicher verwendeter und zugewiesener Speicherplatz |
|||
SAP-Instanz (Web Dispatcher) |
Stündlich, täglich und monatlich |
Anzahl der Verbindungen |
|
Anzahl der Threads |
|||
Anzahl der Warteschlangen |
|||
SAP-System (ABAP und ABAP+Java) |
Stündlich, täglich und monatlich |
Anzahl der gleichzeitigen Benutzer |
TH_USER_LIST |
Anzahl der Transporte |
|||
Täglich und monatlich |
Durchschnittliche Dialogantwortzeit und Anzahl der Dialogschritte |
||
Durchschnittliche Antwortzeit und Anzahl der Dialogschritte für benannte Transaktionen |
|||
Durchschnittliche Antwortzeit und Anzahl der Dialogschritte aller benannten Transaktionen zusammen pro System |
|||
Top-N Transaktionsantwortzeiten sortiert nach durchschnittlicher Antwortzeit und nach Anzahl der Schritte |
|||
Stündlich, täglich und monatlich |
End-to-End ABAP-, Java- und HTTP-Antwortzeiten |
||
CCMS-Leistungszähler |
CCMS und CCMS_MONSET Custom Checks |
||
Datenbank (alle Datenbanktypen, außer MySQL und PostgreSQL) |
Stündlich, täglich und monatlich |
Datenbankgröße und belegter Speicherplatz |
ADA_DATAAREA, DB2_TABLESPACES, MSS_DBUSAGE, SYB_DataSpaces, HDB_Disks, ANY_DBSpaces SIQ_DataSpaces und ORA_TABLESPACES Checks |
Datenbank (MaxDB) |
Stündlich, täglich und monatlich |
Anzahl der Sitzungen |
Anzahl der Sitzungen, die verbundenen Benutzern gehören |
Daten-Cache-Hit-Rate |
|||
Katalog-Cache-Hit-Rate |
|||
Datenbank (Microsoft SQL Server) |
Stündlich, täglich und monatlich |
Anzahl der Anmeldungen |
OS-Leistungswert des Zählers mit dem Namen 'User Connections' |
Puffer-Cache-Hit-Rate |
|||
Sperrwartezeit |
|||
Anzahl der Deadlocks |
|||
Datenbank (Oracle) |
Stündlich, täglich und monatlich |
Tablespace-Größe und belegter Speicherplatz |
|
Anzahl der Anmeldungen |
'logons current' von V$SYSSTAT |
||
Daten-Puffer-Hit-Rate |
|||
DD-Cache-Hit-Rate |
|||
Verhältnis Benutzer-/rekursive Aufrufe |
|||
Sortierungen im Speicher |
|||
Kurze Tabellen-Scans |
|||
Anzahl der wartenden Sitzungen |
|||
Enqueue-Deadlocks, Timeouts und Wartezeiten |
|||
Datenbank (DB2) |
Stündlich, täglich und monatlich |
Tablespace-Größe und belegter Speicherplatz |
|
Anzahl der Verbindungen |
Summe der lokalen und Remote-Verbindungen SNAPDBM |
||
Bufferpool-Hit-Rate |
|||
Sort-Überläufe % |
|||
LSN-Gab-Clean-Triggers |
|||
Zeit, die die Datenbank auf Sperren wartete |
|||
Sperrwartezeiten |
|||
Deadlocks |
|||
Sperreskalationen |
|||
Datenbank (SAP HANA) |
Stündlich, täglich und monatlich |
Festplattengröße/-nutzung der benannten Volumenpartition |
Performance-Daten-Tabellen M_VOLUMES und M_VOLUME_SIZES |
Physische Speichergröße/-nutzung pro Host |
|||
Spitzenspeicherlimit Größe/Nutzung |
|||
CPU-Auslastung pro Host |
|||
Anzahl der gesamten Sperrwartezeiten |
|||
Gesamte Sperrwartezeit pro Server |
|||
Backup-Größe |
|||
Backup-Durchsatz |
|||
Datenbank (SAP ASE) |
Stündlich, täglich und monatlich |
Anzahl der Verbindungen |
Anzahl der suids in master.sysprocesses |
Cache-Hit-Rate |
|||
Datenbank (SAP SQL Anywhere) |
Stündlich, täglich und monatlich |
Anzahl der Verbindungen |
ConnCount von sa_db_properties |
Cache-Hit-Rate |
|||
Checkpoint-Dringlichkeit |
|||
Wiederherstellungsdringlichkeit |
|||
Datenbank (SAP IQ) |
Stündlich, täglich und monatlich |
Haupt-Cache-Größe |
SIQ_Cache-Check |
Temp-Cache-Größe |
|||
Genutzter Haupt-Cache |
|||
Genutzter Temp-Cache |
|||
Haupt-Cache-Hit-Rate |
|||
Temp-Cache-Hit-Rate |
|||
Katalog-Cache-Maximalgröße |
|||
Genutzter Katalog-Cache |
|||
Katalog-Cache-Hit-Rate |
|||
Zugewiesener Speicher |
|||
Aktive Verbindungen |
SIQ_Connections-Check |
Performance-Indikatoren werden in der Benutzeroberfläche angezeigt und in den Service Level Reports für diejenigen Systeme gemeldet, bei denen die Performance-Datenerfassung aktiviert ist. Dies kann systembezogen (über den PerfDataCollection Monitoring-Parameter) ein- oder ausgeschaltet werden.
Performance-Indikatoren werden automatisch in stündliche, tägliche und monatliche Werte aggregiert, wobei stündliche und tägliche Werte sechs Monate und monatliche Werte drei Jahre lang in Avantra gespeichert werden (siehe auch Performance.PERFDATA_KEEPTIME_MONTHLY).
PostgreSQL-Datenbank
Avantra allows you to monitor any PostgreSQL as a stand alone database. Similar to other monitored objects, Avantra provides a number of out of the box checks which are applied to a PostgreSQL monitored object automatically. To understand how to add a PostgreSQL database, please follow the guide covering Defining stand-alone Databases.
The out of the box checks include:
Predictive Analytics
Predictive Analytics ist der Ansatz der Avantra Enterprise Edition für „spikey“, „bursty“ oder „flapping“ Überwachungssituationen für Prüfungen auf der Grundlage von Zeitreihendaten. Es kombiniert Algorithmen des maschinellen Lernens zur Vorhersage zukünftiger Trends mit der klassischen überwachungsbasierten Überwachung.
HINWEIS: Diese Funktion ist nur in der Avantra Enterprise Edition verfügbar. Weitere Informationen zu den Editionen finden Sie in der Avantra Editions Matrix.
Es gibt Situationen, in denen Schwellenwerte zu statisch sind oder zu streng werden. Die Absicht von Schwellenwerten ist es, eine langfristige Trennlinie zwischen gut und nicht so gut zu definieren. In der Regel wird eine Situation erst dann kritisch, wenn ein Schwellenwert über einen längeren Zeitraum überschritten wird. Bei einem sprunghaften Anstieg der Ressourcennutzung oder es zu Nutzungsschüben kommt, können Schwellenwerte für kurze Zeit überschritten werden, obwohl dies keine kritische Situation darstellt.
Aus technischer Sicht ist es schwierig zu entscheiden, ob es sich bei einer bestimmten Situation nur um eine Nutzungsspitze handelt oder ob sie der Beginn eines längerfristigen Problems ist.
Die prädiktive Analyse versucht, dieses Dilemma zu lösen. Der Avantra-Agent wendet ML-basierte Algorithmen an, um Nutzungsmuster zu verstehen und zu jedem beliebigen Zeitpunkt vorherzusagen Zeitpunkt - vorherzusagen, wie sich die Nutzung in naher Zukunft entwickeln wird. Diese Vorhersagen werden verwendet, um einen Trend zu ermitteln, wenn der Agent eine Prüfung bewertet. Und dieser Trend wird zusätzlich zu den definierten Schwellenwerten berücksichtigt.
Wenn ein Schwellenwert überschritten wird und die Predictive-Analytics-Engine prognostiziert, dass sich die Situation innerhalb kurzer Zeit wieder klärt, wird der check status nicht geändert. Nur wenn sich die Situation voraussichtlich verschlechtern wird, wird der check status sofort geändert.
Ab Avantra 21.11 ist die Predictive Analytics Engine in den Prüfungen CPULOAD und HDB_CPULoad aktiviert. Sie wird sukzessive auf andere Prüfungen auf Basis von Zeitreihendaten ausgerollt.