Introduction

Go back to Pandora FMS documentation index

Pandora FMS is a network monitoring software package, intended for all types of environments. Pandora FMS is designed to adapt to every role and organization. Its main objective is to be flexible enough to manage and control the whole infrastructure, without the need to invest more time or money in other monitoring tools.

Pandora FMS currently uses agents for every operating system on the market. It can, of course, be used successfully not only as a system monitoring tool, but as a monitoring tool for all sorts of network devices, whether it might use SNMP, TCP protocol probes, ICMP, UDP or software agents.

• Besides the official documentation, you may find the user's forum where you make ask any of your questions.
• There is an official training program with its very own certification taught by Pandora FMS developers.
• Our quick reference guides help you configure Pandora FMS and implement simple monitoring tasks as well as install software agents, both for GNU/Linux® and MS Windows®.
• Learn more on our website at http://pandorafms.com

Pandora FMS was born out of a personal development project of its original author, Sancho Lerena, in 2003. Originally it was 100% open source code but years later a version oriented towards big companies was needed: Pandora FMS Enterprise, capable of processing large volumes of information through its Metaconsole.

• Auto monitoring: By default it allows to detect hard disks, partitions or databases in a database server, among many other things.
• Auto discovery: Remotely, using the network, you may detect all network elements, catalog them according to your operating system, and monitor with an assigned profile.
• Agents: They are capable of obtaining information - from the execution of a command to the lowest MS Windows® API call: events, logs, memory and CPU consumption, etc. Pandora FMS makes use of a default check library for streamlined processes.
• Control: The agents themselves can activate services, delete temporary files or execute processes. In the Enterprise version it can be done from the web Console, remotely executing tasks such as stopping or starting services, including regular executions. In addition you may use Pandora FMS to remotely access remote systems thanks to eHorus (Telnet, VNC or SSH).
• Alerts and notifications: Notifications are just as important as failure detection. Pandora FMS gives you multiple notification means and formats.
• Analysis and display: Monitoring is not just receiving a trap or having a failing service displayed. It also means presenting forecast reports, correlated summary charts of long-term gathered data, generating user portals, delegating reports to third parties or defining its own charts and tables.
• Inventory: Unlike other solutions where the idea of CMDB is the base, in Pandora FMS it is an option. The inventory is flexible and dynamic (it can auto-discover, remotely check, etc.). Changes may also be notified (e.g. uninstalled software from a computer) or simply be used to make listings.

Remote monitoring means that Pandora FMS’s server polls in a synchronous way the devices it intends to monitor. This process is known as polling or remote monitoring.

Generally speaking, remote monitoring is used:

• To make sure something is alive and running.
• To obtain a numerical value (e.g. to measure the network traffic or the number of active connections).

The opposite process is called asynchronous monitoring, and in case of remote monitoring, we usually refer to it as SNMP traps.

• To monitor network environments, the protocol to be chosen is SNMP with an SNMP device external browser, access to the MIB collections from the network device manufacturers (OID libraries) and trap listening. Then it will be added to the custom OID collections of each device. For Unix® and GNU/Linux® systems bear in mind to activate SNMP functions.
• For MS Windows® servers WMI monitoring is quite appropriate and powerful since it is carried out through authentication credentials.

Finally, you may always monitor networked elements through the use of TCP (e.g. HTTP or SMTP protocols) or ICMP (e.g. ping or latency time).

Regarding systems and applications, the best way to obtain information is definitely from the system by executing commands, or querying the system data sources from the machine to be monitored itself. Pandora FMS software agents is used to run a command or script, or for any queries on the system or application.

In addition to obtaining information through commands, software agents include other advanced fueatures like obtaining inventory information. Agents can also be configured to react in case of a problem or a failure, interacting automatically with the system, deleting a temporary file or executing a given command. When software agents have no direct connection to the designated Pandora FMS server, you may use PFMS Satellite Server or a broker agent.

Before starting the deployment stage, is is important to set the critical points as well as those that will be of the utmost importance of the technological platform to be monitored. That way, before having information about specific data on the systems, it is clear what it is for and how to make full use of it without wasting time on researches or trivial things.

• Availability: You are mostly interested in event-based monitoring and remote monitoring will probably be enough for your needs. It is faster to deploy and will give you fairly quick results. SLA reports will be the most useful ones in this case.
• Performance: They are graphics and numbers, collecting information through agents or remotely, even though you will probably require agents to get in-depth information on their systems. Group reports and combined graphics are of capital importance.
• Capacity Planning: Much more specific. It is necessary to obtain data, as in the second instance, but to parse and manipulate the data, with predictive monitors and very specialized projective reports. Establishing early alerts will be of great help and you are required to have good knowledge of the WARNING and CRITICAL status meanings, besides elaborating serial event management policies to prevent the problem from happening, which is without a doubt the most complex and interesting case.

In order to be able to draw up action procedures, it will be necessary to take into account several factors:

• Urgency of the event: Being able to distinguish something usual from something rare or critical.
• Form of notification: Email, SMS, Telegram, sound alert…
• Scaling: Different forms of warning in face of a recurrent problem. A common case is notification to a manager after a certain amount of time without solving a problem.

Before getting into any configurations, it is advisable to have these concepts clear, draw up schemes with the critical elements, how to monitor them, what to do with all the information gathered and how to report problems that arise.

By focusing on the most critical issues first, you reach a logical starting point that defines what the most important issues for your organization are. Once you know what the most critical elements are, you can define how to monitor the target(s), while considering who will be responsible for the resolution of the reported problems in those systems as well as how to notify the appropriate people of the existence of a problem.

• The direct supervision method implies that there is one or several people constantly overwatching the system. They might see little changes, not critical ones, and have much more flexibility. There is no need to define alerts for each possible case, it is enough to see the laste events to see what is happening on the system right then. This model is used for big environments.
• The indirect supervision method implies the use of automated notifications that were previously configured. This system is suitable for few devices or when the ritical elements are precisely identified with their according pre-established notification and solution.

Go back to Pandora FMS documentation index