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

The following Key Performance Indicators are collected, aggregated, and reported:

System Type Aggregation Performance Resource Type Source

Physical Server

Hourly, daily, and monthly

Total average CPU usage

CPULOAD Check

Total size and used space (kB) of every local filesystem, and accumulated over all local filesystems

FILESYSTEMS Check

Total amount of and used virtual memory

PAGINGSPACE Check

Amount of used physical memory

MEMORY Check

Network I/O transmitted and received kilobytes

NETWORK_IO Custom Check

Disk I/O number of reads and writes

DISK_IO Custom Check

Disk I/O read and written kilobytes

Network Response time

NW_RESPONSE Custom Check

HTTP Response time

HTTP_RESPONSE Custom Check

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

Daily Check

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

JVMGarbageCollector Check

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

JVM_MEMORY Check

SAP Instance (Web Dispatcher)

Hourly, daily, and monthly

Number of connections

WD_ConnectionStat Check

Number of threads

WD_ThreadStat Check

Number of queues

WD_QueueStat Check

SAP System (ABAP and ABAP+Java)

Hourly, daily, and monthly

Number of concurrent users

TH_USER_LIST

Number of Transports

TMS_ImportStat Check

Daily and monthly

Average dialog response time and number of dialog steps

Daily Check

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

End-to-End Application Monitoring

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

ORA_TABLESPACES Check

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

DB2_TABLESPACES Check

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.