Pandora FMS Glossary of Terms

When starting to work with Pandora FMS, it is important to fully understand some of the terms that are used. Because the different monitoring systems use their own terms to refer to similar concepts, it is important that each of them are throughly explained to avoid misleadings. The purpose of this glossary is to unify and define in a detailed way all the definitions of the terms commonly used in Pandora FMS.


An agent in Pandora FMS is an organizational entity, which is usually a machine, system or host (a computer), that contains information of different checks called modules, and belongs to a single group. It can be related to other agents through a kinship relationship (parent-child).

Software Agent

This refers to the service that is installed on computers to collect local information, and it can be installed on all types of systems: MS Windows®, UNIX®, etc. It runs on the system where it is installed to collect and send information from time to time, called interval. The software agent generates a data file in XML format that is sent to Pandora FMS server through the network, generally using Tentacle protocol.


A module is an atomic information entity that stores numerical or alphanumeric/text values. Each module only stores data from an individual check (CPU, RAM, traffic…). The modules are contained within the agents, and stay always associated with a single agent. An agent can contain multiple modules.

Remote Server

Server that is on a network that is not the local server.


The Pandora FMS server is the one that processes the collected information in different ways, it also executes alerts, applies policies and sends the information to the database. Pandora FMS server also contains different components that perform their own functions, some of them are the network server, the SNMP server, the data server… All of them are components that are part of Pandora FMS server and can be enabled or disabled depending on the needs.


Pandora FMS console or web console is the interface that allows Pandora FMS to be managed through the browser.


A Web portal where you can view, synchronize and manage different Pandora FMS monitoring systems in a unified and transparent way. That way, the data from different monitoring environments will be handled centrally from this hierarchically superior point.


A set containing agents, used to filter and control visibility and permissions. Groups work closely with user profiles, and combine to create rules that establish which elements of the console a user can or cannot see. Groups may contain other groups.


It defines the permissions on different possible operations under Pandora FMS: see an agent, modify an agent, assign alerts, define reports, manage the database, etc. They are associated with users for specific groups.


ACL stands for Access Control List, that in Pandora FMS are defined by assigning a profile on a group to a user. They determine user permissions.


A module with an associated status.

Data Files /Data XML

Data files generated by Pandora FMS software agents. Besides containing the agent module's information, they contain information about the agent itself (the version, the operating system, etc.).


An event is everything that takes place in a monitored system. The information displayed ranges from any module status change, alerts triggered or retrieved, to system restarts or custom events.


An automatic request based on circumstances. It can have different associated actions and has two possible status: “Triggered” or “not triggered”. The alert, in Pandora FMS, is in charge of sending a warning email or an SMS to a person, displaying what happened. An alert consists of a template + action + command.

Alert Template

It is one of three components of alerts. It specifies the triggering conditions of the alert, which may depend on the value or status of a module, and other details such as the maximum number of times it will be triggered in a given interval or time range of operation.


Execution carried out when an alert is triggered. They are parameterizable through a series of fields, including specific information on the circumstances in which the alert was triggered. It is possible to execute several actions for a single alert.


System-level execution carried out by the server when an alert is triggered. External commands or custom scripts can be used to expand existing possibilities.

Shell or Command Line

An interface which allows commands to be entered manually, via keyboard.


A package contains a program or group of programs packaged in a specific format, ready to be installed in a specific operating system and version, e.g. an RPM package for OpenSUSE Linux.


Like packages, they contain a program or group of programs packed in TAR format, but do not contain information on how to install them, and are not specific to a specific operating system.

SVN / Subversion / Code Repository

SVN / Subversion / Code Repository is a version control system that stores one repository along with the different versions of the files assigned to one project as long at it exists. The group of files within a specific time is called 'Revision', so two people that have the same project's revision will have two identical copies of the same files.


A collection of data belonging to the same context and stored systematically for later use. Pandora FMS uses relational databases, within which the place and the way data is stored has no particular importance. You can access them through a structured language of standard requests (SQL).

Database Schema

The Database Schema describes the database structure in a formal language. In a relational database, the sketch defines the tables, the fields of each table, and the connections between fields and tables.


Tentacle is the data transfer protocol the software agents and the Satellite Server use to send data to Pandora FMS Server. Tentacle is multi platform and it is designed to be an easy-to-use and secure protocol. It uses port 41121 (assigned by IANA) by default.


It is normally used to refer to the status of one module. It gives information about the module at the present moment. The status of an agent is determined by considering the worst of the status of all its modules as a group (if it has 5 modules and one is in CRITICAL, two in WARNING and two in NORMAL), the module's status will be CRITICAL. Same goes for the status of one group.


NORMAL, and CRITICAL are a module's three possible status. CRITICAL and WARNING status usually show error conditions of different severity. Pandora FMS allows different thresholds to be defined for the CRITICAL and WARNING status of each module independently.

UKNOWN status

We say that a module is in unknown status or UNKNOWN if it does not receive data for more than twice its interval. In other words, a module that sends data every 5 minutes is marked as UNKNOWN after 10 minutes without receiving data.

Alert Threshold

The time interval in which the defined restrictions are applied when configuring the alert template. For example: An alert template which defines a '10 minute' threshold and a maximum alert number of '5', ensures that the alert will not be triggered more than 5 times within a 10 minute interval. Besides, the alert will remain triggered until this time interval ends, except if the recovery is already configured.

False Positive / Negative

When a check returns an error and the error has not taken place, it is a false positive. When no error is returned and the error has occurred, it is a false negative. For example, a module that returns 1 when the server is available. It would be a false negative when the server is not available and the module returns 1; and it would be a false positive when the server is available and the module returns 0.

Flip-Flop Protection

The flip flop protection of a module indicates the number of times that the condition of change of status must be given in order for the change of status to happen. This feature allows a module to be protected from false positives or negatives. For example, if a module returns a false positive, but never more than twice in a row, the flip-flop protection can be modified to prevent false positives from causing status changes.

Synchronous Monitoring

A module is considered synchronous if it returns data in regular intervals, e.g. a temperature measurement every 5 minutes.

Asynchronous Monitoring

A module is considered asynchronous if it returns data depending on its availability, e.g. it searches for a string in a log file. If it does not find the string, this module does not return data. Another -very common- example is the one of SNMP traps which are only generated if an error takes place (e.g. a power-supply failure).