# P

## Parameter Set

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!

## Performance Data Collection

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 Database

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:

- PGSQL_Bloat

- PGSQL_Connections

- PGSQL_Deadlocks

- PGSQL_LongTransactions

- PGSQL_ReplicationSlot

- PGSQL_TempFiles

## Predictive Analytics

Predictive Analytics is the Avantra Enterprise Edition approach to “spikey”, “bursty”, or “flapping” monitoring situations for checks based on time series data. It combines Machine Learning algorithms to predict future trends with classic threshold based monitoring.

| This function is only available with the Avantra Enterprise Edition. For more information about editions please see the Avantra Editions Matrix.

There are situations where thresholds are too static, or become too strict. The intention of thresholds is to define a long term separator between good and not so good. Usually a situation only becomes critical if a threshold is exceeded over a longer period of time. Whenever resource usage is spikey, or there are usage bursts, thresholds can be exceeded for a short period of time, although this does not constitute a critical situation.

From a technical perspective it tricky is to decide: is a certain situation only a usage spike, or is it the beginning of a longer term problem?

Predictive Analytics tries to remediate this dilemma. The Avantra agent applies ML based algorithms to understand usage patterns and to predict - at every given point in time - how the usage will evolve in the near future. These predictions are used to determine a trend whenever the agent evaluates a check. And this trend is taken into account, in addition to the defined thresholds.

If a threshold is exceeded and the predictive analytics engine projects the situation clears again within a short period of time, the check status will not be changed. Only if the situation is projected to get worse the check status is changed immediately.

Staring with Avantra 21.11, the Predictive Analytics Engine is enabled in the CPULOAD and the HDB_CPULoad checks. It will successively be rolled out to other checks based on time series data.