From Pandora FMS Wiki
- 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
One of the things which are sometimes difficult to understand in the beginning are the terms we use. If you came from another monitoring system or if you don't know any previous one, it's quite difficult. The main purpose of this glossary is to unify and define all the term definitions usually used in Pandora FMS in a detailed way.
- An agent in Pandora FMS is an organizing company. It is usually a machine, system or host (a computer). The agent contains information and belongs to one group. An agent could also be an organizing entity, different from a computer. 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 the son of another agent). Therefore, the agent is an organizing unity within Pandora FMS - a concept where information from other information units called modules is stored.
Though it's named the same as the previous concept, the software agent refers to the software which is installed on the computers 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 the Pandora FMS through the network, usually using the Tentacle Protocol.
One module is an atomic information entity that stores values (numerical or alphanumerical text). Each module only stores one kind of data, from the same kind. That's to say, the module that stores the traffic flow in one router, only store this value (numbers that increases as time goes on). The modules are contained inside the agents, and they are always related to an only agent. An agent could have N modules. The modules are not connected between them.
Server that is on net and that isn't the local server.
The Pandora FMS Server is the element which processes the collected information in different ways. They are also the ones that execute alerts and send the data to the database. There are many subtypes of Pandora servers, and each one conducts one operation. The servers type of network, e.g. conducts remote monitoring tests (at a distance, whereas the data servers process the collected XML data).
Sometimes, we refer to a 'Server' when speaking about a system, to a computer.
The console or web console is the web application which allows to manage Pandora FMS by using the web.
The Metaconsole is a Web portal where you can visualize, synchronize and manage in an unified way different Pandora FMS monitoring systems. This way, the data management of different monitoring environments will be done in a transparent way for the user.
A group is an organizing element. The groups have agents, and are used as reference to fix the things a user could see and the ones he 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 couldn't be seen (at least in version 3.1 and the previous ones) in any other way nor is it taken into account in the permission system.
It's a group of 'permissions' on different operations which are possible under Pandora FMS: To see an agent, modify an agent, assign alerts, define reports, manage the database, etc.
ACL is an English acronym for Access Control List, or 'Listas de Control de Accesos' (LCA in Spanish), that in Pandora FMS are defined by assigning a profile in a group to one user.
It's 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 to define thresholds for three different states. When a module hasn't 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 modules 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 to contain data. For more info about the XML format, please read the detailed explanation of XML.
An Alert is a request of an alert template, associated to a specific module. It can have different associated actions and has two possible states: 'Fired' and 'not fired'. The alert, in Pandora FMS, does that 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.
An Alert Template is one of the alert's three main components. It defines an alert's configuration in a general way (properly speaking we call alerts to a template request). It allows to specify the firing condition, 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 fired within a specific interval or recovery options.
The action is one of the alert's parts. Actions are requests which is, the particularity of one command. This particularity takes care for the actions to include specific parameters, e.g. on the command 'eMail' we could define the actions 'Send an email to the administrator' and 'Send an email to the project distribution list', defining some of the fields the command had, specifying the administrator's email or its distribution list, following the previous example.
A Command is another component of the Pandora FMS list. Excluding the Pandora FMS internal commands which allow to generate events, send emails, etc. A command represents a program or external utility the server executes.
Shell or Command Line
The Shell or Command Line is an interface which allows the introduction of commands by using the 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.
It's the same as a package. It contains a program or group of programs packed in the TAR format, but different from this, it doesn't contain information about on how to install it, and they aren't specific for a specific operating system, although it's possible.
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 Database is a group of data which belongs to the same context and is stored systematically for its 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 one module's the three possible states. The 'warning' and 'critical' states usually show error conditions of different severity. Pandora FMS allows to define different thresholds for the 'warning' and 'critical' states of each module independently.
We say that one module is on state unknown if it doesn't receive data from more than twice its interval. This is, one module that sends data every 5 minutes is selected as unknown after 10 minutes of no receiving any data. Although, the module still keeps its state NORMAL, WARNING or CRITICAL depending on the last data that it got.
It's the time interval in which the defined restrictions are applied when configuring the alert template. For example: An alert template which defines a '10 minutes' threshold and a maximum alert number of '5', warranties that the alert won't be fired more than 5 times within a 10 minutes interval. Besides, the alert will remain fired until this time interval ends, except if the recovery is already configured.
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.
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.
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).