P
Parametersatz
Parameters Sets are a grouping mechanism for certain properties. A Parameter Set can be applied to a Dynamic Group or a Static Group of Systems.
The properties available for grouping are: Monitoring Parameters, Check Execution, Check Notification, and Monitoring Exception Parameters.
As you can easily see, there may be situations where a certain system belongs to more than one group. If you have the same property defined in two different Parameters Sets sharing a common subset of a system, you have to prioritize the Parameters Sets in order to decide which one is finally effective.
Furthermore, for every Parameter Set, you can define if the definition of a property in a Parameter Set can or cannot be overridden on a per-system level. If cannot, you can define a consistent set of properties throughout a class of the system. But even if you allow overriding, you can re-apply the properties at any time.
Parameters Sets can be scheduled. So, for example, it is possible to have different values for Monitoring Parameters of different periods of time. You may use schedules or service hours to define the validity period of a Parameter Set.
Please prioritize Parameters Sets carefully if they are scheduled! |
Leistungserfassung
System Type | Aggregation | Performance Resource Type | Source |
---|---|---|---|
Physical Server |
Hourly, daily, and monthly |
Total average CPU usage |
|
Total size and used space (kB) of every local filesystem, and accumulated over all local filesystems |
|||
Total amount of and used virtual memory |
|||
Amount of used physical memory |
|||
Network I/O transmitted and received kilobytes |
|||
Disk I/O number of reads and writes |
|||
Disk I/O read and written kilobytes |
|||
Network Response time |
|||
HTTP Response time |
|||
SAP Instance (ABAP and ABAP+Java) |
Hourly, daily, and monthly |
Maximum number of concurrent users |
Monitoring Tree ActivitySnapshot ActiveUsersCount |
Daily and monthly |
Average dialog response time and number of dialog steps |
||
Average response time and number of dialog steps for named transactions |
|||
Average response time and number of dialog steps of all named transactions together per instance |
|||
Top N transaction response times sorted by average response time, and sorted by number of steps |
|||
CCMS performance counters |
CCMS and CCMS_MONSET Custom Checks |
||
SAP Instance (Java-only) |
Hourly, daily, and monthly |
J2EE garbage collection runtime ratio |
|
J2EE DSR average action response time |
Average of sum of times (cpu, gen, load, net…) per DSR record with action types unequal to 'unknown' |
||
J2EE DSR number of actions |
|||
JVM memory used and allocated space |
|||
SAP Instance (Web Dispatcher) |
Hourly, daily, and monthly |
Number of connections |
|
Number of threads |
|||
Number of queues |
|||
SAP System (ABAP and ABAP+Java) |
Hourly, daily, and monthly |
Number of concurrent users |
TH_USER_LIST |
Number of Transports |
|||
Daily and monthly |
Average dialog response time and number of dialog steps |
||
Average response time and number of dialog steps for named transactions |
|||
Average response time and number of dialog steps of all named transactions together per system |
|||
Top N transaction response times sorted by average response time, and sorted by number of steps |
|||
Hourly, daily, and monthly |
End-to-End ABAP, Java, and HTTP response times |
||
CCMS performance counters |
CCMS and CCMS_MONSET Custom Checks |
||
Database (All Database types, except MySQL and PostgreSQL) |
Hourly, daily, and monthly |
Database size and used space |
ADA_DATAAREA, DB2_TABLESPACES, MSS_DBUSAGE, SYB_DataSpaces, HDB_Disks, ANY_DBSpaces SIQ_DataSpaces and ORA_TABLESPACES Checks |
Database (MaxDB) |
Hourly, daily, and monthly |
Number of sessions |
Count of sessions belonging to connected users |
Data cache hit ratio |
|||
Catalog cache hit ratio |
|||
Database (Microsoft SQL Server) |
Hourly, daily, and monthly |
Number of logons |
OS Performance value of counter with name 'User Connections' |
Buffer cache hit ratio |
|||
Lock wait time |
|||
Number of deadlocks |
|||
Database (Oracle) |
Hourly, daily, and monthly |
Tablespace size and used space |
|
Number of logons |
'logons current' from V$SYSSTAT |
||
Data buffer hit ratio |
|||
DD cache hit ratio |
|||
User/recursive calls ratio |
|||
Sorts in memory |
|||
Short table scans |
|||
Number of waiting sessions |
|||
Enqueue deadlocks, timeouts, and waits |
|||
Database (DB2) |
Hourly, daily, and monthly |
Tablespace size and used space |
|
Number of connections |
Sum of local and remote connections SNAPDBM |
||
Bufferpool hit ratio |
|||
Sort overflows % |
|||
LSN gab clean triggers |
|||
Time database waited on locks |
|||
Lock waits |
|||
Deadlocks |
|||
Lock escalations |
|||
Database (SAP HANA) |
Hourly, daily, and monthly |
Disk size/usage of named volume partition |
Performance data tables M_VOLUMES and M_VOLUME_SIZES |
Physical memory size/usage by host |
|||
Peak memory limit size/usage |
|||
CPU load by host |
|||
Number of total lock waits |
|||
Total lock wait time per server |
|||
Backup Size |
|||
Backup Throughput |
|||
Database (SAP ASE) |
Hourly, daily, and monthly |
Number of connections |
Count of suids in master.sysprocesses |
Cache hit ratio |
|||
Database (SAP SQL Anywhere) |
Hourly, daily, and monthly |
Number of connections |
ConnCount from sa_db_properties |
Cache hit ratio |
|||
Checkpoint urgency |
|||
Recovery urgency |
|||
Database (SAP IQ) |
Hourly, daily, and monthly |
Main Cache Size |
SIQ_Cache check |
Temp Cache Size |
|||
Main Cache Used |
|||
Temp Cache Used |
|||
Main Cache Hit Ratio |
|||
Temp Cache Hit Ratio |
|||
Catalog Cache Max Size |
|||
Catalog Cache Used |
|||
Catalog Cache Hit Ratio |
|||
Memory Allocated |
|||
Connections Active |
SIQ_Connections check |
Performance Indicators are shown in the UI and reported in the Service Level Reports for those Systems where Performance Data Collection is turned on. This can be turned on or off on a per-System (via PerfDataCollection Monitoring Parameter) level.
Performance Indicators are aggregated automatically into hourly, daily, and monthly values, whereas hourly and daily values are kept for six months and monthly values are kept for three years in Avantra (see also 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.