Pandora: QuickGuides EN: Remote Monitoring
The purpose of this document is to make the reader aware of the possibilities regarding configuration and usability for Pandora FMS as a monitoring tool for all kind of systems and applications.
This guide contains a set of specific instructions to build your network environment using Pandora FMS.
These instructions will include short steps covering the installation and the initial configuration, followed by practical examples regarding the real use of the program with its corresponding screenshots.
Let's imagine that we want to implement a solution which integrates Pandora FMS as a monitoring tool in a network environment, mainly to make different remote checks against the critical elements on this network (Servers, routers, etc.) and to have an alert that can be triggered and send an email any time the status of any of these elements is considered critical.
Let's further imagine that we want a historical view of all these events presented on a list, with graphs of a router's interface traffic data.
The requirements to make this implementation work properly are:
- Install a Pandora Server and Pandora Console on a server with access to all the machines which need to be monitored.
- Have it opened and listening all ports needed to execute our remote checks.
In order to know how to install all the elements of Pandora FMS, check the Pandora FMS installation manual. It is also possible to operate from a virtual image containing all the necessary elements installed and configured.
5 Monitoring our network with Pandora FMS
We're going to explain data collecting using remote agents on target devices. The use of software agents hosted from within Pandora FMS aren't going to be discussed in this guide as the topic is already covered in another guide.
We strongly recommended reading the Pandora FMS operation manual to obtain more information and a better understanding of the following processes:
5.1 ICMP checks
The first thing we're going to do is to define modules to check the availability and latency of a remote element from the Pandora Console.
In order to monitor a server or one of it's services (FTP, SSH, etc.) remotely, first we have to create the corresponding agent to monitor this service, so let's get started. This agent is going to gather data from our router, and in order to achieve that we'll need to introduce its main IP during the agent creation. This way we'll be able to perform all the remote checks against this IP by default.
In the management section of the Pandora FMS console click on Manage agents:
On the next screen, click on the button Create agent:
Fill out all the data for your new agent and click on the button Create agent:
Once the agent has been created, click on the upper right tab representing the modules. In this section, select to create a new Network Server module and click on Create:
On the next form, select a module network component, and when the correct menu is displayed, select the check you want to perform. In this example we will select Host Alive, which conducts a ping check against the target, a simple check to know whether the machine is connected to the network or not.
In the case of boolean modules (to check a service's availability for example) or xxxx_proc type in Pandora, which returns a value of 0 when the result isn't good and any other value over 0 when it is good, these are represented with red and green colors respectively, automatically, so it's not necessary to define a range to change its status.
We'll leave the advanced options for another time. Note that the module has obtained the agent's IP address. If you wish, this field can have a different IP address. Once you're done with the module definition, click on the Create button.
In the following screen, all the modules defined in the agent will be shown. In this case the Host Alive module we've just created will come in handy:
As you can see, there's a warning icon over the modules. This warning only means that no data has been received by the module yet, since it's just been added. Once the data begins to be received, this warning will disappear.
However, in the case of the Host Latency module, which returns the time that it takes the server to establish contact with the remote machine in milliseconds, we can define the module's value ranges for warnings and critical statuses.
For example, let's configure the module to create a warning status from 50 to 100 ms and a critical status for a value above 100 ms.
Once we've finished adding modules, click on the upper right tab named "View", and go to the bottom of the new section, where the data will be shown once it is received:
This has been an example of ICMP monitoring, with the most basic and simple checks that allow us to have important and precise information about the status of our monitored targets. There are two kinds of ICMP checks:
- icmp_proc, or host check (ping), which allows us to know whether an IP address is responsive or not.
- icmp_data, or latency check. Basically it tells us the time in milliseconds it takes the machine located on that IP address to respond to a basic ICMP query.
5.2 SNMP checks
Now let's define two remote SNMP modules to measure the incoming and outgoing traffic from the 11th interface of a router. We'll use a similar procedure.
In order to accomplish this task, we first need to check the OIDs our router model has and check which one matches the data we want to obtain.
The easiest way is to use the SNMP Explorer tool, so we can do a SNMP Walk against the IP of the router we want to monitor.
Let's go to the management view of the desired agent and click on the SNMP Explorer tab, on the upper right hand section of the screen:
In order to initiate the SNMP exploration, we need the router's IP as well as its port, if it's not the default one, with valid authentication data. In our case we're going to use SNMP v1 along with a SNMP community that has read privileges.
Once we perform the SNMP Walk we will be able to see a list with all the router interfaces. Select the desired one, and then select the modules we want to create. In our case:
Another way to define SNMP modules is by knowing it's numeric OID, defining the module the same way we did with the ICMP ones.
- Ingoing traffic (interface 11): .220.127.116.11.18.104.22.168.1.10.11
- Outgoing traffic (interface 11): .22.214.171.124.126.96.36.199.1.16.11
If we wanted to add all the modules found by the SNMP Explorer, we should see something like this:
5.3 TCP checks
TCP checking allows us to confirm the status of a port or a TCP service.
There are two specific fields for TCP tests:
TCP checking, by default, simply determines whether the destination port is open or not. Optionally you could send a text string and wait to receive something that will be processed directly as data.
It's also possible to send a text string (using the «^M» string to replace the CR) and you can wait to receive an answer substring to check that communication is correct. This allows us to implement simple protocol checking. For example, we could check if a server is alive sending the following string:
GET / HTTP/1.0^M^M
And wait to receive in return this string:
This is coded in the TCP Send and TCP Receive fields.
Now we have a chance to use a couple of predefined module components for the Network Server, in order to create two modules to check the status of the web and SMTP servers, respectively.**
Pleas note that while inside the module we are defining to check the web server, we're doing a TCP send/receive query, in the case of the SNMP server we only want to check whether the corresponding port is open or not.
Once we are done, we can check the status of these servers in the agent's monitoring view.
5.4 Module detail in graphs
If we want to check the data history of one of the SNMP modules we've defined previously, for example one indicating the ingoing traffic of one of the router's interfaces, we would only have to go to the agent's modular view, and click on the graph icon of the desired module
This way we would display a graph with the module data collected over the last 24 hours by default. In our case we've chosen to display the data collected during the last 6 hours. In order to change the graph format, just click on the grey bar located to the left.
5.5 Event listing
Aside from all the features commented previously, we also have the possibility to see all the events that have occurred in our system, since the modules changing their status to alerts were triggered.
In order to access the event list, simply enter the Event section in the operation menu:
Once inside, we can see the list of unvalidated events during the last 8 hours by default.
If we want to choose the events we want it to show, we have a filter to manage this in the upper section of the console: