ASRS Projet 7 : Déploiement d'une infrastructure de supervision

⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Contexte et objectifs

Dans le cadre d’une mission freelance pour HealthData Corp, une entreprise spécialisée dans la mise à disposition de données de santé, j’ai été chargé de mettre en œuvre un système de supervision complet. L’entreprise faisait face à des problèmes de performance sur son site web et souhaitait anticiper les incidents avant qu’ils n’impactent les utilisateurs.

Exigences du Projet

Le projet devait permettre de :

• Superviser en temps réel les ressources systèmes et applicatives
• Centraliser les logs pour faciliter l’analyse et la traçabilité
• Anticiper les incidents grâce à des seuils d’alerte configurables
• Fournir une documentation pour la gestion opérationnelle des alertes

La particularité de ce projet résidait dans son contexte médical, imposant des exigences strictes en termes de traçabilité et de conformité (RGPD, audit de sécurité).

Architecture déployée

L’infrastructure repose sur deux machines virtuelles Debian 12 déployées dans un environnement virtualisé :

Justification de l’architecture

La séparation des responsabilités est un point clé de cette architecture : le serveur de supervision est isolé du serveur applicatif, ce qui permet de superviser même en cas de problème majeur sur l’application.

En termes de scalabilité, l’architecture NRPE (Nagios Remote Plugin Executor) offre une grande flexibilité. Elle permet d’ajouter facilement de nouveaux serveurs à superviser sans modifier profondément l’infrastructure.

La centralisation des logs via RSyslog en mode serveur/client fournit une traçabilité indispensable pour l’audit de sécurité et la conformité réglementaire. C’est un élément essentiel dans le contexte médical.

Concernant la performance, Nagios Core compilé depuis les sources offre de meilleures performances et une plus grande maîtrise de la configuration que les packages pré-compilés.

Installation et configuration de Nagios Core

Compilation depuis les Sources

Le choix de compiler Nagios depuis les sources plutôt que d’utiliser un package APT répond à plusieurs besoins :

• Maîtrise totale de la version et des modules
• Optimisation pour le matériel spécifique
• Apprentissage approfondi du processus de compilation
• Flexibilité pour les futures évolutions

Installation des dépendances :

1
2
3
4

sudo apt update
sudo apt install -y build-essential apache2 apache2-utils \
    libgd-dev libssl-dev libapache2-mod-php php php-gd \
    unzip wget autoconf gcc libc6 make

Téléchargement et compilation de Nagios Core 4.5.1 :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

cd /tmp
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.5.1.tar.gz
tar xzf nagios-4.5.1.tar.gz
cd nagios-4.5.1

./configure --with-httpd-conf=/etc/apache2/sites-enabled
make all

sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo make install-webconf

Configuration Apache et authentification

Création de l’utilisateur administrateur Nagios :

1

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Activation des modules Apache nécessaires :

1
2

sudo a2enmod rewrite cgi
sudo systemctl restart apache2

Vérification de la configuration :

1

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Résultat attendu :

Total Warnings: 0
Total Errors:   0

Installation des plugins Nagios

Les plugins officiels fournissent les commandes de vérification de base :

1
2
3
4
5
6
7
8

cd /tmp
wget https://nagios-plugins.org/download/nagios-plugins-2.4.6.tar.gz
tar xzf nagios-plugins-2.4.6.tar.gz
cd nagios-plugins-2.4.6

./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
sudo make install

Configuration NRPE pour la supervision distante

Installation NRPE sur le serveur applicatif

NRPE (Nagios Remote Plugin Executor) permet l’exécution de plugins sur les serveurs distants de manière sécurisée.

Installation :

1
2

sudo apt update
sudo apt install -y nagios-nrpe-server nagios-plugins

Configuration dans /etc/nagios/nrpe.cfg :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Autorisation du serveur Nagios
allowed_hosts=127.0.0.1,::1,172.16.10.100

# Configuration du port (par défaut 5666)
server_port=5666

