Pandora: Documentation en: Glossary

From Pandora FMS Wiki
Jump to: navigation, search

Go back to Pandora FMS documentation index

1 Pandora FMS Glossary of Terms


When starting to work with Pandora FMS, it is important to have clear 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 clear to avoid later confusion. The purpose of this glossary is to unify and define in a detailed way all the definitions of terms commonly used in Pandora FMS

1.1 Agent


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

1.2 Software Agent


This refers to the service that is installed on computers to collect local information, and can be installed on all types of systems: Windows, UNIX, etc. It runs on the system in which 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 the Pandora FMS server through the network, generally using the Tentacle protocol.

1.3 Module


A module is an atomic entity of information 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 always associated with a single agent. An agent can contain multiple modules.

1.4 Remote Server


Server that is on a network that isn't the local server.

1.5 Server


The Pandora FMS server is the one that processes the collected information in different ways, it also executes alerts, applies the policies and sends the information to the database. The 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 the Pandora FMS server and can be enabled or disabled depending on the needs.

Sometimes 'Server' refers to a computer, when speaking about a system.

1.6 Console


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

1.7 Metaconsole


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

1.8 Group


Sets containing agents, used to filter and control visibility and permissions. They work closely with user profiles, and by combining, they create rules that establish which elements of the console a user can or cannot view. Groups may contain other groups.

1.9 Profile


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

1.10 ACL


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

1.11 Monitor


A module with an associated status.

1.12 Data Files /Data XML


An XML file is a data file, generated by the Pandora FMS software agents. Besides containing the agent module's information, it contains information about the agent itself (the version, the operating system, etc.).

1.13 Alert


An automatic request configured via an alert template, 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.

1.14 Alert Template


It's 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.

1.15 Action


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.

1.16 Command


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.

1.17 Shell or Command Line


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

1.18 Package


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.

1.19 Tarball


Like packages, they contain a program or group of programs packed in TAR format, but don't contain information on how to install them, and aren't specific to a specific operating system.

1.20 SVN / Subversion / Code Repository


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

1.21 Database


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 have access to them by a structured language of standard requests (SQL).

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

1.23 Tentacle


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

1.24 Status


We usually refer to the status of one module. It gives us 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.

1.25 CRITICAL and WARNING Status


NORMAL, and CRITICAL are a module's three possible status. The 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.

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

1.27 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 won't be triggered more than 5 times within a 10 minutes interval. Besides, the alert will remain triggered until this time interval ends, except if the recovery is already configured.

1.28 False Positive / Negative


When a check returns an error and the error has not occurred, we speak of a false positive. When no error is returned and the error has occurred, we speak of false negative. For example, we have a module that returns 1 when the server is available. We would have a false negative when the server is not available and the module returns 1; and we would have a false positive when the server is available and the module returns 0.

1.29 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 occur. 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, we can configure the flip-flop protection to '3' in order to avoid the false positives causing status changes.

1.30 Synchronous Monitoring


We consider a module as synchronous if it returns data in regular intervals, e.g. a temperature measurement every 5 minutes.

1.31 Asynchronous Monitoring


We consider a module as asynchronous if it returns data, depending on its availability, e.g. it searches for a string in a log file. If it doesn't find the string, the module doesn't 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).

Go back to Pandora FMS Documentation Index