Pandora: Documentation en: Glossary

From Pandora FMS Wiki
Revision as of 13:05, 5 April 2017 by Steve alvey (talk | contribs) (Alert Threshold)
Jump to: navigation, search

Go back to Pandora FMS documentation index

1 Pandora FMS Glossary of Terms

The purpose of this glossary is to unify and define all the specific Pandora FMS terminology in detail.

1.1 Agent

    • An agent in Pandora FMS is an organizing component. It is usually a machine, system or host (a computer). The agent contains information and belongs to one group. An agent is not only IT hardware. It could be a building, a vehicle or anything else that 'contains information'. The agent contains information stored in different modules. The agent could be linked to other agents by a parental connection (an agent could be another agent's "child"). Therefore, the agent is an organizing unity within Pandora FMS - a concept where information from other information units called modules is stored.

1.2 Software Agent

Refers to the software which is installed on a computer to automatically collect information. This program is called the 'Pandora FMS Agent' and it's installed on all types of systems: Windows, UNIX, etc. The software agent is an appliance that generates a data file that is sent to Pandora FMS through the network, usually using the Tentacle Protocol.

1.3 Module

An information entity that stores values (numerical or alphanumerical text). Each module only stores one kind of data, of the same kind. That's to say, the module that stores the traffic flow in one router, only stores this value (numbers that increase as time goes on). The modules are contained in the agents, and they are always related to a single agent. An agent can have N modules. The modules are not interconnected.

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 element which processes the collected information in different ways. They also execute alerts and send the data to the database. There are many subtypes of Pandora servers, and each one conducts one operation. The server-type of network, e.g. conducts remote monitoring tests (at a distance, whereas the data servers process the collected XML data).

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

1.6 Console

Or 'web console'; the web application which allows Pandora FMS to be managed online.

1.7 Metaconsole

A Web portal where you can view, synchronize and manage Pandora FMS monitoring systems in a unified and transparent way.

1.8 Group

An organizing element. Groups have agents, and are used as references to fix the things a user can see and the ones they can't. For example, when a report is defined and it's associated to a group, only the users with access to this group are able to see this report.

The groups can also contain other groups, but this hierarchy can't be seen (at least in version 3.1 and the previous ones) in any other way, and it isn't taken into account in the permission system either.

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.

1.10 ACL

ACL stands for Access Control List, that in Pandora FMS is defined by assigning a profile in a group to a user.

1.11 Monitor

A module with an associated state. In previous versions of Pandora FMS, only the boolean modules had states ('normal', if they are at '1' and 'critical' if they are at '0'). At present, all the modules allow thresholds to be defined for three different states. When a module has no information about an associated state, it doesn't know when to change to a 'critical' or 'warning' state, so it's simply a module.

1.12 Data Files / XML Data

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.). The XML format is a standard in computing, and it's quite useful for storing data. For more info about the XML format, please read the detailed explanation of XML.

1.13 Alert

A request configured via an alert template, and associated to a specific module. It can have different associated actions and has two possible states: 'Triggered' or 'not triggered'. The alert, in Pandora FMS, is triggered when something happens - e.g. if a server is down, Pandora FMS interprets this and it sends an email or an SMS to a person, displaying what happened.

1.14 Alert Template

One of the alert's three main components. It defines an alert's configuration in a general way (properly speaking alerts are template requests). It allows the triggering condition to be specified, which can depend on the module's value or state and other details, such as the maximum number of times it's going to be triggered within a specific interval, or recovery options.

1.15 Action

One part of an alert. Actions are requests, or instances, of a command and can include specific parameters, e.g. on the command 'eMail' the actions 'Send an email to the administrator' and 'Send an email to the project distribution list', are defined, defining some of the fields the command had, specifying the administrator's email or its distribution list, following the previous example.

1.16 Command

Another Pandora FMS component. Excluding the Pandora FMS internal commands which allow events to be generated, to send emails, etc. A command represents a program or external utility the server executes.

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 and Code Repository are version control systems which store one repository along with the different version 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 (e.g. [ SQL).

1.22 Database Sketch

The Database Sketch 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 State

We usually refer to the state of one module. It gives us information about the module at the present moment. The state of an agent is determined by considering the worst of the state 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 state will be 'critical'. Same goes for the state of one group.

1.25 'Critical' and 'Warning' States

'Normal', 'warning' and 'critical' are a module's three possible states. The 'warning' and 'critical' states usually show error conditions of different severity. Pandora FMS allows different thresholds to be defined for the 'warning' and 'critical' states of each module independently.

1.26 'Unknown' State

We say that a module's state is unknown if it doesn't receive data from more than twice its interval. E.g., a module that sends data every 5 minutes is shown as unknown after 10 minutes of not receiving any data. Although the module still keeps its state NORMAL, WARNING or CRITICAL depending on the last data received.

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

If a check returns an error but hasn't take place, we consider it a false positive. If it doesn't give back any error and it has taken place, we say that it's a false negative, e.g. we have a false positive if a module returns '1' if the server is available and '0' if it isn't, although it returns '1' but the server is not available.

1.29 Flip-Flop Protection

The flip-flop protection of one module displays the number of times the state changes its condition. This feature allows to protect one module from false positives or negatives. For example, if we know that a module returns 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 would cause state 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