# Commandes personnalisées pour les sondes
command[check_users]=/usr/lib/nagios/plugins/check_users -w 1 -c 2
command[check_load]=/usr/lib/nagios/plugins/check_load -r -w 0.85,0.80,0.75 -c 0.98,0.95,0.90
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 70% -c 80% -p /
command[check_mem]=/usr/lib/nagios/plugins/check_mem.pl -w 70 -c 85
command[check_http_local]=/usr/lib/nagios/plugins/check_http -H localhost -u /
command[check_mysql]=/usr/lib/nagios/plugins/check_mysql -H localhost -u nagios_check -p 'SecureP@ss2025'

Script personnalisé pour la supervision mémoire

Le plugin check_mem.pl n’étant pas fourni par défaut, j’ai créé un script Perl personnalisé :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#!/usr/bin/perl -w

use strict;
use Getopt::Long;

my ($warning, $critical);

GetOptions(
    "w=i" => \$warning,
    "c=i" => \$critical
);

# Récupération des informations mémoire
open(my $fh, '<', '/proc/meminfo') or die "Cannot open /proc/meminfo: $!";
my %mem;
while (<$fh>) {
    if (/^(\w+):\s+(\d+)/) {
        $mem{$1} = $2;
    }
}
close($fh);

# Calcul du pourcentage utilisé
my $total = $mem{MemTotal};
my $available = $mem{MemAvailable} || ($mem{MemFree} + $mem{Buffers} + $mem{Cached});
my $used = $total - $available;
my $percent_used = int(($used / $total) * 100);

# Détermination de l'état
my $state;
my $exit_code;

if ($percent_used >= $critical) {
    $state = "CRITICAL";
    $exit_code = 2;
} elsif ($percent_used >= $warning) {
    $state = "WARNING";
    $exit_code = 1;
} else {
    $state = "OK";
    $exit_code = 0;
}

# Sortie formatée pour Nagios
my $used_mb = int($used / 1024);
my $total_mb = int($total / 1024);
print "$state - Memory usage: ${percent_used}% (${used_mb}MB/${total_mb}MB) | ";
print "memory=${percent_used}%;${warning};${critical};0;100\n";

exit $exit_code;

Installation et permissions :

1
2
3

sudo cp check_mem.pl /usr/lib/nagios/plugins/
sudo chmod +x /usr/lib/nagios/plugins/check_mem.pl
sudo chown nagios:nagios /usr/lib/nagios/plugins/check_mem.pl

Test de connectivité NRPE

Depuis le serveur Nagios :

1

/usr/lib/nagios/plugins/check_nrpe -H 172.16.10.200

Résultat attendu :

NRPE v4.1.0

Configuration des sondes de supervision

Définition de l’hôte dans Nagios

Fichier /usr/local/nagios/etc/objects/healthdata-servers.cfg :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

define host {
    use                     linux-server
    host_name               app-server
    alias                   Application Server - WordPress
    address                 172.16.10.200
    max_check_attempts      3
    check_period            24x7
    notification_interval   30
    notification_period     24x7
    contact_groups          admins
}

Configuration des 7 sondes requises

1. Sonde RAM (Mémoire)

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     RAM
    check_command           check_nrpe!check_mem
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

Seuils configurés :

• WARNING : 70% d’utilisation
• CRITICAL : 85% d’utilisation

Ces seuils permettent d’anticiper une saturation mémoire tout en évitant les fausses alertes. À 70%, l’équipe peut investiguer avant que le service ne soit impacté.

2. Sonde CPU Load (Charge Processeur)

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     CPU
    check_command           check_nrpe!check_load
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

Seuils configurés (dégressifs) :

• WARNING : 0.85 (1min) / 0.80 (5min) / 0.75 (15min)
• CRITICAL : 0.98 (1min) / 0.95 (5min) / 0.90 (15min)

Les seuils dégressifs permettent de différencier un pic temporaire (toléré) d’une charge persistante (problématique). Plus la période d’observation est longue, plus le seuil devient strict.

3. Sonde Disk Space (Espace Disque)

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     Disk
    check_command           check_nrpe!check_disk
    check_interval          10
    retry_interval          2
    max_check_attempts      3
}

