Table of Contents
What Is Pandora FMS
Pandora FMS is a monitoring software that collects data from any system, generates alerts based on that data and shows graphs, reports and maps of our environment. There are two versions of Pandora FMS; a free or OpenSource version and a paid or Enterprise version, available starting from 100 devices.
We will have the possibility to monitor systems, servers, applications, networks, events and a long list of devices. Pandora FMS collects the information that we want to monitor, compiles it and saves it to represent it visually, with the objective of carrying out actions that our systems require. This tool can run on different operating systems, including Windows and Linux, the latter being the recommended operating system.
Pandora FMS consists of different elements for its correct operation.
- Servers: in charge of collecting and processing data.
- Database: the place where the servers store the information collected by the different monitors, as well as the tool configuration.
- Console: is the web interface in charge of displaying the collected data and the main method of user interaction with the tool.
In Pandora FMS there are more than ten different servers specialized in different monitoring tasks; from network servers to perform remote checks, to web servers used to monitor the navigation made by a user. There are the following servers:
- Data server: in charge of processing local monitoring information.
- Network server: in charge of executing remote monitoring tasks through network checks.
- SNMP Server: in charge of collecting and processing SNMP traps.
- WMI Server: in charge of monitoring Windows environments.
- Recognition server: in charge of exploring the network and detecting new systems in operation.
- Plugin server: in charge of carrying out more complex remote monitoring by means of personalized scripts.
- Prediction server: in charge of knowing if a data, in the current moment, is anomalous.
- Web server: in charge of carrying out complete web checks.
- Export server: in charge of exporting data to obtain data replication.
- Inventory server: in charge of obtaining and visualizing information from the monitored systems.
- Event server: in charge of collecting events caused in the system.
- Enterprise network server: in charge of the use of advanced strategies for network checks.
- Satellite server: server installed separately to explore and remotely monitor new systems that cannot be reached by the server.
- WUX server: in charge of carrying out complex web transactions in a distributed way.
Pandora FMS console allows different users with different profiles to manage and operate the tool. With this web tool we can control the state of the current monitoring, see statistical information through graphs or reports and control the incidences generated by the monitoring.
Pandora FMS is managed by the use of ACL profiles, by which a user can access only information related to the profile they belong to. For example, an administrator will be able to access to all the information that Pandora FMS contains, while a user will be able to have access only to the data that belong to a certain group.
All the elements described above that make up Pandora FMS (console, server and database) are collected in a single software package -except the satellite server-, which makes the installation of the tool very easy. This package is updated every month with the generation of new versions that can include new functionalities, error correction and security improvements.
Next we are going to describe in a general way some elements that compose Pandora FMS, as well as some functionalities to be able to know the tool a little more.
What is an agent?
Agents are organizational elements that are created remotely or locally to contain a series of monitoring elements. They usually represent a device or server. An agent may have one or more IPs associated with it and its name cannot be repeated with any other, although its alias can. Each agent belongs to a main group, and to as many secondary groups as wanted.
The agents have different states, which are determined by the state of their monitoring elements or modules.
The work of the agent is based on being the container of data extraction tools of a certain machine.
Which kinds og agents are there?
There are two types of agent: the software agent and the remote agent.
- Software agent: it is a small piece of software that is installed in a machine and remains running in it, extracting information through local or remote extraction tools and sending it to Pandora FMS server regularly. This installation is done individually in each machine, through an installer.
- Remote Agent: this agent is installed through Pandora FMS console remotely, pointing to an IP address that can reach the machine where the Pandora FMS server is installed. In this agent, we can only use remote extraction tools.
It is important to see the difference between the agents, being the software agent a local agent that has the machine with which local and remote monitoring can be done, and the remote agent a fictitious agent with which only remote monitoring can be done.
What is a module?
Modules are units of information stored within an agent. They are the monitoring elements with which the information is extracted from the device or server to which the agent points. Each module can store only one metric. Inside the same agent there cannot be two modules with the same name. All modules have an associated status, which can be:
- Not started: where no data has been received yet.
- Normal: data are being received with values outside the warning or critical thresholds.
- Warning: Data is being received with values within the warning threshold.
- Critical: Data is being received with values within the critical threshold.
- Unknown: the module has been running and has stopped receiving information for a certain time.
The modules have different types of data, such as Boolean, numeric or alphanumeric. Depending on the information collected by the module, it will be of one type or another.
Which kinds of modules are there?
There are several types of modules inside Pandora FMS.
- Data module: it is a type of local monitoring module with which checks are made on the system in which the agent is, such as for example the use of CPU of the device or its free memory.
- Network module: it is a type of remote monitoring module with which checks are made to verify the connection with the device or server to which the agent points, as for example if it is working or if it has a particular port open.
- Plugin module: this is a type of local or remote monitoring module with which custom checks can be made through the creation of scripts. With them more advanced and extensive checks than the ones proposed directly through Pandora FMS console can be done.
- WMI module: this is a type of local monitoring module with which the Windows system can be checked through the WMI protocol, such as obtaining the list of installed services or the current CPU load.
- Prediction module: this is a type of predictive monitoring module with which different arithmetic operations are performed through the consultation of data from other “base” modules, such as the average CPU usage of the monitored servers or the sum of connection latency.
- Webserver module: this is a type of web monitoring with which checks are made of the status of a website and obtain data from it, such as for example to see if a website is down or if it contains a specific word.
- Web analysis module: this is a type of web monitoring with which simulations of a user's web browsing are carried out, such as browsing a website, introducing credentials or complying with forms.
Each of these types of module can be used or not depending on the type of agent desired to create. As we mentioned before, a data type module, being a local monitoring module, can only be generated within a software agent.
An event is everything that happens within the system; from the creation of a module to the login of a user in the console. The event itself is a text describing the problem, its origin (agent), and its creation date.
Pandora FMS allows the visualization in real time of all the events of our systems that are monitored; with this information we can make the necessary actions according to the created event. It shows information that goes from any change of state of a module, launched or recovered alerts, to system restarts or personalized events. It is one of the most used views by operation teams in any type of professional monitoring software.
An event can have three status:
- New: This is an event that has just been created by the system.
- In process: this is an event that a user has seen, and is performing some action related to the notice that has arrived. This status must be entered manually by a user.
- Validated: this is a visualized event for which the actions corresponding to the warning have already been carried out. This status can be entered manually by a user, or automatically by the server when there are two events related to the same warning, where the last event will prevail.
Depending on the information carried by the event, it will appear in one color or another. For example, if an information event arrives from which a module has become critical, this event will appear in red.
When validating an event, the screen refreshes and the validated event “disappears”. This happens because the default event view only shows the unvalidated or assigned events, but not the validated ones, that have occurred during the last 8 hours. Thanks to this default view we can observe the active “problems” in real time.
When events occur due to status changes in modules, there will generally be two events: a first event from normal status to another incorrect status, and an event back to normal status, once the problematic situation is resolved.
In these cases, critical or warning events are automatically validated when normal is restored. This is what we call event autovalidation, an essential functionality that allows to hide non-relevant information in the event console.
An alert is the Pandora FMS reaction to an inadequate value of a module, event or trap . This reaction is configurable and can consist of anything that can be triggered by a script configured in the Operative System where the Pandora FMS server that processes the information runs. An alert is a combination of different elements:
- The module: that contains the information, the generated event or the sent trap.
- The condition: that causes the alert to go out (template).
- The command: that is executed when that happens.
- The action: or the specific way to execute that command that can be particular for a specific case or general for a group of cases.
The system of alerts allows to create them for each module of each agent, associating only one alert for each module, although this one can carry out one or several actions.
It’s a very flexible system, which allows to define applicable and generic templates to all modules, avoiding having to define a specific alert for each module. Alerts are composed of:
- Templates: define the firing conditions. For example, go to critical state.
- Actions: indicate the specific way to execute a command, passing particular parameters such as module name, agent, etc.
- Commands: final execution that the Pandora FMS server will do when firing the alert. It can be to write in a log, send a mail, an SMS, execute a script, etc. The command must, implicitly, define where the parameters are passed in the call to the real command.
This template/action/command system is designed to generate very generic templates and actions that are useful for most cases and be able to apply changes globally.
The actions that Pandora FMS will carry out in case of alert situations will be translated at the end in executions in the server, in the form of commands. Therefore, the command defines the “physical” or real execution that is done in the server. The commands are executed by the server that processes the data that triggers the alert. There are predefined “internal” commands, such as generating an event or sending an email, that do not have a visible command.
Actions are the components of alerts in which a command is related to generic variables, that is, they define the way in which the command is called.
The templates of alerts or templates, define the conditions for triggering the alert and an action by default. They are assigned individually to modules to determine under which circumstances a problem in the module in question will be alerted.
There are several types of alerts:
- Simple alerts: alerts generated on a module, explained above.
- Alerts on events: alerts created on the events generated by the system, which allows working from a much more flexible perspective, since alerts are not generated depending on the status of a specific module, but on an event (which may have been generated by several different modules, from different agents). These alerts are based on complex rules, where a single rule can host modules with the same name of different agents without having to perform each alert individually per agent/module.
- SNMP trap alerts: SNMP trap alerts have their own subsystem, except that we redirect a trap to an agent by forwarding traps using the SNMP Trap Forwarding option.
Let's say the case in which we have a module that monitors the saturation state of the network server of a company. This is a critical element for the company, since with a high saturation level the network fluidity will be affected, as well as the work of the employees. Then we generate an alert where, reached a specific saturation level, Pandora FMS executes a command with which it relieves the workload of the network server, thus avoiding automatically a high load saturation.
Pandora FMS offers a wide range of possibilities in the visualization of the data collected by the different monitors. Pandora FMS has a multitude of views with the data collected by the tool. Next we can see a tactical view:
Pandora FMS includes a collection of graphs with which the data collected during a period of time defined by the user can be represented.
The graphs that Pandora FMS offers can be divided in two ways to visualize the data:
- With data collected during a time threshold
We can find simple graphs generated automatically when receiving data from modules, or custom graphs.
The simple graphs show us individually a range of data collected in the interval that is configured.
The custom graphs show us combined information of any module that we want to represent in the same graph with the configured time interval. With this type of graphs we can make comparisons between modules of different agents. An example of this type of graph can be seen below.
- With real-time data
We can visualize in an individual way certain information collected by the console, referring to the state of the server where our Pandora FMS is installed, in real time. By means of this functionality it is possible, for example, observing the traffic flow that has a live network interface.
Pandora FMS offers us the possibility to visualize the monitored data in an orderly way in a report. We can generate these reports in different formats, such as HTML or PDF, even be sent by e-mail automatically.
Within a report, the data are represented in different ways:
- Simple graph: shows a graph with the value of a module during a configured time interval.
- Predictive Graph: shows a graph with the expected values for a module during a configured time interval.
- Top N: shows N values discriminated by maximum, minimum or average over the total of added modules, sorted ascending, descending or by agent name.
- Projection graph: shows a graph in which two parts are presented:
- On the one hand, the data referring to a selected module in an existing period of time.
- On the other hand, the estimation in a future time frame depending on the previously selected values.
- Custom graph: shows a graph with the values of different modules that have been configured in the graph.
- S.L.A Graphs: shows a graph that shows the degree of compliance of a module in the configured interval.
- Module values: where the average, maximums or minimums can be included…
Below is an example of a monthly SLA report:
A service is a grouping of resources that form a whole. Pandora FMS monitors a group of elements whose individual state determines, in a configurable way, the global state of the service provided. For example, Pandora FMS depends on its different functionalities (console, server, SQL…), where each one of them has a degree of minor or major importance for the correct functioning of the tool.
Next we can see a service where we monitor the 4 Pandora FMS services: MySQL, Apache, Tentacle and the server itself.
Pandora FMS offers the possibility to define in a personalized way how to visually represent the monitoring carried out by the tool. Inside the same visual console you can find the following elements:
- Static image: image associated to a module or agent to be able to see its state.
- Icon: simple image that can represent something, such as the logo of the monitored company.
- Progress: allows to visualize the monitoring progress of a module.
- Module graph: allows to visualize the graph of an existing module.
- Cake or bar graph: allows to visualize data of a module with up to 6 different elements, such as the times that a module has passed through the different states in the last day.
- Simple value: it allows to visualize the data of a module in real time.
- Histogram of events: it allows to visualize the histogram of events of a configured interval.
- Service: displays the status of a configured service.
- Text label: text label without associated content.
- Group: to display the status of a group.
- Clock: allows adding a dynamic clock that displays the exact time at all times without having to reload the page.
- Heat map: allows to represent heat clouds depending on the data of an assigned module.
In the next image we can see a heat map:
The visual consoles have an additional functionality with which we could share them through a public URL to any user outside Pandora FMS.
Pandora FMS allows to create individual monitoring pages for each user, in which more than one window in which to include different monitoring maps, graphs or status summaries can be added.
Several different widgets can be added to each dashboard, each one occupying a cell. Each widget has its own characteristics and configurations.
Inside a dashboard we can include more than 20 different widgets that allow to show data with a list of events or with module graphics.
Next we can see a dashboard which shows a list of events, a Top-N graph of events per agent and another one per module.
There are more advanced functionalities inside Pandora FMS, which are developed to handle large environments with many agents/modules.
The policy system proposed in Pandora FMS allows the management of large monitoring environments through the propagation of different elements of the tool in a centralized and homogeneous way within the same installation.
This functionality is designed for environments where we want to monitor a series of devices with the same modules, alerts and other functionalities. Thanks to the policies we can avoid having to manually do each of the monitoring we want and execute the whole process on a large scale with the simple application of a policy.
Some of the operations that a policy can perform are:
- Create/Remove/Duplicate a policy
- Add/Remove one or more agents to a policy
- Create/Edit/Delete a module
- Create/Edit/Delete an alert
Let's suppose a complex environment, where we have groupings of devices depending on their role (servers, routers…); within this environment we want to perform certain particular monitoring for each group of devices and certain global monitoring. By means of the application of policies we will be able to carry out the monitoring management in a homogeneous way, being able to introduce the modules simultaneously without having to create them manually in each one of the different devices.
In Pandora FMS there is the possibility of massively managing different elements of the tool. This functionality becomes important in environments with a high monitoring volume. It is a complementary functionality to the policies to make manual changes in large volumes of data in a punctual way.
Massive operations can be carried out on the following elements, among others:
- Agents: existing agents can be edited or deleted.
- Modules: existing modules can be edited, copied or deleted.
- Alerts: alerts can be added, deleted, enabled or disabled in existing modules.
- Policies: alerts or modules can be added or removed to existing policies.
The Metaconsole is a console where we can visualize, synchronize and manage in a centralized and unified way different Pandora FMS installations. Thanks to this functionality it would not be necessary to manage each monitoring node in an independent way, but it can be managed from a single place, allowing an almost unlimited horizontal scalability.
The Metaconsole offers the user almost all the functionalities that a normal Pandora FMS installation can offer. We can manage the agents, modules, alerts, policies… of each one of the Pandora FMS installations that are collected inside the Metaconsole.
This functionality is thought for big work environments, where we find multiple Pandora FMS installations. It is a way to offer an access point to a user to manage all his machines or to offer a single console that can offer service to different companies and/or users.
Let's take the example of a company that has offices around the world and has a Pandora FMS server in each country in which it operates, being able to have more than 10 different servers. Thanks to this functionality, we could manage from a single server all the others belonging to the company.
It is a very advanced functionality of Pandora FMS, which is recommended to use once the corresponding training is done.
Pandora FMS, by default, makes a deletion in the database of more than 45 days. There is a feature of the Enterprise version by which a historical database is created with the data copied before being purged from the main database. Thanks to this functionality reports or graphs with can be made old data without having to occupy this space in the main database.
The satellite server is a server installed separately from the main one, used to explore and monitor in a remote way new systems not reachable by the Pandora FMS server and where we can't install agents. This is an exclusive component of the Enterprise version.
This functionality is one of the most critical and important of Pandora FMS. A backup is a backup where we keep all the data and configurations of our tool so that, in case of failure, we can recover our installation without losing any data collected previously. That's why Pandora FMS puts at the user's disposal a simple tool to make backups of the database, as well as the Pandora FMS console and server files.
This document gathers a small part of Pandora FMS functionalities and options. From Pandora FMS Enterprise web page, https://pandorafms.com, different contents are available to learn more about the tool, download Pandora FMS packages and versions or contact Ártica ST.
Ártica ST makes available to all users a blog where they explain both elements of monitoring and articles on technology, networks and servers, in order to increase knowledge, not only of the tool but of the increasingly technological world that surrounds us: https://blog.pandorafms.org/
There are online courses to learn how to use the tool in an advanced way, as well as a course to help in the sale of the software, with which you can opt for an official certificate of use of Pandora FMS.
Pandora FMS has a knowledge library or wiki, where more information can be found about functionalities and elements of the tool, as well as quick guides: https://wiki.pandorafms.com
In case of doubts or problems related to Pandora FMS, there is a ticketing system for Enterprise customers, as well as a forum for OpenSource version users.