How to migrate SNMP monitoring from Cacti to Pandora FMS

How to migrate Cacti to Pandora FMS

Any IT environment needs a monitoring system, but which one should we use? We can opt for traditional and more limited systems, or for current monitoring systems such as Pandora FMS.

In order to facilitate the task to any user that needs it, from the Pandora FMS team we have developed a method to migrate SNMP monitoring data in order to learn how to migrate Cacti to Pandora FMS in a fast and easy way.
Unlike Pandora FMS, Cacti has 2 ways to collect data:

1. Taking the data via SNMP (using Cacti’s internal methods).
2. Taking the data via scripts (some included in the installation of Cacti and others customized by the user).

Given this situation, simple and standard monitoring mechanisms in Cacti (e.g. a check to measure the latency of a ping) should be performed using scripts or plugins rather than being integrated into the system.

In Pandora FMS this type of basic checks are integrated in the tool itself, thus leaving the scripts or plugins for more advanced monitoring. Therefore, unlike Cacti, we have more directly integrated data collection options:

1. Taking the latency and response data to a ping.
2. Monitoring the status and latency of TCP ports and even getting some value from the connection to them.
3. Taking data via SNMP (both making snmpget requests and receiving traps).
4. Taking data via WMI from Windows systems.
5. Collecting information from an operating system using commands from the operating system itself.
6. Monitoring the state of a web, taking data from it and even simulating the browsing experience of a user looking for failures (only with Pandora FMS Enterprise).
7. Monitoring business process transactions (only with Pandora FMS Enterprise).
8. Performing arithmetic operations based on the values of other checks performed.
9. Taking data via custom scripts or plugins.

As we can see there is a big difference between both monitoring systems, and that is why initially this script will only migrate those checks that take data via SNMP in Cacti, those that use the collection methods (Data Input Methods) “Get SNMP Data” or “Get SNMP Data (Indexed)”.

When it comes to discovering how to migrate Cacti, we need to know that we can only migrate from Cacti SNMP checks that are collecting data, since the purpose of this utility is to preserve all the historical data obtained so far.

Therefore, following this migration process, we will be able to keep all the SNMP monitoring obtained so far in a system with many more possibilities, which means a greater ease of use when adding new checks and managing existing ones.

Requirements

Now that we have seen and explained the differences between the two monitoring systems and the purpose of the script let’s explain how to achieve our goal: learn how to migrate Cacti SNMP monitoring to Pandora FMS.

To work properly, this script must meet the following requirements:

1. The script must be executed from the computer where the Pandora FMS server will be hosted.
2. This computer must have access to the Cacti database as configured in the plugin configuration file (you can see all the detailed documentation of the script in Pandora FMS library).
3. The computer from where we launch the script must have HTTP access from Pandora FMS server to the path where the Cacti RRD files are hosted or transfer the RRD files to a directory in Pandora server. Cacti RRD files are those that store the monitoring data.
4. The computer where we launch the script must have the tool “rrd2csv”, which can be downloaded from this link.
5. The computer from where we launch the script must have the perl module “RRD::Simple“ installed.

Learn how the script works when migrating from Cacti to Pandora FMS

The script will migrate the Cacti SNMP monitoring in 3 steps:

1. Creation of agents in Pandora FMS:

First, a query is made to the Cacti database, thus taking into account all the devices being monitored.
An agent is then created in Pandora FMS for each device, using Cacti’s “Description” field as “Agent name” in Pandora FMS and Cacti’s “Hostname” field as “IP Address” in Pandora FMS. If there is already an agent with the corresponding “Agent name”, the agent is not created or modified.

When creating the agents if it detects that the IP address of the device is “localhost” or “127.0.0.1“, it would be changed by the IP address defined in the script configuration file, since it would not make sense to refer to the Pandora FMS server in the agent that corresponds to the Cacti server.
All agents created as a result of the migration will have the words “Migrated from cacti” in their description to locate them more easily.

2. Creation of SNMP modules:

Secondly, for each device detected as Pandora FMS agent (both if it already existed and if it has been created) the corresponding SNMP modules are generated.
In order to do this, a query is made in the Cacti database in order to obtain the following data:

• SNMP version of the device.
• SNMP community of the device.
• OID of the check carried out.
• Name of the graph showing the data in Cacti.
• Path to the RRD file that stores the data.
• Name of the collected information (Data source name).
• Type of data collected.

Based on this information the script creates the modules in the following way:

• It checks if the monitored OID is part of the IF-MIB tree to build the module name according to the nomenclature used by Pandora FMS (_ – for example: enp0s3_ifInOctets).

The IF-MIB tree is standard for SNMP devices and has information from network interfaces.

With this information Pandora FMS is able to show traffic graphs of a network interface (input and output) and to represent the connections between devices using a specific network interface, that’s why certain modules have to fulfil a specific nomenclature.

If it is not an OID of the IF-MIB tree, the data source name is used as name for the module in Pandora FMS:

The script determines the type of data for the module in Pandora FMS considering the type of data collected in Cacti following the following table:

Data type in Cacti	Data type in Pandora FMS
GAUGE	remote_snmp
COUNTER	remote_snmp_inc
DERIVE	remote_snmp_inc
ABSOLUTE	remote_snmp_inc
COMPUTE	remote_snmp_inc

• The script checks if the IP of the computer being monitored is “localhost” or “127.0.0.1”. In this case the IP is modified in the same way as when creating the agents.
• Finally, the corresponding module is created in Pandora FMS as long as it doesn’t exist previously. If the module already exists it doesn’t modify it.

In order to be able to locate them easily, the modules created in Pandora FMS have as their description the name of the graph in which this data was represented in Cacti:

We must bear in mind that Cacti can represent in the same graph the data of different checks, while Pandora FMS creates an independent module for each different data:

3. Last step to learn how to migrate Cacti to Pandora FMS: Data import

Finally, for those SNMP modules created by the migration (excluding those that already existed previously), the data collected by Cacti is imported in order to preserve the current history. To do this, the script can proceed in two ways:

• Using the RRD files located in a server directory where Pandora FMS is hosted.
• Downloading the RRD files directly from the server where Cacti is hosted via HTTP.

In any of the two cases, it takes the corresponding data for each one of the created modules and imports them in Pandora FMS database.
After migrating the environment and if there have been no errors, the script will return as output a summary with the number of agents and modules migrated, the number of modules you have created and those that have not been created because they already existed.

From that moment we will have the Pandora FMS server collecting new data, besides being able to show the SNMP data history that we had in Cacti:

With Pandora FMS we have many more monitoring options directly integrated in the system, thus allowing us to add new elements or manage the already the existing ones in a simpler way compared to how we would do it in Cacti, and with a much friendlier web interface.