# Server - Built-in Checks

Here you will find detailed information about Built-in checks for Server monitored objects.

Built-in checks are deployed automatically for a monitored object type. Once Avantra has detected a specific monitored object, each of the relevant built-in checks will be auto-deployed to the agent to begin check execution and status reporting. Built-in checks can be configured using Monitoring Parameters (e.g. to set threshold values) and can also be disabled if they are not relevant to your landscape.

## AGENTALIVE

Verifies Avantra Agent alive status and detects cluster switches.

Description

One of the most important Avantra checks. It differs from almost all other checks, since it is not executed by the Avantra Agent, but by the Avantra Server.

AGENTALIVE, on the one hand, is used to self-monitor Avantra Agent and is generated by Avantra Server if there is no message from Avantra Agent within a certain period of time.

On the other hand, it is used to detect cluster switches.

For a Physical Server, the AGENTALIVE check can only have two statuses: Ok or Critical. If the AGENTALIVE turns to Critical, all other dependent checks will turn to Unknown. A Critical AGENTALIVE check result can have several reasons:

- The server is down.

- The server is up but Avantra Agent does not run.

- The server is up and the Avantra Agent is running but cannot connect to Avantra Server due to network problems.

For Virtual Cluster Servers, the AGENTALIVE can also return a Warning state: * The check will be in Ok status if the Virtual Cluster Server is active on one of the configured physical nodes. * The check will be in Warning status if the Virtual Cluster Server has switched from one physical node to the other. The period of how long the check result remains in the Warning state can be configured using the ClusterSwitchMsgDisplayDuration Monitoring Parameter. * The check will be in Critical if the Virtual Cluster Server is not detected on any of the physical nodes, and in any of the reasons given for Physical Servers.

Reference Data

Managed Object | Physical Server, Virtual Cluster Server
Check Cycle | n/a, Check is executed by Avantra Server
Depends on | n/a, the Check is executed independently of any other Check
Monitoring Parameters | AliveTimeout and ClusterSwitchMsgDisplayDuration

## AgentConnect

Monitors the connection from Avantra Server to Avantra Agent.

Description

This Avantra check is executed on the Avantra Server. It monitors whether an Avantra Agent can be reached from the Avantra Server. To decide whether the connection was successful or not, the Agent Configuration distribution is analyzed. If there no connection to the agent for more than AgentConnectTimeWarn minutes (default: 10 minutes), the check status changes to Warning. If the connection cannot be established for more than AgentConnectTimeCrit minutes (default: 60 minutes), the check turns to Critical.

If the AgentConnect Check is in status Warning or Critical, no configuration could be sent to the Avantra Agent from the Avantra Server. When the Check changes to status Ok, the configuration of the Avantra Agent will work again.

Virtual Cluster Server does not possess an AgentConnect check.

Reference Data

Managed Object | Physical Server
Check Cycle | n/a, Check is executed by Avantra Server
Depends on | n/a, the Check is executed independently of any other Check
Monitoring Parameters | AgentConnectRoute, AgentConnectTimeCrit, AgentConnectTimeWarn, and AgentProtocolUseSSL

## CPULOAD

Verifies CPU usage of Physical Servers.

Description

The average usage of all detected CPUs is computed over a period of time.

This Check is also available for Virtual Cluster Servers but is disabled by default.

In the Avantra Enterprise Edition this check supports Predictive Analytics.

Reference Data

Managed Object | Physical Server
Check Cycle | Basic
Depends on | AGENTALIVE
Monitoring Parameters | CheckCycleTime, CPULoadAverageTime, CPULoadCrit, CPULoadWarn, PredictiveAnalyticsEngine

## FILESYSTEMS

Verifies the usage of local (or remote) filesystems.

Description

Every filesystem is checked for its usage (and inode usage on Unix-like operating systems). And a forecast is computed of when the filesystem limit will be exceeded if current usage rates continue. Thresholds can be defined on a per-file system level for both usage and forecast.

By default, only local file systems are considered. Use Monitoring Parameter FSMonitorNetwork to enable monitoring of remote file systems.

On Unix, the file system of the following types are monitored (locally), configured by Monitoring Parameter FSTypeLocal:

advfs, aix, ext2, ext3, ext4, gpfs, hfs, jfs, jfs2, minix, ntfs, ocfs2, reiser4, reiserfs, ufs, vxfs, xfs, xiafs, zfs

On Unix, the filesystems of the following types are monitored if FSMonitorNetwork is activated:

afs, dfs, nfs/nfs2/nfsv2, nfs3/nfsv3, smbfs

Reference Data

Managed Object | Physical Server
Check Cycle | Basic
Depends on | AGENTALIVE
Monitoring Parameters | FSUsageWarn, FSUsageCrit, FSMonitorNetwork, FSTypeLocal, FSTypeRemote, FSExWarn, FSExCrit, FSForecast, CheckCycleTime, FSNodeCrit, FSNodeWarn, PerfDataDiskIOFileSystems

## FULLCHECK

Description

