DEV Community: Achraf Lasri

Building a Perl Script for High Availability Monitoring in Centreon

Achraf Lasri — Tue, 05 Sep 2023 15:43:36 +0000

In today's interconnected world, high availability is crucial for ensuring uninterrupted services. One way to achieve this is by monitoring the availability of hosts using tools like Centreon. In this blog post, we will explore how to create a Perl script that checks the high availability between two hosts in Centreon by monitoring their ping services.

Why Ping Services?

Ping is a commonly used network diagnostic utility that sends ICMP echo request packets to a target host and waits for an ICMP echo reply. By monitoring the ping service of two hosts, we can determine if they are reachable and responsive.

Requirements:

To follow along with this tutorial, you will need:

Perl installed on your system.
A working installation of Centreon or any other compatible monitoring platform.
Access privileges to configure monitors and execute scripts on the monitored hosts.

Step 1: Setting Up Centreon Ping Services

Before diving into scripting, ensure that both hosts have ping services configured in Centreon as part of their monitoring templates or custom configurations. This ensures that the necessary checks are already running from within Centreon's infrastructure.

Step 2: Creating the Perl Script

Open your favorite text editor and start creating your Perl script with these steps:

We start with the shebang (#!/usr/bin/perl) followed by some use statements that import necessary modules as strict, DBI (for database connectivity), Text::Diff and Pod::Text::Termcap.

#!/usr/bin/perl

use strict;
use DBI;
use Text::Diff;

use Pod::Text::Termcap;

use Time::localtime;

Next, we need to define constant definitions for different states: OK, WARNING, CRITICAL, UNKNOWN.

use constant OK       => 0;
use constant WARNING  => 1;
use constant CRITICAL => 2;
use constant UNKNOWN  => 3;

We also need to check if the required Monitoring::Plugin module or Nagios::Plugin module is available. If not found, it prints an error message and exits with an UNKNOWN state.

my $pkg_monitoring_available = 0;
BEGIN {
    my $pkg_nagios_available = 0;
    eval {
        require Monitoring::Plugin;
        require Monitoring::Plugin::Functions;
        require Monitoring::Plugin::Threshold;
        $pkg_monitoring_available = 1;
    };
    if (!$pkg_monitoring_available) {
        eval {
            require Nagios::Plugin;
            require Nagios::Plugin::Functions;
            require Nagios::Plugin::Threshold;
            *Monitoring::Plugin:: = *Nagios::Plugin::;
            $pkg_nagios_available = 1;
        };
            }
    if (!$pkg_monitoring_available && !$pkg_nagios_available) {
        print("UNKNOWN - Unable to find module Monitoring::Plugin or Nagios::Plugin\n");
        exit UNKNOWN;
    }
}

Two arguments (firstHostServiceId and secondHostServiceId) are added using add_arg() method to define command-line options for specifying service IDs of the first host and second host respectively.

my $mp = Monitoring::Plugin->new(
    shortname => "High Availability of two hosts",
    usage => "",
    extra => $extra_doc_output
);

$mp->add_arg(
    spec    => 'firstHostServiceId|id1=s',
    help    => 'service id of the first host status',
    required => 1
);

$mp->add_arg(
    spec    => 'secondHostServiceId|id2=s',
    help    => 'service id of the second host status',
    required => 1
);

Connects to Centreon MySQL database using DBI->connect()

# Connect to Centreon MySQL database
my $dbh = DBI->connect("DBI:mysql:centreon_storage:localhost", $user, $password)
  or die wrap_exit(UNKNOWN, $$DBI::errstr) ;

We need to prepare and execute SQL query to retrieve the output and name of the service associated with $firstService_id from the services table. The results are stored in variables $firstHostStatusOutput and $firstHostStatusName.

my $sth = $dbh->prepare("
  SELECT t1.output, t2.name
  FROM services t1
  JOIN hosts t2
  ON t1.host_id=t2.host_id
  WHERE service_id = ?
  LIMIT 1
");
$sth->execute($firstService_id)
  or die "Cannot execute SQL statement: $DBI::errstr";
my ($firstHostStatusOutput, $firstHostStatusName) = $sth->fetchrow_array;

$sth->execute($secondService_id)
  or die "Cannot execute SQL statement: $DBI::errstr";
my ($secondHostStatusOutput, $secondHostStatusName) = $sth->fetchrow_array;

Now we need to add the important part that checks the status of two hosts. If both hosts have an "OK" status, it adds a message stating that both hosts are OK. If either host has a "CR" (Critical) status, it sets the check state as CRITICAL and determines which host is critical to add an appropriate message. If neither condition matches, indicating that both hosts are considered critical, it sets the check state as CRITICAL and adds a generic message indicating that both hosts are critical.

my $check_state = OK;

# Check if both strings have 'OK'
if ($firstHostStatusOutput =~ /OK/ && $secondHostStatusOutput =~ /OK/) {
    $mp->add_message(
        $check_state,
        sprintf(
            'Both Hosts are OK'
        )
    );
}
# Check if either host has 'CR'
elsif ($firstHostStatusOutput =~ /CR/ || $secondHostStatusOutput =~ /CR/) {
    my $result = ($firstHostStatusOutput =~ /CR/) ? "$firstHostStatusName host is CRITICAL" : "$secondHostStatusName host is CRITICAL";
    $check_state = CRITICAL;
    $mp->add_message(
        $check_state,
        sprintf(
            $result
        )
    );
}
else {
    $check_state = CRITICAL;
    $mp->add_message(
        $check_state,
        sprintf(
            'Both hosts are CRITICAL.'
        )
    );
}

Step 3: Running the Script

Save the Perl script with a descriptive name like high_availability_check.pl, and make it executable by running chmod +x high_availability_check.pl

To run this script, open your terminal and navigate to its location. Then execute:

./high_availability_check.pl id1=<id1number> id2=<id2number>

The output will indicate whether both hosts are reachable or if high availability has been compromised.

After implementing the script in a service, the result can be viewed in Centreon.

In this blog post, we explored how to create a Perl script that checks high availability between two hosts in Centreon by monitoring their ping services. By incorporating this custom script into your monitoring workflow, you can proactively identify potential downtime issues and take appropriate actions to ensure uninterrupted services.

Remember, while ping-based checks provide basic connectivity information, additional service-level checks may be necessary depending on your specific requirements. Feel free to customize this script further or explore other monitoring techniques provided by Centreon to enhance your high availability monitoring capabilities.

Happy monitoring!

How to completely remove Centreon from your server

Achraf Lasri — Tue, 11 Apr 2023 02:37:01 +0000

Maybe you, as an IT engineer, have a faced a situation after you have done working with Centreon in a server or you want to transform your instance and the only way to do it is by reinstalling the platform, in this case you need to delete Centreon from your machine but you can't find a way to perfectly remove it. This post will show you how to completely uninstall Centreon from your Linux server.

What is Centreon in the first place

Centreon is an Open Source software package that lets you supervise all the infrastructure and applications comprising your information system.
Centreon is powered by PHP, with some TypeScript, JavaScript, Perl, shell, and Symfony 5.4. The software is bundled with tons of features to monitor the complete IT Infrastructure from Cloud-to-Edge for a clear and comprehensive view.

We are just simply going to delete it … what is the big deal ?

The simplest option to delete Centreon is by removing the centreon package using the package manager (yum, dnf, …).

However, it can affect some behavior problems if you install a new version. For instance, the web interface had a bug in the web installation and to fix it i had to remove the old files in /var/cache/centreon/symfony.

There are other files that used to have an old configuration and it can have an impact on the performance in the future or maybe the platform can stop working.

Lets fully remove Centreon then

Now that we are on the same page, it's time to clean your server.

You'll have to follow these steps to remove all centreon's files and folders that resides in your machine.

First, you need to stop and disable the service

systemctl stop centreon
systemctl disable centreon

After that we can proceed to remove the packages

yum remove centreon*

Now we have to get rid of the files in the /etc folder

rm -r /etc/centreon
rm -r /etc/centreon-broker
rm -r /etc/centreon-engine
rm -r /etc/centreon-gorgone

You can use the -f "force" flag to delete the files instantly without any prompts or warnings. However, extreme caution should be taken when using the rm command as a slight typo or mistake can result in unrecoverable system damage.

Supposing that you have a Poller instance, you don't have the centreon-broker module so you will have to execute just the other three.

We carry on with the Centreon files, we need also to delete them from the /var/lib folder.

rm -r /var/lib/centreon
rm -r /var/lib/centreon-broker
rm -r /var/lib/centreon-engine
rm -r /var/lib/centreon-gorgone

In the /usr folder we will find other Centreon folders, so let's just delete them.

rm -r /usr/share/centreon
rm -r /usr/lib/centreon

We still got the logs in the /var/log folder, so we have to execute these commands.

rm -r /var/log/centreon
rm -r /var/log/centreon-broker
rm -r /var/log/centreon-engine
rm -r /var/log/centreon-gorgone

And finally, we just need to delete the cache in the /var/cache directory.

rm -r /var/cache/centreon

With that, you are free to install a new version of your Centreon's instance whether it can be a central server, remote server or just a poller.

That’s it for now.

Keep building.