Seuils configurés :

• WARNING : 70% d’utilisation
• CRITICAL : 80% d’utilisation

L’espace disque évolue progressivement. Un seuil à 80% laisse le temps d’agir avant saturation complète, qui pourrait causer des corruptions de données.

4. Sonde Current Users (Utilisateurs Connectés)

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     Current Users
    check_command           check_nrpe!check_users
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

Seuils configurés :

• WARNING : 1 utilisateur connecté
• CRITICAL : 2 utilisateurs connectés

Sur un serveur de production, les connexions SSH doivent être exceptionnelles. Ces seuils bas détectent rapidement une activité anormale (maintenance non planifiée, intrusion potentielle).

5. Sonde HTTP Service

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     HTTP
    check_command           check_nrpe!check_http_local
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

Vérification : Disponibilité du service Apache sur le port 80.

La détection immédiate d’un arrêt du serveur web est cruciale, car l’Apache est un élément critique pour un site accessible au public.

6. Sonde Index Page (Page d’Accueil)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

define service {
    use                     generic-service
    host_name               app-server
    service_description     Index Page
    check_command           check_http_url
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

define command {
    command_name    check_http_url
    command_line    $USER1$/check_http -H $HOSTADDRESS$ -u / -s "WordPress"
}

Vérification : Présence du mot-clé “WordPress” dans la page d’accueil.

Cette sonde détecte les problèmes applicatifs (page blanche, erreur PHP) que la simple vérification HTTP ne détecterait pas.

7. Sonde MySQL/MariaDB

1
2
3
4
5
6
7
8
9

define service {
    use                     generic-service
    host_name               app-server
    service_description     MySQL
    check_command           check_nrpe!check_mysql
    check_interval          5
    retry_interval          1
    max_check_attempts      3
}

Vérification : Connexion à la base de données MariaDB.

WordPress nécessite un accès permanent à la base. Cette sonde détecte tout problème de connexion, de credentials ou d’arrêt du service MySQL.

Centralisation des logs avec RSyslog

Configuration du serveur RSyslog (monitor-srv)

RSyslog permet de centraliser tous les logs du SI sur un seul serveur, facilitant ainsi l’analyse, l’audit et la corrélation d’événements.

Fichier /etc/rsyslog.conf - Activation du mode serveur :

# Écoute UDP (protocole léger)
module(load="imudp")
input(type="imudp" port="514")

# Écoute TCP (protocole fiable)
module(load="imtcp")
input(type="imtcp" port="514")

# Template pour organisation des logs
$template RemoteLogsDynamic,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogsDynamic
& stop

La justification de la double écoute UDP/TCP réside dans les caractéristiques de chacun :

• UDP : rapide, faible overhead, acceptable pour les logs non critiques
• TCP : fiable, garantit la livraison, essentiel pour les logs d’audit de sécurité

Configuration du client RSyslog (app-srv)

Fichier /etc/rsyslog.d/50-forward.conf :

# Envoi de tous les logs vers le serveur central
*.* @@172.16.10.100:514  # TCP (deux @)
*.* @172.16.10.100:514   # UDP (un @)

Syntaxe RSyslog :

• @@ : Envoi en TCP
• @ : Envoi en UDP
• *.* : Tous les niveaux de priorité, toutes les facilités

Organisation automatique des logs

Grâce au template RemoteLogsDynamic, les logs sont automatiquement organisés selon cette arborescence :

/var/log/remote/
├── app-srv/
│   ├── apache2.log
│   ├── cron.log
│   ├── systemd.log
│   ├── sshd.log
│   ├── sudo.log
│   └── mysqld.log
└── monitor-srv/
    ├── nagios.log
    └── systemd.log

Cette organisation offre plusieurs avantages :

• Séparation par serveur : identification immédiate de la source
• Séparation par programme : facilite le troubleshooting ciblé
• Scalabilité : ajout automatique de nouveaux serveurs sans modification
• Analyse forensique : corrélation facile des événements entre services

Validation de la centralisation

Test d’envoi de logs depuis app-srv :

1

logger -t test-rsyslog "Test de centralisation des logs"

Vérification sur monitor-srv :

1

sudo tail -f /var/log/remote/app-srv/test-rsyslog.log

Résultat attendu : Le message apparaît instantanément sur le serveur central.

Tests et validation de l’infrastructure

Validation de la configuration Nagios

Vérification syntaxique :

1

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Résultat obtenu :

Total Warnings: 0
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

Nombre d’objets configurés :

• Services : 15
• Hosts : 2 (localhost + app-server)
• Commands : 24

Tests des sondes en conditions réelles

Test de la sonde RAM

Déclenchement d’alerte avec stress-ng :

1
2
3
4
5

# Installation de l'outil de stress test
sudo apt install -y stress-ng

# Génération d'une charge mémoire progressive
stress-ng --vm 1 --vm-bytes 70% --timeout 60s

Résultat dans Nagios :

• État : WARNING après ~30 secondes
• Message : RAM WARNING - Memory usage: 72% (2048MB/2048MB)

Passage en CRITICAL :

1

stress-ng --vm 2 --vm-bytes 85% --timeout 60s

Résultat :

• État : CRITICAL après ~15 secondes
• Message : RAM CRITICAL - Memory usage: 87% (2470MB/2048MB)

Test de la sonde CPU

Déclenchement progressif d’alerte :

1
2
3
4
5

# WARNING (85% sur 1 minute)
stress-ng --cpu 1 --cpu-load 85 --timeout 90s

# CRITICAL (98% sur 1 minute)
stress-ng --cpu 2 --cpu-load 98 --timeout 90s

Observations importantes :

• Le check_load utilise la load average (nombre de processus en attente)
• Sur un système 2 cores, une load de 1.70 correspond à 85% d’utilisation
• La détection est progressive : 1min → 5min → 15min

Test de la sonde Disk Space

Création d’un fichier volumineux :

1
2
3
4
5
6
7
8

# Vérification de l'espace disponible
df -h /

# Création d'un fichier de 15GB (pour atteindre 75%)
sudo dd if=/dev/zero of=/tmp/testfile bs=1G count=15

# Nettoyage après test
sudo rm /tmp/testfile

Résultat dans Nagios :

• État : WARNING à 72% d’utilisation
• Message : DISK WARNING - free space: / 5214 MB (28% inode=97%)

Test de la sonde Current Users

Simulation de connexions multiples :

1
2
3

# Connexion depuis plusieurs terminaux SSH
# Terminal 1 : ssh user@172.16.10.200
# Terminal 2 : ssh user@172.16.10.200

Résultat dans Nagios :

• 1 utilisateur : OK
• 2 utilisateurs : WARNING
• 3 utilisateurs : CRITICAL

Tests de résilience

Test d’arrêt du service Apache

1

sudo systemctl stop apache2

Résultats Nagios :

• HTTP : CRITICAL - Connection refused
• Index Page : CRITICAL - Connection refused

Logs RSyslog centralisés :

app-srv systemd: Stopping The Apache HTTP Server...
app-srv systemd: Stopped The Apache HTTP Server

Test d’arrêt MySQL

1

sudo systemctl stop mariadb

Résultats Nagios :

• MySQL : CRITICAL - Can’t connect to local MySQL server
• Index Page : WARNING - Database connection error

Points critiques et difficultés rencontrées

1. Seuils CPU avec Load Average

Le problème initial concernait la confusion entre pourcentage CPU et load average.

Explication technique :

• Pourcentage CPU : temps processeur utilisé (0-100% par core)
• Load Average : nombre de processus en attente d’exécution

La solution mise en place sur un système 2 cores :

• Load de 1.0 = 50% d’utilisation moyenne
• Load de 1.70 = 85% d’utilisation moyenne
• Load de 2.0 = 100% d’utilisation (saturation)

Les seuils dégressifs permettent de détecter :

• 1 minute : pic ponctuel (toléré jusqu’à 0.85)
• 5 minutes : charge soutenue (alerte à 0.80)
• 15 minutes : problème persistant (alerte à 0.75)

2. Plugin check_mem absent

Le plugin check_mem n’existe pas dans la distribution standard de nagios-plugins. Pour résoudre ce problème :

1. Création d’un script Perl personnalisé
2. Lecture de /proc/meminfo pour les données mémoire
3. Calcul du pourcentage avec prise en compte des buffers/cache
4. Sortie formatée selon les standards Nagios (état + données de performance)

Points d’attention importants :

• Utilisation de MemAvailable (kernel 3.14+) plutôt que MemFree
• Prise en compte des buffers et cache (mémoire récupérable)
• Format de sortie : STATE - Message | perfdata

3. Configuration NRPE et sécurité

Le problème initial était l’erreur “CHECK_NRPE: Socket timeout after 10 seconds”. Les causes identifiées :

1. Firewall bloquant le port 5666
2. Configuration allowed_hosts incorrecte dans nrpe.cfg
3. Service NRPE non démarré

La solution complète implémentée :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. Vérifier le service
sudo systemctl status nagios-nrpe-server

# 2. Vérifier le port en écoute
sudo ss -tuln | grep 5666

# 3. Configuration allowed_hosts
allowed_hosts=127.0.0.1,::1,172.16.10.100

# 4. Test depuis Nagios
/usr/lib/nagios/plugins/check_nrpe -H 172.16.10.200 -c check_users

Mesures de sécurisation additionnelle :

• NRPE n’écoute que sur l’IP interne (172.16.10.200)
• Liste blanche stricte des IPs autorisées
• Pas de commandes dangereuses exposées via NRPE

4. Organisation RSyslog complexe

Le problème initial était la gestion des logs mélangés dans un seul fichier, difficiles à analyser. La solution adoptée :

Template avancé avec double niveau d’organisation :

$template RemoteLogsDynamic,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogsDynamic
& stop

Avantages observés :

• Séparation automatique par serveur source
• Séparation automatique par programme
• Aucune configuration additionnelle lors de l’ajout de serveurs
• Facilité d’analyse avec tail -f /var/log/remote/app-srv/apache2.log

Configuration de la rotation des logs :

# /etc/logrotate.d/rsyslog-remote
/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Résultats obtenus et métriques

État opérationnel

Au terme du déploiement, l’infrastructure présente les caractéristiques suivantes :

Supervision Nagios :

• 15 services supervisés
• 2 hôtes définis
• Intervalle de vérification : 5 minutes (services critiques) à 10 minutes (espace disque)
• Taux de disponibilité cible : 99,9%
• 0 warning, 0 error dans la configuration

Centralisation RSyslog :

• 2 serveurs clients configurés
• 40+ fichiers de logs distincts
• Volume quotidien : ~50 MB de logs
• Rétention : 30 jours
• Double protocole TCP/UDP opérationnel

Tableaux de bord Nagios

L’interface web Nagios fournit plusieurs vues essentielles :

Vue Tactical Overview :

• Nombre d’hôtes UP/DOWN
• Nombre de services OK/WARNING/CRITICAL
• Santé globale du SI

Vue Services :

• État détaillé de chaque sonde
• Dernière vérification
• Durée depuis le dernier changement d’état
• Nombre de tentatives de vérification

Vue Performance Data :

• Graphiques d’évolution sur 24h/7j/30j
• Historique des métriques (RAM, CPU, Disk)
• Tendances et prédictions

Points de sécurité et bonnes pratiques

Sécurisation de l’accès Nagios

Authentification Basic Apache :

1
2
3
4
5
6

<Directory "/usr/local/nagios/sbin">
    AuthType Basic
    AuthName "Nagios Access"
    AuthUserFile /usr/local/nagios/etc/htpasswd.users
    Require valid-user
</Directory>

Recommandations additionnelles :

• Changer le mot de passe par défaut (nagiosadmin)
• Utiliser des mots de passe forts (>16 caractères, complexes)
• Envisager une authentification LDAP/AD pour les grandes structures
• Mettre en place HTTPS avec Let’s Encrypt

Principe du moindre privilège

Utilisateur nagios :

• Droits limités aux seuls répertoires nécessaires
• Pas de privilèges sudo
• Isolation via systemd (PrivateTmp, NoNewPrivileges)

Plugin NRPE :

• Commandes prédéfinies uniquement (pas d’exécution arbitraire)
• Liste blanche IP stricte
• Pas de commandes système dangereuses exposées

Isolation réseau

Recommandations de segmentation :

┌─────────────────────────────────────────┐
│   DMZ (172.16.10.0/24)                  │
│   ├── app-srv (172.16.10.200)           │
│   └── Accès public port 80/443          │
└────────────┬────────────────────────────┘
             │ Firewall
┌────────────┴────────────────────────────┐
│   LAN Management (172.16.20.0/24)       │
│   ├── monitor-srv (172.16.20.100)       │
│   └── Accès restreint équipe IT         │
└─────────────────────────────────────────┘

Règles firewall recommandées :

• Autoriser port 5666 (NRPE) uniquement depuis monitor-srv
• Autoriser port 514 (RSyslog) uniquement depuis monitor-srv
• Bloquer tout accès direct à monitor-srv depuis l’extérieur

Documentation opérationnelle

Procédures d’intervention par sonde

Sonde RAM en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 1. Identifier les processus gourmands
top -o %MEM

# 2. Analyser la répartition mémoire
free -h
ps aux --sort=-%mem | head -10

# 3. Vérifier les logs pour détection de memory leak
sudo journalctl -xe | grep -i "out of memory"

# 4. Si nécessaire, redémarrer le service problématique
sudo systemctl restart <service>

Mesures préventives :

• Augmenter la RAM si la consommation est structurelle
• Optimiser les configurations applicatives (PHP memory_limit, InnoDB buffer pool)
• Mettre en place un swap si inexistant

Sonde CPU en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 1. Identifier les processus consommateurs
top -o %CPU
htop

# 2. Analyser les tâches cron actives
sudo crontab -l -u www-data
ps aux | grep cron

# 3. Vérifier les attaques potentielles (crypto-mining)
sudo netstat -tunap | grep ESTABLISHED

Mesures préventives :

• Optimiser les requêtes SQL lentes
• Mettre en cache les contenus statiques (varnish, redis)
• Augmenter les ressources CPU si charge légitime

Sonde Disk en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. Identifier les répertoires volumineux
du -sh /* | sort -h
du -sh /var/* | sort -h

# 2. Nettoyer les logs anciens
sudo journalctl --vacuum-time=7d
sudo rm /var/log/*.gz

# 3. Nettoyer le cache APT
sudo apt clean
sudo apt autoclean

# 4. Vérifier les fichiers temporaires
sudo find /tmp -type f -atime +7 -delete

Mesures préventives :

• Rotation des logs correctement configurée
• Surveillance de la croissance des bases de données
• Planifier une extension de disque si nécessaire

Sonde Current Users en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. Lister les utilisateurs connectés
who
w

# 2. Analyser l'historique des connexions
last | head -20
sudo journalctl -u ssh

# 3. Vérifier les tentatives de connexion échouées
sudo grep "Failed password" /var/log/auth.log | tail -20

# 4. Si connexion suspecte, déconnecter
sudo pkill -KILL -u <username>

Mesures préventives :

• Désactiver l’authentification par mot de passe SSH (clés uniquement)
• Configurer Fail2Ban pour bloquer les tentatives répétées
• Auditer régulièrement les comptes utilisateurs

Sonde HTTP/Index en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. Vérifier l'état du service Apache
sudo systemctl status apache2

# 2. Consulter les logs d'erreur
sudo tail -100 /var/log/apache2/error.log

# 3. Tester l'accès en local
curl -I http://localhost

# 4. Redémarrer Apache si nécessaire
sudo systemctl restart apache2

Mesures préventives :

• Monitorer les erreurs PHP dans les logs
• Configurer un système de notification automatique
• Mettre en place un health check automatisé

Sonde MySQL en alerte

Actions immédiates :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. Vérifier l'état du service
sudo systemctl status mariadb

# 2. Consulter les logs MySQL
sudo tail -100 /var/log/mysql/error.log

# 3. Tester la connexion
mysql -u root -p -e "SELECT VERSION();"

# 4. Vérifier les processus bloquants
mysql -u root -p -e "SHOW FULL PROCESSLIST;"

# 5. Redémarrer si nécessaire
sudo systemctl restart mariadb

Mesures préventives :

• Optimiser les requêtes lentes (slow query log)
• Configurer correctement InnoDB (buffer pool size)
• Mettre en place des sauvegardes régulières

Évolutions possibles

Haute disponibilité

Nagios en cluster :

• Déploiement d’un second serveur Nagios (master/slave)
• Synchronisation automatique des configurations
• Failover automatique en cas de panne du master

Base de données répliquée :

• Configuration MySQL en Master-Master ou Master-Slave
• Utilisation de Galera Cluster pour MariaDB
• Load balancing avec ProxySQL

Automatisation et DevOps

Infrastructure as Code :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Exemple Ansible pour déploiement Nagios
- name: Install Nagios Core
  hosts: monitoring
  roles:
    - nagios-core
    - nagios-plugins
    - nrpe-server

- name: Configure services monitoring
  hosts: monitoring
  tasks:
    - name: Deploy service definitions
      template:
        src: services.cfg.j2
        dest: /usr/local/nagios/etc/objects/services.cfg

CI/CD :

• Validation automatique des configurations Nagios dans GitLab CI
• Tests unitaires des plugins personnalisés
• Déploiement automatique via Ansible/Terraform

Monitoring avancé

Graphiques de performance :

• Intégration de PNP4Nagios ou Graphite
• Visualisation des métriques sur 1 an
• Prédiction de tendances (Machine Learning)

Alertes intelligentes :

• Configuration de seuils dynamiques (basés sur l’historique)
• Corrélation d’événements (si CPU ET RAM CRITICAL → alerte majeure)
• Notification multi-canal (email, SMS, Slack, PagerDuty)

Conformité et audit

Traçabilité renforcée :

• Archivage des logs RSyslog sur stockage immuable
• Chiffrement des logs en transit (TLS pour RSyslog)
• Signature des logs pour non-répudiation

Tableaux de bord conformité :

• Dashboard dédié aux exigences RGPD
• Reporting automatisé pour les audits ISO 27001
• Alertes en cas de non-conformité détectée

Conclusion

Ce projet de mise en place d’une infrastructure de supervision avec Nagios Core et RSyslog a permis de créer un système robuste et évolutif, répondant aux exigences strictes du secteur de la santé. L’architecture déployée offre une visibilité complète grâce à sept sondes qui couvrent les aspects critiques : ressources, services et applicatif.

La traçabilité centralisée via RSyslog fournit une base d’audit indispensable pour la conformité réglementaire, point essentiel dans le contexte médical. Les seuils calibrés permettent une réactivité opérationnelle en anticipant les incidents avant qu’ils n’impactent les utilisateurs. L’architecture NRPE garantit aussi une excellente scalabilité en facilitant l’ajout de nouveaux serveurs sans refonte majeure.

Les difficultés rencontrées lors du déploiement (configuration NRPE, seuils CPU, organisation RSyslog) ont été autant d’occasions d’approfondir la compréhension des mécanismes de supervision et de mettre en place des solutions pérennes. La documentation opérationnelle fournit permet à l’équipe technique de réagir efficacement en cas d’alerte.

L’infrastructure actuelle constitue une base solide pour les évolutions futures, qu’il s’agisse de haute disponibilité, d’automatisation via DevOps, ou de conformité renforcée. Le système de supervision est désormais un élément central du SI de HealthData Corp, garantissant la disponibilité et la performance des services critiques.

Configuration testée avec :

• Nagios Core 4.5.1 (compilé depuis les sources)
• Nagios Plugins 2.4.6
• NRPE 4.1.0
• Apache 2.4.57
• RSyslog 8.2312.0
• Debian 12 (Bookworm)
• WordPress 6.4 / MariaDB 10.11