Understanding basic concepts

Private agents

The Anturis Private Agent is a server application that allows you to monitor internal network resources (including behind a firewall) and capture performance metrics of your operating system. The agent can be installed on various supported machines (including cloud and IaaS-based) to gather all required data.

Public agents

The Anturis Public Agent is an external poller that is located in different locations and is accessible as an out-of-the-box feature. The agent allows you to determine the uptime of your web services when accessed from those spots.


A Component it is an entity that represents a group of monitors or a specific device or application. A Component has a set of properties and each Component consists of a number of monitors. Components can be linked, in what is called component dependencies. By using logical dependencies, you can avoid false alert notifications and obtain a hierarchical view of your IT assets.


Status represents the health state of monitors, components, and infrastructures. A monitored object can have one of the following statuses:
  • OK (green color)—normal state.
  • ERROR (red color) —designates a severe problem, such as: lost connection or something goes down.
  • WARNING (orange color) —brings attention to a potential, but not critical issue; such as, hard drive is almost full or web services are responding slowly.
  • NO DATA (grey color) —used in some cases to show that Anturis has no information yet about a monitored object and cannot be sure that an ERROR happened.

The statuses of monitors are used to calculate the component status, with the worst status among all monitors being the one escalated to Component level.

Accordingly, the worst status among all components defines the infrastructure status.

Event type (problem and incident)

There are two event types in Anturis: Problem and Incident. A Problem happens on the Component level when a Component’s status becomes non-OK. An Incident happens on the Infrastructure level when at least one Component within an Infrastructure is given a non-OK status.

For linked components, incidents are very useful in that one incident aggregates more than one problem and you are only alerted about those, instead of receiving notifications about all problems, which can cause an alert spam.

For independent components, an Incident equals a Problem as each component generates its own incident.

An infrastructure is a collection of IT resources grouped by their location, type, or another user-defined concept. Anturis allows for multiple infrastructures to be created for a single account.

An infrastructure consists of different components, which can represent categories.

Anturis uses a hierarchy model that consists of four levels: Account, Infrastructure, Component, and Monitor.

A monitor represents a single IT infrastructure resource that needs to be checked. For each component, you can add a number of monitors. A monitor is not considered a device, because depending on the type of an infrastructure resource, there may be many monitor types. For instance, server CPU load, website HTTP latency, log file, or MySQL.

Monitor period
The period of time between two subsequent checks of a monitored object.

Anturis enables you to send notifications to different people within your organization, so that the right person is notified when an issue occurs. Thus, notification events are divided into alert notification and recovery notification. An alert notification is used when an incident occurs, as opposed to a recovery notification, which is sent when a problem was solved or it disappeared.

A person represents a contact who can be notified in case of an emergency with at least one component. Each person can be made responsible for many components, so this person will receive notifications for all the components that are assigned to them.

Group of persons
Several persons can be gathered into a group. The group helps to inherit notification settings to many persons as you need, where each of them will receive an alert and/or recovery notification.

Severity indicates the importance or urgency of the problem.

The following severity levels are possible:
  • Critical—most severe
  • Major
  • Minor
  • Info—least severe

To ensure correct notifications, it is possible to map a component status to a problem severity.

Thus, once a problem occurs with a component, it is assigned a severity level. Each component contains the mapping between its status and the new problem severity level. For example:

  • If the new Status is ERROR, then the new problem is assigned a severity of critical.
  • If the new Status is WARNING, then the new problem is assigned a severity of major.
Once a problem severity is defined, alert notifications are sent to the persons responsible for the component.

It is possible to adjust the status-severity mapping of a component, in order to set up the relative priority of different components. Let's consider the following example:

The "Very important" component has the following mapping:

  • ERROR → Critical
  • WARNING → Major

The "Not that important" component has the following mapping:

  • ERROR → Major
  • WARNING → Minor