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 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!
See also

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)

Hourly, daily, and monthly

Database size and used space

ADA_DATAAREA, DB2_TABLESPACES, MSS_DBUSAGE, SYB_DataSpaces, HDB_Disks, ANY_DBSpaces 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

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).

See also

Physical Server

A Physical Server in terms of Avantra is either:

  • a real server that runs a copy of the supported operating systems

  • a system virtual machine (or hardware virtual machine) running its own operating system (the so called guest operating system)

  • a partition in operating system-level virtualization (virtual environment, virtual private server, guest, zone, container, jail, etc.).

In other words, if it looks like a real server from the point of view of its users, it is called a Physical Server in Avantra.

If you want to manage or monitor a Physical Server you need to install an Avantra Agent on it.

The same holds true if you want to define an End Point on it.

See also

Problem Management

Avantra provides a built-in Problem Management (also known as Ticketing) solution to allow Customer to report problems with their Systems and to issue requests.

Tickets can also be created automatically by Notification Actions.

See also