Pandora: Documentation en: Glossary
- 1 Pandora FMS Glossary of Terms
- 1.1 Agent
- 1.2 Software Agent
- 1.3 Module
- 1.4 Remote Server
- 1.5 Server
- 1.6 Console
- 1.7 Metaconsole
- 1.8 Group
- 1.9 Profile
- 1.10 ACL
- 1.11 Monitor
- 1.12 Data Files / XML Data
- 1.13 Alert
- 1.14 Alert Template
- 1.15 Action
- 1.16 Command
- 1.17 Shell or Command Line
- 1.18 Package
- 1.19 Tarball
- 1.20 SVN / Subversion / Code Repository
- 1.21 Database
- 1.22 Database Sketch
- 1.23 Tentacle
- 1.24 State
- 1.25 'Critical' and 'Warning' States
- 1.26 'Unknown' State
- 1.27 Alert Threshold
- 1.28 False Positive / Negative
- 1.29 Flip-Flop Protection
- 1.30 Synchronous Monitoring
- 1.31 Asynchronous Monitoring
Pandora FMS Glossary of Terms
The purpose of this glossary is to unify and define all the specific Pandora FMS terminology in detail.
- 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.
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.
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.
Server that is on a network that isn't the local 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.
Or 'web console'; the web application which allows Pandora FMS to be managed online.
A Web portal where you can view, synchronize and manage Pandora FMS monitoring systems in a unified and transparent way.
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.
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.
ACL stands for Access Control List, that in Pandora FMS is defined by assigning a profile in a group to a user.
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.
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.
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.
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.
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.
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.
Shell or Command Line
An interface which allows commands to be introduced 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 don't contain information on how to install them, and aren't specific to a specific operating system.
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.
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. [http://en.wikipedia.org/wiki/SQL SQL).
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.
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 [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority IANA.)
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.
'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.
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.
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.
False Positive / Negative
If a check returns an error but hasn't taken place, it's a false positive. If no error is returned but has taken place, 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.
The flip-flop protection of one module displays the number of times the state changes its condition. 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.
We consider a module as synchronous if it returns data in regular intervals, e.g. a temperature measurement every 5 minutes.
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).