Usually the server does not have a FULLCHECK (i.e. Daily Check). The only exception is when a CUSTOM_CHECK is defined for this server. In such case, the status and description of the check(s) are provided.

Reference Data

Managed Object | Server
Check Cycle | DAILY
Depends on | AGENTALIVE
Monitoring Parameters | None

## MEMORY

Verifies physical memory usage of Physical Servers.

Description

MEMORY check verifies physical memory usage of the operating system against configurable thresholds MemoryUsageWarn and MemoryUsageCrit.

If the percentage of memory used is above MemoryUsageWarn, the check status will be Critical. If the percentage of memory used is above MemoryUsageWarn but still below MemoryUsageCrit, the check result status will be Warning.

If the monitoring parameter thresholds are configured as remaining free space using KB/MB or GB, the amount of free memory is checked (if it is below the corresponding threshold).

MEMORY check is accompanied by check PAGINGSPACE which includes virtual memory i.e. swap space as well. If MEMORY returns a Warning or Critical result, but PAGINGSPACE is still Ok, you will probably notice that the system will perform slower, but should still work correctly. If, however, PAGINGSPACE will result as Warning or even Critical too, the server is definitely in a more serious condition and you may face out-of-memory errors.

Reference Data

Managed Object | Physical Server
Check Cycle | Basic
Depends on | AGENTALIVE
Monitoring Parameters | MemoryUsageWarn, MemoryUsageCrit, CheckCycleTime

## PAGINGSPACE

Verifies paging space usage of Physical Servers.

Description

Every detected paging space (or swap space) is checked for usage. Thresholds may be defined for the total paging space usage. Depending on the operating system, paging spaces may be devices, file (systems), or in memory. For operating systems that use an early paging strategy, paging space being reserved is considered in use.

There is also an option to check the ratio of paging space to physical memory by defining a value for PagingSpacePhysMemRatioWarn

On Microsoft Windows operating systems: This check reports the paging space usage as reported from windows `perfmon.exe`. This value may differ from PF Usage as displayed by the Windows Task Manager.

Reference Data

Managed Object | Physical Server
Check Cycle | Basic
Depends on | AGENTALIVE
Monitoring Parameters | PagingSpaceWarn, PagingSpaceCrit, CheckCycleTime, PagingSpacePhysMemRatioWarn, and TimeOutOsCalls (HSolaris only)

## SAPHostAgentStatus

Description

This check verifies whether the SAP host agent and dependent components are up and running.

SAP host agent discovery is to be done daily automatically only on the servers with some piece of SAP software in the Inventory. That includes SAP instances and SAP databases (IQ, ASE, MaxDB, Hana). Apart from the automatic procedure, there should also be a possibility to force host agent discovery execution for the cases when there is no SAP software on the host, for example, for different database instances (like Oracle or DB2). As this is always a 1-1 relationship between the server and the host agent, the host agent can be added as another part of the server inventory.

| SAP host agent always runs on fixed ports (1128 for HTTP and 1129 for HTTPS) and is always located in the same directory.

On Windows and Linux, the host agent version information is available via the `sapHostCtrl` webservice call, method ExecuteOperation, operation - `versioninfo` (the webservice authentication is required). `sapsys` group member (or Windows equivalent) is enough to get the version info. The proposed credentials pickup approach (the SAP software is installed on the host by default, so the Avantra Agent is likely to contain `avantra.sapControl` creds) is as follows:

- If available, the `avantra.hostControl` credentials are used (should be added as standard to the server). The credential type should be similar to `sapControl`, it can allow certificate-based authentication.

- If `avantra.hostControl` credentials are not set, `avantra.sapControl` credentials are used instead.

- If none of the above is found, the check will remain UNKNOWN.

If HTTP/HTTPS endpoint is discovered, it should not be automatically removed even if the next discovery run will not reach them.

Reference Data

Managed Object | SAP System (ABAP, ABAP+Java)
Check Cycle | Medium
Depends on | FULLCHECK
Monitoring Parameters | _SAPHostAgentProtocol, SAPHostAgentIP, SAPHostAgentCheckSaposcol

## SelfCheck

Performs Avantra Agent self checking.

Description

In addition to checks performed by the Avantra Agent, there are many other tasks that run in the background, for example, change or performance data collection. If something goes wrong while doing these background tasks, SelfCheck will let you know.

Reference Data

Managed Object | Physical Server
Check Cycle | Basic
Depends on | AGENTALIVE
Monitoring Parameters | n.a.

## TimeOffset

Verifies server time accuracy.

Description

The check compares the UTC server time with the Avantra Server UTC time. If the time difference exceeds TimeOffsetWarn (default is 30 seconds), the status changes to Warning, and if it exceeds TimeOffsetCrit (default 60 seconds), it changes to Critical.

For this check to provide correct results, it is crucial to keep the Avantra Server host clock properly synchronized.

Reference Data

Managed Object | Physical Server
Check Cycle | 60 Minutes
Depends on | AGENTALIVE
Monitoring Parameters | TimeOffsetCrit, TimeOffsetWarn