Pandora: Documentation en: Glossary

From Pandora FMS Wiki
Revision as of 12:39, 5 April 2017 by Steve alvey (talk | contribs) (Alert)
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

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 Pandora FMS through the network, usually using the Tentacle Protocol.

1.3 Module

One module is 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

The console or web console is the web application which allows Pandora FMS to be managed by using the web.

1.7 Metaconsole

The Metaconsole is a Web portal where you can view, synchronize and manage in a 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.

1.8 Group

A group is an organizing element. The 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 operations which are possible 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 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 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

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.

1.15 Action

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.

1.16 Command

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.

1.17 Shell or Command Line

The Shell or Command Line is an interface which allows the introduction of commands by using the 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

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.

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

1.26 'Unknown' State

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.

1.27 Alert Threshold

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.

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