1. Fondamentaux du monitoring

1.1 Types de monitoring

Le monitoring informatique se décompose en plusieurs catégories complémentaires :

Type	Description	Exemples de métriques
Infrastructure	Supervision du matériel et des OS (serveurs, VM, stockage)	CPU, RAM, disque, température, uptime
Applicatif	Surveillance des applications et services métier	Temps de réponse, taux d'erreur, requêtes/s, files d'attente
Réseau	Supervision des équipements réseau et du trafic	Bande passante, latence, perte de paquets, état des ports
Logs	Collecte, agrégation et analyse des journaux	Erreurs applicatives, événements système, audit de sécurité

1.2 Protocoles de supervision

Protocole	Type	Port(s)	Usage
SNMP v1	Agentless	UDP 161/162	Ancien, communauté en clair, à éviter en production
SNMP v2c	Agentless	UDP 161/162	Amélioration de v1, communauté en clair, très répandu
SNMP v3	Agentless	UDP 161/162	Authentification + chiffrement, recommandé en production
WMI	Agentless	TCP 135 + dynamique	Supervision Windows native (performances, services, événements)
IPMI	Agentless	UDP 623	Gestion matérielle hors bande (iLO, iDRAC, BMC)
Agent installé	Agent	Variable	Agent sur l'hôte (Zabbix Agent, NRPE, Node Exporter, etc.)
SSH	Agentless	TCP 22	Exécution de commandes à distance sur Linux/Unix

1.3 Métriques clés à surveiller

Serveurs :

• CPU : % utilisation, load average, iowait
• Mémoire : % utilisée, swap utilisé, cache/buffers
• Disque : % espace utilisé, IOPS, latence I/O, état SMART/RAID
• Réseau : bande passante in/out, erreurs, drops
• Processus : nombre, état des services critiques, zombies

Applications :

• Disponibilité : uptime, health check HTTP (codes 2xx/5xx)
• Performance : temps de réponse (p50, p95, p99), throughput
• Saturation : files d'attente, connexions actives, threads
• Erreurs : taux d'erreur, exceptions non gérées

1.4 SLA, SLO et SLI

Terme	Définition	Exemple
SLA (Service Level Agreement)	Contrat entre fournisseur et client définissant le niveau de service garanti	Disponibilité 99.9% = max 8h45 d'indisponibilité/an
SLO (Service Level Objective)	Objectif interne plus strict que le SLA	Objectif interne de 99.95% de disponibilité
SLI (Service Level Indicator)	Métrique mesurée pour évaluer le respect du SLO	% de requêtes avec réponse < 200ms

1.5 Niveaux de sévérité des alertes

Niveau	Couleur	Description	Action requise
OK	Vert	Tout fonctionne normalement	Aucune
Information	Bleu	Événement informatif, pas de problème	Aucune, suivi uniquement
Warning	Jaune	Seuil d'avertissement atteint, dégradation possible	Planifier une intervention
Critical	Rouge	Service indisponible ou seuil critique dépassé	Intervention immédiate
Unknown	Gris/Orange	Impossible de déterminer l'état (timeout, erreur de check)	Vérifier la connectivité et la configuration

2. Nagios

2.1 Présentation et architecture

Nagios Core est le moteur open source de supervision le plus historique. Il fonctionne par polling : le serveur Nagios exécute des plugins (check commands) à intervalles réguliers pour tester l'état des hôtes et services.

Architecture typique :

• Nagios Core : moteur d'ordonnancement et de notification
• Plugins : scripts/binaires exécutés pour effectuer les checks (nagios-plugins)
• NRPE : agent distant pour exécuter des checks locaux sur les hôtes Linux
• NSClient++ : agent pour superviser les hôtes Windows
• Interface web : CGI pour la visualisation (ou Thruk, interface moderne)

2.2 Installation sur Ubuntu

# Prérequis
sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-gd
sudo apt install -y autoconf gcc libc6 make wget unzip libgd-dev libssl-dev

# Créer l'utilisateur nagios
sudo useradd nagios
sudo groupadd nagcmd
sudo usermod -aG nagcmd nagios
sudo usermod -aG nagcmd www-data

# Télécharger et compiler Nagios Core
cd /tmp
wget https://github.com/NagiosEnterprises/nagioscore/releases/download/nagios-4.5.2/nagios-4.5.2.tar.gz
tar xzf nagios-4.5.2.tar.gz
cd nagios-4.5.2
./configure --with-command-group=nagcmd
make all
sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo make install-webconf

# Créer l'utilisateur web admin
sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

# Installer les plugins Nagios
cd /tmp
wget https://github.com/nagios-plugins/nagios-plugins/releases/download/release-2.4.10/nagios-plugins-2.4.10.tar.gz
tar xzf nagios-plugins-2.4.10.tar.gz
cd nagios-plugins-2.4.10
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
sudo make install

# Démarrer Nagios
sudo systemctl enable nagios
sudo systemctl start nagios
sudo systemctl restart apache2

2.3 Fichiers de configuration principaux

Fichier	Rôle
/usr/local/nagios/etc/nagios.cfg	Configuration principale (chemins, intervalles, directives globales)
/usr/local/nagios/etc/cgi.cfg	Configuration de l'interface web (autorisations, rafraîchissement)
/usr/local/nagios/etc/objects/commands.cfg	Définition des commandes de check et notification
/usr/local/nagios/etc/objects/contacts.cfg	Définition des contacts et groupes de contacts
/usr/local/nagios/etc/objects/timeperiods.cfg	Périodes de temps (24x7, heures ouvrées, etc.)
/usr/local/nagios/etc/objects/templates.cfg	Templates réutilisables pour hôtes et services

2.4 Définition d'un hôte

# /usr/local/nagios/etc/objects/serveurs.cfg
define host {
    use                     linux-server        ; template hérité
    host_name               srv-web-01
    alias                   Serveur Web Production
    address                 192.168.1.10
    max_check_attempts      5
    check_period            24x7
    notification_interval   30                  ; minutes entre les re-notifications
    notification_period     24x7
    contacts                admin-it
    notification_options    d,u,r               ; down, unreachable, recovery
}

define hostgroup {
    hostgroup_name          serveurs-web
    alias                   Serveurs Web
    members                 srv-web-01,srv-web-02
}

2.5 Définition d'un service

# Vérifier l'espace disque via NRPE
define service {
    use                     generic-service
    host_name               srv-web-01
    service_description     Espace disque /
    check_command           check_nrpe!check_disk
    check_interval          5                   ; toutes les 5 minutes
    retry_interval          1
    max_check_attempts      4
    notification_interval   30
    notification_period     24x7
    contacts                admin-it
}

# Vérifier un site web HTTP
define service {
    use                     generic-service
    host_name               srv-web-01
    service_description     HTTP Site Web
    check_command           check_http!-H www.example.com -u /health -s "OK"
    check_interval          2
    retry_interval          1
    max_check_attempts      3
}

2.6 Plugins essentiels

Plugin	Usage	Exemple
check_ping	Vérifie la connectivité ICMP	check_ping -H 192.168.1.1 -w 100,20% -c 500,60%
check_http	Vérifie un serveur HTTP/HTTPS	check_http -H www.site.com -S -p 443 -u /health
check_disk	Vérifie l'espace disque	check_disk -w 20% -c 10% -p /
check_load	Vérifie la charge CPU (load average)	check_load -w 5,4,3 -c 10,8,6
check_procs	Vérifie les processus	check_procs -w 250 -c 400 -s RSZDT
check_tcp	Vérifie la connectivité TCP sur un port	check_tcp -H 192.168.1.5 -p 3306 -w 1 -c 3

2.7 NRPE (Nagios Remote Plugin Executor)

NRPE permet d'exécuter des plugins localement sur les hôtes distants :

# Installation sur l'hôte distant (Ubuntu)
sudo apt install -y nagios-nrpe-server nagios-plugins

# Configuration NRPE : /etc/nagios/nrpe.cfg
# Autoriser le serveur Nagios
allowed_hosts=127.0.0.1,192.168.1.100

# Définir les commandes locales
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_load]=/usr/lib/nagios/plugins/check_load -w 5,4,3 -c 10,8,6
command[check_mem]=/usr/lib/nagios/plugins/check_mem -w 80 -c 90
command[check_procs]=/usr/lib/nagios/plugins/check_procs -w 250 -c 400
command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 20% -c 10%

# Redémarrer NRPE
sudo systemctl restart nagios-nrpe-server

Depuis le serveur Nagios, tester la connexion NRPE :

# Test de connectivité NRPE
/usr/local/nagios/libexec/check_nrpe -H 192.168.1.10

# Exécuter une commande distante
/usr/local/nagios/libexec/check_nrpe -H 192.168.1.10 -c check_disk

2.8 Notifications

# Définition d'un contact
define contact {
    contact_name            admin-it
    alias                   Administrateur IT
    email                   admin@example.com
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r     ; warning, unknown, critical, recovery
    host_notification_options       d,u,r       ; down, unreachable, recovery
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
}

# Commande de notification par email
define command {
    command_name    notify-service-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\nInfo: $SERVICEOUTPUT$\nDate: $LONGDATETIME$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}

2.9 Concept de templates

Les templates permettent de factoriser la configuration via l'héritage :

# Template de base pour les serveurs Linux
define host {
    name                    linux-server
    use                     generic-host
    check_period            24x7
    check_interval          5
    retry_interval          1
    max_check_attempts      10
    check_command           check-host-alive
    notification_period     24x7
    notification_interval   120
    notification_options    d,u,r
    contact_groups          admins
    register                0               ; ceci est un template, pas un hôte réel
}

# Hôte héritant du template
define host {
    use                     linux-server
    host_name               srv-db-01
    alias                   Serveur BDD Production
    address                 192.168.1.20
}

3. Centreon

3.1 Présentation

Centreon est une plateforme de supervision française basée historiquement sur Nagios (moteur Centreon Engine, fork de Nagios). Elle apporte une interface web complète, la gestion centralisée de la configuration, des graphes intégrés et un système de Plugin Packs facilitant le déploiement.

Composants principaux :

• Centreon Engine : moteur d'ordonnancement (compatible Nagios)
• Centreon Broker : collecte et stocke les données de performance (RRD, MariaDB)
• Centreon Web : interface de configuration et de visualisation
• Centreon Gorgone : communication entre serveur central et pollers

3.2 Installation (Alma Linux / RHEL 8+)

# Ajouter le dépôt Centreon (Alma Linux 8 / RHEL 8)
dnf install -y dnf-plugins-core
dnf config-manager --add-repo https://packages.centreon.com/rpm-standard/23.10/el8/centreon-23.10.repo

# Installer le serveur central
dnf install -y centreon-web centreon-engine centreon-broker centreon-gorgone
dnf install -y mariadb-server

# Démarrer MariaDB et sécuriser
systemctl start mariadb
systemctl enable mariadb
mysql_secure_installation

# Configurer PHP
dnf install -y php-intl php-pdo php-mysqlnd
echo "date.timezone = Europe/Paris" > /etc/php.d/50-centreon.ini

# Démarrer les services
systemctl enable --now centreon centengine cbd gorgoned httpd php-fpm

# Configurer le firewall
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-port=5556/tcp
firewall-cmd --reload

3.3 Interface web et navigation

L'interface Centreon est organisée en menus principaux :

• Accueil : tableau de bord personnalisable, vue d'ensemble
• Supervision > Statut des ressources : état temps réel des hôtes et services
• Configuration > Hôtes / Services : ajouter et configurer les objets de supervision
• Supervision > Performances : graphiques de métriques
• Configuration > Commandes : définir les commandes de check
• Administration : gestion des utilisateurs, paramètres généraux

3.4 Configuration d'un hôte

Via l'interface web : Configuration > Hôtes > Ajouter

• Nom : srv-web-01
• Alias : Serveur Web Production
• Adresse IP : 192.168.1.10
• Modèle(s) : OS-Linux-SNMP-custom (ou via Plugin Pack)
• Communauté SNMP : MaCommunaute (ou config SNMPv3)
• Collecteur : Central (ou poller distant)

3.5 Plugin Packs

Les Plugin Packs sont des paquets préconfigurés contenant templates, commandes et seuils pour un type d'équipement :

# Installer un Plugin Pack via CLI
centreon -u admin -p 'motdepasse' -a APPLYTPL -v "srv-web-01;OS-Linux-SNMP-custom"

# Lister les Plugin Packs disponibles
yum list centreon-pack-*

# Installer le pack pour Linux SNMP
yum install -y centreon-pack-operatingsystems-linux-snmp
# Puis activer dans : Configuration > Plugin Packs

Packs populaires : OS-Linux-SNMP, OS-Windows-SNMP, Hardware-Ups-Standard-SNMP, Network-Cisco-Standard-SNMP, Applications-Databases-MySQL.

3.6 Auto-découverte

Centreon propose un module d'auto-discovery :

• Découverte réseau : scan d'un sous-réseau pour trouver les hôtes (SNMP, ping)
• Découverte de services : détection automatique des interfaces réseau, disques, etc.
• Accessible via Configuration > Découverte

# Lancer une découverte manuelle via CLI
centreon -u admin -p 'motdepasse' -o HTPL -a generate \
  -v "discovery-job-name"

3.7 Graphiques et performances

Centreon stocke les données de performance (perfdata) via Centreon Broker dans des fichiers RRD. Les graphiques sont accessibles depuis :

• Supervision > Performances > Graphiques : graphiques par service
• Vues personnalisées : tableaux de bord avec widgets graphiques
• Période ajustable : dernière heure, jour, semaine, mois, personnalisée

3.8 API REST

Centreon expose une API REST v2 pour l'automatisation :

# Authentification - obtenir un token
curl -s -X POST "http://centreon.local/centreon/api/latest/login" \
  -H "Content-Type: application/json" \
  -d '{"security":{"credentials":{"login":"admin","password":"motdepasse"}}}' \
  | jq -r '.security.token'

# Lister les hôtes
TOKEN="votre-token"
curl -s -X GET "http://centreon.local/centreon/api/latest/monitoring/hosts" \
  -H "X-AUTH-TOKEN: $TOKEN" | jq '.result'

# Ajouter un hôte
curl -s -X POST "http://centreon.local/centreon/api/latest/configuration/hosts" \
  -H "X-AUTH-TOKEN: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "srv-app-01",
    "alias": "Serveur Applicatif",
    "address": "192.168.1.30",
    "monitoring_server_id": 1,
    "templates": [{"id": 10}]
  }'

# Forcer un check immédiat
curl -s -X POST "http://centreon.local/centreon/api/latest/monitoring/hosts/42/check" \
  -H "X-AUTH-TOKEN: $TOKEN"

4. Zabbix

4.1 Architecture

Zabbix est une solution de supervision open source complète. Son architecture modulaire comprend :

• Zabbix Server : composant central qui collecte, traite et stocke les données
• Zabbix Frontend : interface web PHP (Nginx ou Apache)
• Base de données : MySQL/MariaDB, PostgreSQL ou TimescaleDB
• Zabbix Agent / Agent 2 : agent installé sur les hôtes supervisés (Go pour Agent 2)
• Zabbix Proxy : collecteur intermédiaire pour les sites distants

4.2 Installation du serveur (Ubuntu 22.04+)

# Ajouter le dépôt Zabbix 7.0 LTS
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo apt update

# Installer le serveur, le frontend et l'agent
sudo apt install -y zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf \
    zabbix-sql-scripts zabbix-agent2

# Créer la base de données
sudo mysql -uroot -p <<EOF
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'MotDePasseSecure';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1;
EOF

# Importer le schéma initial
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

# Configurer le mot de passe BDD dans Zabbix Server
sudo sed -i 's/# DBPassword=/DBPassword=MotDePasseSecure/' /etc/zabbix/zabbix_server.conf

# Configurer Nginx pour le frontend
sudo nano /etc/zabbix/nginx.conf
# Décommenter et ajuster : listen 8080; server_name votre-serveur;

# Démarrer les services
sudo systemctl enable --now zabbix-server zabbix-agent2 nginx php8.1-fpm

4.3 Installation de l'agent

# Sur l'hôte à superviser (Ubuntu)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2

# Configuration : /etc/zabbix/zabbix_agent2.conf
Server=192.168.1.100          # IP du serveur Zabbix (checks passifs)
ServerActive=192.168.1.100    # IP du serveur Zabbix (checks actifs)
Hostname=srv-web-01           # Doit correspondre au nom dans l'interface

# Démarrer l'agent
sudo systemctl enable --now zabbix-agent2

# Tester depuis le serveur Zabbix
zabbix_get -s 192.168.1.10 -k agent.ping           # Doit retourner 1
zabbix_get -s 192.168.1.10 -k system.cpu.util       # Utilisation CPU
zabbix_get -s 192.168.1.10 -k vfs.fs.size[/,pused]  # % disque utilisé

4.4 Configuration initiale du frontend

Après l'installation, accédez à http://votre-serveur:8080 et complétez l'assistant :

1. Vérification des prérequis PHP
2. Connexion à la base de données (hôte: localhost, base: zabbix, user: zabbix)
3. Paramètres du serveur Zabbix (nom, port 10051)
4. Fuseau horaire et thème
5. Connexion avec Admin / zabbix

4.5 Templates

Les templates Zabbix regroupent items, triggers, graphes et règles de découverte. Zabbix inclut des templates prêts à l'emploi :

• Linux by Zabbix agent : CPU, mémoire, disques, réseau, processus
• Windows by Zabbix agent : performances, services, événements
• ICMP Ping : disponibilité réseau basique
• Template Module SNMP Interfaces : interfaces réseau via SNMP
• MySQL by Zabbix agent 2 : métriques MySQL natives
• Docker by Zabbix agent 2 : conteneurs Docker

Lier un template à un hôte : Data collection > Hosts > [hôte] > Templates > Link new template.

4.6 Types d'items

Type	Description	Exemple de clé
Zabbix agent	Check passif (serveur interroge l'agent)	system.cpu.util
Zabbix agent (active)	Check actif (l'agent envoie les données)	log[/var/log/syslog]
SNMP agent	Interrogation SNMP (v1/v2c/v3)	IF-MIB::ifInOctets.1
Simple check	Vérification sans agent (ping, port)	net.tcp.service[http,,80]
External check	Script exécuté côté serveur	check_custom.sh[{HOST.CONN}]
HTTP agent	Requête HTTP/HTTPS native	URL + parsing JSON/XML/Regex
Calculated	Calcul basé sur d'autres items	last(//vfs.fs.size[/,used])/last(//vfs.fs.size[/,total])*100

4.7 Triggers (déclencheurs)

Les triggers définissent les conditions d'alerte à l'aide d'expressions :

# CPU > 90% pendant 5 minutes
avg(/srv-web-01/system.cpu.util,5m)>90

# Espace disque < 10%
last(/srv-web-01/vfs.fs.size[/,pfree])<10

# Service HTTP indisponible
last(/srv-web-01/net.tcp.service[http,,80])=0

# Pas de données reçues depuis 5 minutes (agent down)
nodata(/srv-web-01/agent.ping,5m)=1

# Charge CPU en augmentation constante (tendance)
avg(/srv-web-01/system.cpu.util,1h)>avg(/srv-web-01/system.cpu.util,1d)

# Mémoire swap utilisée > 50%
last(/srv-web-01/system.swap.size[,pused])>50

Niveaux de sévérité disponibles : Not classified, Information, Warning, Average, High, Disaster.

4.8 Actions et notifications

Les actions définissent ce qui se passe quand un trigger change d'état :

• Alerts > Actions > Trigger actions > Create action
• Conditions : filtrer par groupe, template, sévérité, tag, etc.
• Opérations :
  • Envoyer un message (email, SMS, Slack, Teams via webhook)
  • Exécuter une commande distante (redémarrage de service, etc.)
• Opérations de récupération : notification quand le problème est résolu

# Exemple de webhook Slack (Media type > Webhook)
# URL: https://hooks.slack.com/services/T00/B00/xxxx
# Message template :
{
  "channel": "#alertes-infra",
  "username": "Zabbix",
  "text": ":rotating_light: {TRIGGER.STATUS}: {TRIGGER.NAME}\nHost: {HOST.NAME} ({HOST.IP})\nSévérité: {TRIGGER.SEVERITY}\nDétails: {ITEM.LASTVALUE}"
}

4.9 Tableaux de bord

Zabbix offre des tableaux de bord personnalisables :

• Dashboards > Create dashboard
• Widgets disponibles : graphiques, problèmes, carte réseau, horloge, SLA, top hosts, etc.
• Chaque utilisateur peut créer ses propres dashboards
• Possibilité de créer des dashboards partagés par équipe

4.10 Découverte réseau

Zabbix peut scanner automatiquement un réseau pour ajouter de nouveaux hôtes :

• Data collection > Discovery > Create discovery rule
• Définir la plage IP : 192.168.1.1-254
• Checks : SNMP, Zabbix agent, ICMP ping, TCP ports
• Actions automatiques : ajouter l'hôte, lier un template, ajouter à un groupe

# Exemple de règle de découverte via API
curl -s -X POST "http://zabbix.local/api_jsonrpc.php" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "drule.create",
    "params": {
        "name": "Decouverte LAN",
        "iprange": "192.168.1.1-254",
        "delay": "3600",
        "dchecks": [
            {"type": 9, "key_": "system.uname", "ports": "10050"},
            {"type": 3, "ports": "161", "snmp_community": "public"}
        ]
    },
    "auth": "votre-token",
    "id": 1
}'

4.11 Low-Level Discovery (LLD)

Le LLD permet de découvrir et superviser automatiquement des éléments dynamiques (interfaces réseau, systèmes de fichiers, instances de bases de données) :

# Règle LLD intégrée pour les systèmes de fichiers
# Clé : vfs.fs.discovery
# Filtre : {#FSTYPE} matches "ext4|xfs|btrfs"

# Items prototypes créés automatiquement pour chaque FS découvert :
vfs.fs.size[{#FSNAME},total]     # Taille totale
vfs.fs.size[{#FSNAME},used]      # Espace utilisé
vfs.fs.size[{#FSNAME},pfree]     # % libre

# Trigger prototype :
last(/host/vfs.fs.size[{#FSNAME},pfree])<10
# Crée un trigger pour chaque point de montage découvert

4.12 Zabbix Proxy

Le proxy Zabbix collecte les données pour le compte du serveur central, idéal pour :

• Sites distants avec liaison WAN instable
• Répartition de charge sur de gros environnements
• Supervision au travers de NAT/firewalls (une seule connexion)

# Installation du proxy
sudo apt install -y zabbix-proxy-mysql

# Configuration : /etc/zabbix/zabbix_proxy.conf
Server=192.168.1.100          # Adresse du serveur Zabbix central
Hostname=proxy-site-distant   # Nom du proxy (doit correspondre dans l'interface)
DBName=zabbix_proxy
DBUser=zabbix_proxy
DBPassword=MotDePasseProxy
ProxyMode=0                   # 0 = actif (le proxy envoie), 1 = passif

# Démarrer le proxy
sudo systemctl enable --now zabbix-proxy

4.13 Exemples concrets de supervision

Superviser un serveur Linux

# 1. Installer Zabbix Agent 2 sur le serveur cible
sudo apt install -y zabbix-agent2
# Configurer Server= et Hostname= dans /etc/zabbix/zabbix_agent2.conf

# 2. Dans l'interface Zabbix :
#    - Data collection > Hosts > Create host
#    - Nom : srv-linux-01
#    - Groupe : Linux servers
#    - Interface : Agent, 192.168.1.10, port 10050
#    - Templates : "Linux by Zabbix agent"
#
# Métriques collectées automatiquement :
#    - CPU (utilisation, load, iowait, contextes switches)
#    - Mémoire (RAM, swap, buffers, cache)
#    - Disques (espace, IOPS, débit, inodes)
#    - Réseau (trafic par interface, erreurs, drops)
#    - Processus (nombre, zombies)
#    - Uptime, kernel, agent availability

Superviser un serveur Windows

# 1. Installer Zabbix Agent 2 sur Windows
#    Télécharger le MSI depuis https://www.zabbix.com/download_agents
#    Ou via CLI :
zabbix_agent2.exe --config C:\zabbix\zabbix_agent2.conf --install
net start "Zabbix Agent 2"

# Configuration Windows : C:\zabbix\zabbix_agent2.conf
Server=192.168.1.100
ServerActive=192.168.1.100
Hostname=srv-win-01

# 2. Dans l'interface Zabbix :
#    - Templates : "Windows by Zabbix agent"
#
# Métriques spécifiques Windows :
#    - Services Windows (état, démarrage automatique)
#    - Event Log (Application, System, Security)
#    - Performances (.NET, IIS, SQL Server si présent)

Superviser un switch réseau (SNMP)

# Aucun agent à installer - supervision via SNMP

# 1. Activer SNMP sur le switch (exemple Cisco)
# configure terminal
# snmp-server community MonCommunity RO
# snmp-server host 192.168.1.100 MonCommunity

# 2. Dans l'interface Zabbix :
#    - Data collection > Hosts > Create host
#    - Nom : switch-core-01
#    - Groupe : Network devices
#    - Interface : SNMP, 192.168.1.1, port 161
#    - SNMP community : MonCommunity (v2c)
#    - Templates : "Cisco IOS by SNMP" ou "Network Generic Device by SNMP"
#
# Découverte automatique (LLD) des interfaces :
#    - Trafic in/out par port
#    - État oper/admin de chaque port
#    - Erreurs et discards
#    - Vitesse/duplex

5. Prometheus

5.1 Architecture

Prometheus est un système de monitoring et d'alerting open source, conçu pour la fiabilité et la scalabilité. Il repose sur un modèle pull : le serveur Prometheus interroge périodiquement les cibles (endpoints) pour récupérer leurs métriques.

• Prometheus Server : collecte les métriques par scraping HTTP, stocke dans une base TSDB (Time Series Database) locale
• Exporters : programmes exposant des métriques au format Prometheus (node_exporter, blackbox_exporter, mysqld_exporter, etc.)
• Alertmanager : gère la déduplication, le groupement et le routage des alertes vers les canaux de notification (email, Slack, PagerDuty)
• Pushgateway : permet aux jobs éphémères (cron, batch) de pousser leurs métriques vers Prometheus
• Client libraries : bibliothèques pour instrumenter vos applications (Go, Java, Python, etc.)

5.2 Installation sur Ubuntu

# Créer l'utilisateur système
sudo useradd --no-create-home --shell /bin/false prometheus

# Créer les répertoires
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown prometheus:prometheus /etc/prometheus /var/lib/prometheus

# Télécharger Prometheus (vérifier la dernière version sur github.com/prometheus/prometheus/releases)
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.50.1/prometheus-2.50.1.linux-amd64.tar.gz
tar xvf prometheus-2.50.1.linux-amd64.tar.gz
cd prometheus-2.50.1.linux-amd64

# Copier les binaires
sudo cp prometheus promtool /usr/local/bin/
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

# Copier les fichiers de configuration
sudo cp -r consoles console_libraries /etc/prometheus/
sudo cp prometheus.yml /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus

# Créer le service systemd
sudo cat <<EOF > /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus/ \
  --web.console.templates=/etc/prometheus/consoles \
  --web.console.libraries=/etc/prometheus/console_libraries \
  --storage.tsdb.retention.time=30d \
  --web.enable-lifecycle
ExecReload=/bin/kill -HUP \$MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now prometheus

# Vérifier : interface web sur http://localhost:9090

5.3 Configuration prometheus.yml

Le fichier /etc/prometheus/prometheus.yml définit les paramètres globaux et les cibles à scraper :

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s          # Fréquence de collecte par défaut
  evaluation_interval: 15s      # Fréquence d'évaluation des règles
  scrape_timeout: 10s           # Timeout par scrape

# Fichiers de règles d'alerte
rule_files:
  - "/etc/prometheus/alert.rules.yml"

# Configuration Alertmanager
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "localhost:9093"

# Définition des cibles à scraper
scrape_configs:
  # Prometheus lui-même
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  # Serveurs Linux via node_exporter
  - job_name: "linux-servers"
    scrape_interval: 10s
    static_configs:
      - targets:
          - "192.168.1.10:9100"
          - "192.168.1.11:9100"
          - "192.168.1.12:9100"
        labels:
          env: "production"
          datacenter: "dc1"
      - targets:
          - "192.168.1.20:9100"
        labels:
          env: "staging"

  # Supervision HTTP via blackbox_exporter
  - job_name: "http-probes"
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - "https://www.example.com"
          - "https://api.example.com/health"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: "localhost:9115"   # Adresse du blackbox_exporter

  # Base MySQL via mysqld_exporter
  - job_name: "mysql"
    static_configs:
      - targets: ["192.168.1.10:9104"]

  # Découverte via fichier (file_sd)
  - job_name: "dynamic-targets"
    file_sd_configs:
      - files:
          - "/etc/prometheus/targets/*.json"
        refresh_interval: 30s

5.4 PromQL - Langage de requêtes

PromQL (Prometheus Query Language) permet d'interroger les données de métriques collectées :

Fonctions essentielles

# rate() - Taux de variation par seconde (pour les counters)
# Indispensable pour les métriques de type counter (toujours croissantes)
rate(node_cpu_seconds_total{mode="idle"}[5m])

# increase() - Augmentation totale sur une période
# Nombre de requêtes HTTP reçues dans les 5 dernières minutes
increase(http_requests_total[5m])

# histogram_quantile() - Calcul de percentiles à partir d'histogrammes
# Latence au 95ème percentile des requêtes HTTP
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

# avg() - Moyenne par groupe
# CPU moyen par instance
avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))

# sum() - Somme par groupe
# Total des requêtes par code HTTP
sum by (code) (rate(http_requests_total[5m]))

# topk() - Top N séries
# Les 5 instances consommant le plus de CPU
topk(5, 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100))

# Exemples combinés utiles :

# Pourcentage d'utilisation CPU par serveur
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Espace disque restant en pourcentage
(node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100

# Taux d'erreurs HTTP (5xx) en pourcentage
sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

# Mémoire utilisée en pourcentage
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

5.5 Exporters

node_exporter (métriques système Linux)

# Installation de node_exporter
sudo useradd --no-create-home --shell /bin/false node_exporter

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvf node_exporter-1.7.0.linux-amd64.tar.gz
sudo cp node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

# Service systemd
sudo cat <<EOF > /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
  --collector.systemd \
  --collector.processes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

# Vérifier les métriques : curl http://localhost:9100/metrics
# Métriques exposées : node_cpu_*, node_memory_*, node_disk_*, node_filesystem_*, node_network_*

blackbox_exporter (sondes HTTP, TCP, ICMP, DNS)

# Installation
wget https://github.com/prometheus/blackbox_exporter/releases/download/v0.24.0/blackbox_exporter-0.24.0.linux-amd64.tar.gz
tar xvf blackbox_exporter-0.24.0.linux-amd64.tar.gz
sudo cp blackbox_exporter-0.24.0.linux-amd64/blackbox_exporter /usr/local/bin/

# Configuration /etc/prometheus/blackbox.yml
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: [200, 301, 302]
      method: GET
      follow_redirects: true
      preferred_ip_protocol: "ip4"
      tls_config:
        insecure_skip_verify: false

  http_post_2xx:
    prober: http
    http:
      method: POST
      headers:
        Content-Type: application/json

  tcp_connect:
    prober: tcp
    timeout: 5s

  icmp_check:
    prober: icmp
    timeout: 5s
    icmp:
      preferred_ip_protocol: "ip4"

  dns_check:
    prober: dns
    dns:
      query_name: "example.com"
      query_type: "A"

# Lancer : blackbox_exporter --config.file=/etc/prometheus/blackbox.yml
# Tester : curl "http://localhost:9115/probe?target=https://example.com&module=http_2xx"

mysqld_exporter (métriques MySQL/MariaDB)

# Créer un utilisateur MySQL dédié
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'motdepasse_fort';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES;

# Fichier de credentials /etc/prometheus/.mysqld_exporter.cnf
[client]
user=exporter
password=motdepasse_fort

# Installation et lancement
wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.15.1/mysqld_exporter-0.15.1.linux-amd64.tar.gz
tar xvf mysqld_exporter-0.15.1.linux-amd64.tar.gz
sudo cp mysqld_exporter-0.15.1.linux-amd64/mysqld_exporter /usr/local/bin/

# Lancer avec la config
mysqld_exporter --config.my-cnf=/etc/prometheus/.mysqld_exporter.cnf

# Métriques : mysql_global_status_*, mysql_global_variables_*, mysql_slave_*

5.6 Règles d'alerte

# /etc/prometheus/alert.rules.yml
groups:
  - name: infrastructure
    rules:
      # Alerte si une instance est down depuis plus de 2 minutes
      - alert: InstanceDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} indisponible"
          description: "{{ $labels.instance }} du job {{ $labels.job }} est down depuis plus de 2 minutes."

      # Alerte si CPU > 80% pendant 5 minutes
      - alert: HighCpuUsage
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU élevé sur {{ $labels.instance }}"
          description: "Utilisation CPU à {{ $value | printf \"%.1f\" }}% depuis 5 minutes."

      # Alerte si espace disque < 15%
      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes) * 100 < 15
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Espace disque faible sur {{ $labels.instance }}"
          description: "Partition {{ $labels.mountpoint }} à {{ $value | printf \"%.1f\" }}% d'espace libre."

      # Alerte si mémoire utilisée > 90%
      - alert: HighMemoryUsage
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Mémoire critique sur {{ $labels.instance }}"
          description: "Utilisation mémoire à {{ $value | printf \"%.1f\" }}%."

  - name: http-probes
    rules:
      # Alerte si un site est inaccessible
      - alert: HttpEndpointDown
        expr: probe_success == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Endpoint HTTP {{ $labels.instance }} inaccessible"

      # Alerte si le certificat SSL expire dans moins de 14 jours
      - alert: SslCertExpiringSoon
        expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 14
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Certificat SSL de {{ $labels.instance }} expire dans {{ $value | printf \"%.0f\" }} jours"

5.7 Configuration Alertmanager

# Installation Alertmanager
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar xvf alertmanager-0.27.0.linux-amd64.tar.gz
sudo cp alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo cp alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/

# /etc/alertmanager/alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_password: 'motdepasse'
  smtp_require_tls: true

# Modèles de notification personnalisés
templates:
  - '/etc/alertmanager/templates/*.tmpl'

# Arbre de routage des alertes
route:
  group_by: ['alertname', 'severity']
  group_wait: 30s           # Attendre avant d'envoyer un groupe
  group_interval: 5m        # Intervalle entre les rappels d'un même groupe
  repeat_interval: 4h       # Répéter une alerte non résolue
  receiver: 'email-equipe'  # Receiver par défaut
  routes:
    # Alertes critiques : email + Slack immédiatement
    - match:
        severity: critical
      receiver: 'critical-alerts'
      group_wait: 10s
      repeat_interval: 1h
    # Alertes liées aux certificats SSL
    - match:
        alertname: SslCertExpiringSoon
      receiver: 'email-securite'
      repeat_interval: 24h

# Définition des receivers
receivers:
  - name: 'email-equipe'
    email_configs:
      - to: 'equipe-infra@example.com'
        send_resolved: true

  - name: 'critical-alerts'
    email_configs:
      - to: 'urgences@example.com'
        send_resolved: true
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX'
        channel: '#alertes-infra'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}'
        send_resolved: true
        color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'

  - name: 'email-securite'
    email_configs:
      - to: 'securite@example.com'
        send_resolved: true

# Règles d'inhibition (supprimer les alertes redondantes)
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

5.8 Service Discovery

Prometheus supporte plusieurs mécanismes de découverte automatique des cibles :

file_sd (découverte par fichier)

# /etc/prometheus/targets/linux-servers.json
[
  {
    "targets": ["192.168.1.10:9100", "192.168.1.11:9100"],
    "labels": {
      "env": "production",
      "role": "webserver"
    }
  },
  {
    "targets": ["192.168.1.20:9100"],
    "labels": {
      "env": "staging",
      "role": "database"
    }
  }
]

# Avantage : le fichier peut être généré par un script, Ansible, Terraform, etc.
# Prometheus relit automatiquement le fichier (refresh_interval)

consul_sd (découverte via Consul)

# Dans prometheus.yml
scrape_configs:
  - job_name: "consul-services"
    consul_sd_configs:
      - server: "consul.example.com:8500"
        services: []  # Vide = tous les services
        tags:
          - "monitoring"
    relabel_configs:
      # Utiliser le nom du service Consul comme label "job"
      - source_labels: [__meta_consul_service]
        target_label: job
      # Filtrer par tag
      - source_labels: [__meta_consul_tags]
        regex: '.*,production,.*'
        action: keep
      # Ajouter le datacenter comme label
      - source_labels: [__meta_consul_dc]
        target_label: datacenter

6. Grafana

6.1 Installation

# Installation sur Ubuntu/Debian
sudo apt-get install -y apt-transport-https software-properties-common wget
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list

sudo apt-get update
sudo apt-get install grafana

# Démarrer le service
sudo systemctl enable --now grafana-server

# Interface web : http://localhost:3000
# Identifiants par défaut : admin / admin (changer immédiatement)

# Configuration principale : /etc/grafana/grafana.ini
# Logs : /var/log/grafana/grafana.log

6.2 Data Sources

Grafana supporte de nombreuses sources de données. Voici la configuration des plus courantes :

Prometheus

# Via l'interface : Configuration > Data Sources > Add data source > Prometheus
# URL : http://localhost:9090
# Access : Server (recommandé)
# Scrape interval : 15s (doit correspondre à votre config Prometheus)

# Ou via provisioning (voir section 6.6)

Zabbix

# 1. Installer le plugin Zabbix pour Grafana
grafana-cli plugins install alexanderzobnin-zabbix-app
sudo systemctl restart grafana-server

# 2. Activer le plugin : Configuration > Plugins > Zabbix > Enable
# 3. Ajouter la data source :
#    - Type : Zabbix
#    - URL : http://zabbix-server/api_jsonrpc.php
#    - Username / Password : utilisateur Zabbix avec droits API

InfluxDB

# Configuration :
#   - URL : http://localhost:8086
#   - Database : nom_de_la_base
#   - User / Password : credentials InfluxDB
#   - HTTP Method : GET ou POST
#   - Pour InfluxDB 2.x : utiliser Flux comme langage de requête

MySQL / MariaDB

# Configuration :
#   - Host : localhost:3306
#   - Database : ma_base
#   - User / Password : utilisateur en lecture seule
#   - Permet d'exécuter des requêtes SQL directement dans les panels

6.3 Création de dashboards et types de panels

Grafana propose différents types de visualisations :

Type de panel	Usage	Exemple
Time series	Graphiques temporels classiques (courbes, barres)	CPU, trafic réseau, requêtes/sec
Gauge	Jauge circulaire avec seuils colorés	Pourcentage disque, température
Stat	Valeur unique mise en évidence	Uptime, nombre de serveurs UP
Table	Données tabulaires	Liste des alertes, inventaire
Heatmap	Carte de chaleur (distribution dans le temps)	Distribution de latence, histogrammes
Bar chart	Diagramme en barres	Comparaison entre serveurs
Logs	Affichage de flux de logs	Logs applicatifs via Loki

6.4 Variables et templates

Les variables rendent les dashboards dynamiques et réutilisables :

# Créer une variable : Dashboard Settings > Variables > New variable

# Variable $host (liste des instances Prometheus)
# Type : Query
# Data source : Prometheus
# Query : label_values(node_uname_info, instance)
# Refresh : On time range change

# Variable $interval (intervalle dynamique)
# Type : Interval
# Values : 1m, 5m, 15m, 30m, 1h, 6h, 12h, 24h
# Auto option : activer pour ajustement automatique

# Variable $job (sélection du job Prometheus)
# Type : Query
# Query : label_values(up, job)
# Multi-value : activer pour sélection multiple

# Utilisation dans une requête PromQL :
rate(node_cpu_seconds_total{instance="$host", mode="idle"}[$interval])

# Variable de type Custom (valeurs fixes)
# Type : Custom
# Values : production, staging, development

6.5 Alerting dans Grafana

# Grafana Alerting (Unified Alerting depuis Grafana 9+)

# 1. Créer une règle d'alerte :
#    Alerting > Alert rules > New alert rule
#    - Choisir la data source et la requête
#    - Définir les conditions (ex : IS ABOVE 80)
#    - Définir la période d'évaluation (ex: every 1m, for 5m)
#    - Ajouter labels et annotations

# 2. Contact points (canaux de notification) :
#    Alerting > Contact points > New contact point
#    Types supportés : Email, Slack, Teams, PagerDuty, Webhook, Telegram, Discord...

# 3. Notification policies (routage) :
#    Alerting > Notification policies
#    - Routing par labels (ex : severity=critical → PagerDuty)
#    - Groupement et timing (group_wait, repeat_interval)

# 4. Silences (mettre en pause les alertes) :
#    Alerting > Silences > New silence
#    - Définir les matchers et la durée

6.6 Provisioning (Infrastructure as Code)

Grafana peut être configuré entièrement via des fichiers YAML, idéal pour le déploiement automatisé :

Provisioning des data sources

# /etc/grafana/provisioning/datasources/datasources.yml
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://localhost:9090
    isDefault: true
    editable: false
    jsonData:
      timeInterval: "15s"

  - name: Loki
    type: loki
    access: proxy
    url: http://localhost:3100
    editable: false

  - name: InfluxDB
    type: influxdb
    access: proxy
    url: http://localhost:8086
    database: monitoring
    user: grafana
    secureJsonData:
      password: "motdepasse"

Provisioning des dashboards

# /etc/grafana/provisioning/dashboards/dashboards.yml
apiVersion: 1

providers:
  - name: 'default'
    orgId: 1
    folder: 'Provisioned'
    type: file
    disableDeletion: false
    updateIntervalSeconds: 30
    allowUiUpdates: true
    options:
      path: /var/lib/grafana/dashboards
      foldersFromFilesStructure: true

# Placer vos fichiers JSON de dashboards dans /var/lib/grafana/dashboards/
# Ils seront automatiquement importés au démarrage de Grafana

6.7 Dashboards communautaires populaires

Importez des dashboards prêts à l'emploi depuis grafana.com/dashboards via leur ID :

ID	Nom	Data Source	Description
1860	Node Exporter Full	Prometheus	Dashboard complet pour node_exporter (CPU, RAM, disque, réseau)
3662	Prometheus 2.0 Overview	Prometheus	Monitoring de Prometheus lui-même
7362	MySQL Overview	Prometheus	Métriques MySQL via mysqld_exporter
9628	PostgreSQL Database	Prometheus	Métriques PostgreSQL
13659	Blackbox Exporter	Prometheus	Monitoring HTTP/TCP/ICMP
14031	Zabbix Server	Zabbix	Dashboard Zabbix dans Grafana

6.8 Grafana Loki (agrégation de logs)

Loki est le système d'agrégation de logs de Grafana, conçu pour être efficace et facile à utiliser avec Grafana :

# Installation de Loki
wget https://github.com/grafana/loki/releases/download/v2.9.4/loki-linux-amd64.zip
unzip loki-linux-amd64.zip
sudo cp loki-linux-amd64 /usr/local/bin/loki

# Configuration minimale /etc/loki/loki-config.yml
auth_enabled: false
server:
  http_listen_port: 3100
common:
  path_prefix: /var/lib/loki
  storage:
    filesystem:
      chunks_directory: /var/lib/loki/chunks
      rules_directory: /var/lib/loki/rules
  replication_factor: 1
schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

# Installation de Promtail (agent de collecte de logs)
wget https://github.com/grafana/loki/releases/download/v2.9.4/promtail-linux-amd64.zip
unzip promtail-linux-amd64.zip
sudo cp promtail-linux-amd64 /usr/local/bin/promtail

# Configuration Promtail /etc/promtail/promtail-config.yml
server:
  http_listen_port: 9080
positions:
  filename: /var/lib/promtail/positions.yaml
clients:
  - url: http://localhost:3100/loki/api/v1/push
scrape_configs:
  - job_name: syslog
    static_configs:
      - targets: [localhost]
        labels:
          job: syslog
          __path__: /var/log/syslog
  - job_name: nginx
    static_configs:
      - targets: [localhost]
        labels:
          job: nginx
          __path__: /var/log/nginx/*.log

# Requête LogQL dans Grafana (panel Logs) :
# {job="syslog"} |= "error"
# {job="nginx"} | json | status >= 500

7. ELK Stack (Elasticsearch, Logstash, Kibana)

7.1 Architecture

La stack ELK est une solution complète de collecte, traitement, stockage et visualisation de logs :

• Elasticsearch : moteur de recherche et d'analyse distribué (stockage et indexation)
• Logstash : pipeline de traitement de données (collecte, transformation, envoi)
• Kibana : interface de visualisation et d'exploration des données
• Beats : agents légers de collecte (Filebeat, Metricbeat, Packetbeat, etc.)

7.2 Elasticsearch

Installation

# Importer la clé GPG et le dépôt Elastic
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt-get update
sudo apt-get install elasticsearch

# Configuration /etc/elasticsearch/elasticsearch.yml
cluster.name: monitoring-cluster
node.name: node-1
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200
discovery.type: single-node        # Pour un seul noeud
xpack.security.enabled: true       # Activer la sécurité

# Démarrer
sudo systemctl enable --now elasticsearch

# Vérifier
curl -k https://localhost:9200 -u elastic:motdepasse

Création d'index et requêtes de base

# Créer un index avec mapping
curl -X PUT "localhost:9200/logs-application" -H 'Content-Type: application/json' -d '{
  "mappings": {
    "properties": {
      "timestamp": { "type": "date" },
      "level": { "type": "keyword" },
      "message": { "type": "text" },
      "host": { "type": "keyword" },
      "service": { "type": "keyword" }
    }
  }
}'

# Requête match (recherche full-text)
curl -X GET "localhost:9200/logs-application/_search" -H 'Content-Type: application/json' -d '{
  "query": {
    "match": {
      "message": "connection refused"
    }
  }
}'

# Requête bool (combinaison de conditions)
curl -X GET "localhost:9200/logs-application/_search" -H 'Content-Type: application/json' -d '{
  "query": {
    "bool": {
      "must": [
        { "match": { "message": "error" } }
      ],
      "filter": [
        { "term": { "level": "ERROR" } },
        { "term": { "service": "api-gateway" } }
      ],
      "must_not": [
        { "match": { "message": "timeout" } }
      ]
    }
  },
  "sort": [{ "timestamp": "desc" }],
  "size": 20
}'

# Requête range (plage de dates)
curl -X GET "localhost:9200/logs-application/_search" -H 'Content-Type: application/json' -d '{
  "query": {
    "range": {
      "timestamp": {
        "gte": "now-1h",
        "lte": "now"
      }
    }
  }
}'

# Agrégation (compter les logs par level)
curl -X GET "localhost:9200/logs-application/_search" -H 'Content-Type: application/json' -d '{
  "size": 0,
  "aggs": {
    "logs_par_level": {
      "terms": { "field": "level" }
    }
  }
}'

7.3 Logstash

Installation

sudo apt-get install logstash

# Les pipelines se configurent dans /etc/logstash/conf.d/
# Chaque fichier .conf définit un pipeline : input > filter > output

Exemple de pipeline complet

# /etc/logstash/conf.d/syslog.conf

# INPUT : réception des logs
input {
  # Syslog via TCP/UDP
  syslog {
    port => 5514
    type => "syslog"
  }

  # Logs depuis Filebeat
  beats {
    port => 5044
    ssl => false
  }

  # Fichier local (pour test)
  file {
    path => "/var/log/apache2/access.log"
    start_position => "beginning"
    type => "apache-access"
  }
}

# FILTER : transformation et enrichissement
filter {
  # Parser les logs syslog
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:host} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:log_message}" }
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }

  # Parser les logs Apache
  if [type] == "apache-access" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
    geoip {
      source => "clientip"
    }
    useragent {
      source => "agent"
      target => "user_agent"
    }
  }

  # Enrichissement commun
  mutate {
    remove_field => [ "beat", "input_type", "tags" ]
  }
}

# OUTPUT : envoi vers Elasticsearch
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "%{type}-%{+YYYY.MM.dd}"
    user => "logstash_writer"
    password => "motdepasse"
  }

  # Sortie console pour le debug
  # stdout { codec => rubydebug }
}

Patterns Grok courants

# Patterns Grok les plus utilisés :
# %{IP:client_ip}                    - Adresse IP
# %{IPORHOST:host}                   - IP ou nom d'hôte
# %{NUMBER:response_time:float}      - Nombre (avec conversion)
# %{WORD:method}                     - Un mot (GET, POST, etc.)
# %{URIPATHPARAM:request}            - URI avec paramètres
# %{GREEDYDATA:message}              - Tout le reste de la ligne
# %{COMBINEDAPACHELOG}               - Format Apache combined
# %{SYSLOGTIMESTAMP:timestamp}       - Timestamp syslog
# %{LOGLEVEL:level}                  - Niveau de log (INFO, ERROR, etc.)

# Exemple pour un log personnalisé :
# Log : "2024-01-15 14:30:22 [ERROR] api-gateway - Connection timeout to backend:8080"
# Pattern :
# %{TIMESTAMP_ISO8601:timestamp} \[%{LOGLEVEL:level}\] %{DATA:service} - %{GREEDYDATA:message}

# Tester vos patterns : https://grokdebugger.com/ ou dans Kibana > Dev Tools > Grok Debugger

7.4 Kibana

Installation et configuration

sudo apt-get install kibana

# Configuration /etc/kibana/kibana.yml
server.port: 5601
server.host: "0.0.0.0"
server.name: "kibana-monitoring"
elasticsearch.hosts: ["http://localhost:9200"]
elasticsearch.username: "kibana_system"
elasticsearch.password: "motdepasse"

sudo systemctl enable --now kibana
# Interface : http://localhost:5601

Utilisation de Kibana

# 1. DISCOVER (exploration des logs)
#    - Créer un Data View (anciennement Index Pattern) :
#      Stack Management > Data Views > Create data view
#      Pattern : "syslog-*" ou "filebeat-*"
#      Champ date : @timestamp
#    - Explorer les logs avec filtres et recherche KQL :
#      level: "ERROR" and service: "api-gateway"
#      host: "web-01" and message: "timeout"

# 2. VISUALIZATIONS
#    Types disponibles :
#    - Lens (recommandé, drag & drop)
#    - TSVB (Time Series Visual Builder)
#    - Pie chart, Bar chart, Line chart
#    - Metric, Gauge
#    - Data Table
#    - Maps (géolocalisation)
#    - Tag Cloud

# 3. DASHBOARDS
#    - Combiner plusieurs visualisations sur une seule page
#    - Filtres globaux partagés entre tous les panels
#    - Export/Import en JSON (pour versionner dans Git)

# 4. Dev Tools (console Elasticsearch)
#    Permet d'exécuter des requêtes directement :
#    GET _cluster/health
#    GET _cat/indices?v
#    GET logs-*/_search
#    { "query": { "match_all": {} } }

7.5 Filebeat

# Installation
sudo apt-get install filebeat

# Activer des modules préconfigurés
sudo filebeat modules enable system
sudo filebeat modules enable apache
sudo filebeat modules enable nginx

# Configuration des modules
# /etc/filebeat/modules.d/system.yml
- module: system
  syslog:
    enabled: true
    var.paths: ["/var/log/syslog"]
  auth:
    enabled: true
    var.paths: ["/var/log/auth.log"]

# /etc/filebeat/modules.d/nginx.yml
- module: nginx
  access:
    enabled: true
    var.paths: ["/var/log/nginx/access.log"]
  error:
    enabled: true
    var.paths: ["/var/log/nginx/error.log"]

# Configuration principale /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: filestream
    id: custom-app-logs
    enabled: true
    paths:
      - /var/log/myapp/*.log
    fields:
      app: myapp
      env: production
    fields_under_root: true

# Sortie vers Logstash
output.logstash:
  hosts: ["logstash-server:5044"]

# OU sortie directe vers Elasticsearch
# output.elasticsearch:
#   hosts: ["http://elasticsearch:9200"]
#   username: "filebeat_writer"
#   password: "motdepasse"
#   index: "filebeat-%{+yyyy.MM.dd}"

# Charger les dashboards Kibana préconfigurés
sudo filebeat setup --dashboards

# Démarrer
sudo systemctl enable --now filebeat

7.6 Index Lifecycle Management (ILM)

ILM permet de gérer automatiquement le cycle de vie des index (rotation, archivage, suppression) :

# Créer une politique ILM via l'API Elasticsearch
curl -X PUT "localhost:9200/_ilm/policy/logs-policy" -H 'Content-Type: application/json' -d '{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "1d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "set_priority": { "priority": 0 },
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}'

# Appliquer la politique à un index template
# Stack Management > Index Management > Index Lifecycle Policies
# Ou via Kibana : Stack Management > Index Lifecycle Policies

8. Graylog

8.1 Architecture

Graylog est une plateforme centralisée de gestion de logs, alternative à la stack ELK. Son architecture repose sur trois composants :

• Graylog Server : composant principal (interface web, API REST, moteur de traitement)
• MongoDB : stocke la configuration, les utilisateurs, les streams et les métadonnées
• OpenSearch (ou Elasticsearch) : stocke et indexe les messages de logs

8.2 Installation

# Prérequis : MongoDB et OpenSearch doivent être installés au préalable

# 1. Installer MongoDB
sudo apt-get install -y gnupg curl
curl -fsSL https://www.mongodb.org/static/pgp/server-6.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-6.0.gpg
echo "deb [signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
sudo apt-get update
sudo apt-get install -y mongodb-org
sudo systemctl enable --now mongod

# 2. Installer OpenSearch
wget https://artifacts.opensearch.org/releases/bundle/opensearch/2.12.0/opensearch-2.12.0-linux-x64.deb
sudo dpkg -i opensearch-2.12.0-linux-x64.deb

# Configuration /etc/opensearch/opensearch.yml
# cluster.name: graylog
# node.name: node-1
# network.host: 127.0.0.1
# discovery.type: single-node
# plugins.security.disabled: true   # Simplifier pour usage interne

sudo systemctl enable --now opensearch

# 3. Installer Graylog
wget https://packages.graylog2.org/repo/packages/graylog-5.2-repository_latest.deb
sudo dpkg -i graylog-5.2-repository_latest.deb
sudo apt-get update
sudo apt-get install graylog-server

# Générer le secret et le hash du mot de passe admin
# Secret (pour le chiffrement interne)
pwgen -N 1 -s 96
# Hash SHA256 du mot de passe admin
echo -n "MonMotDePasse" | sha256sum | awk '{print $1}'

# Configuration /etc/graylog/server/server.conf
# password_secret = <résultat de pwgen>
# root_password_sha2 = <hash SHA256>
# http_bind_address = 0.0.0.0:9000
# elasticsearch_hosts = http://127.0.0.1:9200

sudo systemctl enable --now graylog-server

# Interface web : http://localhost:9000
# Login : admin / <mot de passe configuré>

8.3 Inputs (réception des logs)

Les Inputs définissent comment Graylog reçoit les messages. Configuration via System > Inputs :

# Types d'Inputs disponibles :

# Syslog UDP (port 1514 recommandé pour éviter les conflits)
# - Rapide, sans garantie de livraison
# - Idéal pour les équipements réseau, serveurs Linux
# Configuration côté client (rsyslog) :
*.* @graylog-server:1514;RSYSLOG_SyslogProtocol23Format

# Syslog TCP (port 1514)
# - Fiable, connexion persistante
# Configuration côté client (rsyslog) :
*.* @@graylog-server:1514;RSYSLOG_SyslogProtocol23Format

# GELF (Graylog Extended Log Format) - UDP port 12201
# - Format natif Graylog, supporte les champs personnalisés
# - Pas de limite de taille de message (contrairement à syslog)
# Envoi depuis une application :
# curl -X POST -H 'Content-Type: application/json' \
#   -d '{"version":"1.1","host":"web-01","short_message":"Test","level":6,"_app":"myapp"}' \
#   'http://graylog-server:12201/gelf'

# GELF TCP (port 12201)
# - Même format que GELF UDP mais avec garantie de livraison

# Beats (port 5044)
# - Compatible avec Filebeat, Metricbeat, etc.
# - Permet de réutiliser les agents Elastic existants

8.4 Extracteurs et Pipelines

Extracteurs

# Les extracteurs s'appliquent au niveau de l'Input pour parser les messages

# Types d'extracteurs :
# - Regex : extraction par expression régulière
# - Grok : patterns prédéfinis (comme Logstash)
# - JSON : parser automatique du JSON
# - Key-Value : extraire des paires clé=valeur
# - Split & Index : découper par délimiteur
# - Substring : extraire par position

# Exemple Grok pour logs Apache :
# Pattern : %{COMBINEDAPACHELOG}
# S'applique sur le champ : message
# Résultat : crée les champs clientip, verb, request, response, bytes, etc.

Pipelines de traitement

# Les pipelines offrent plus de flexibilité que les extracteurs
# System > Pipelines

# Exemple de règle de pipeline :
rule "extraire_niveau_log"
when
  has_field("message") AND
  regex("\\[(ERROR|WARN|INFO|DEBUG)\\]", to_string($message.message)).matches == true
then
  let niveau = regex("\\[(ERROR|WARN|INFO|DEBUG)\\]", to_string($message.message));
  set_field("log_level", niveau["0"]);
end

# Exemple : enrichir avec une lookup table
rule "enrichir_ip_source"
when
  has_field("src_ip")
then
  let geo = lookup_value("geoip-lookup", to_string($message.src_ip));
  set_field("src_country", geo);
end

# Exemple : router les messages
rule "marquer_erreurs_critiques"
when
  has_field("log_level") AND to_string($message.log_level) == "ERROR"
then
  set_field("alert_priority", "high");
  route_to_stream("Critical Errors");
end

8.5 Streams et routage

# Les Streams permettent de catégoriser et router les messages
# Streams > Create stream

# Exemples de Streams :
# - "Linux Syslog"     : field source matches regex ^srv-.*
# - "Apache Access"    : field application equals apache
# - "Erreurs critiques": field log_level equals ERROR
# - "Réseau"           : field source matches regex ^(sw|rt|fw)-.*

# Chaque message peut appartenir à plusieurs Streams
# Les Streams permettent :
#   - D'appliquer des pipelines spécifiques
#   - De définir des alertes ciblées
#   - De gérer la rétention par catégorie (Index Sets différents)
#   - De contrôler les droits d'accès (qui voit quoi)

# Index Sets : lier un Stream à un Index Set spécifique
# Permet de définir des durées de rétention différentes :
#   - Logs applicatifs : 30 jours
#   - Logs de sécurité : 1 an
#   - Logs réseau : 14 jours

8.6 Dashboards et alertes

# DASHBOARDS
# Dashboards > Create new dashboard
# Widgets disponibles :
#   - Search result count (nombre de résultats)
#   - Message table (tableau de messages)
#   - Field value chart (graphique temporel)
#   - Stacked chart (graphique empilé)
#   - World map (géolocalisation)
#   - Aggregation (statistiques)

# ALERTES (Event Definitions)
# Alerts > Event Definitions > Create Event Definition

# Exemple : alerte si plus de 50 erreurs en 5 minutes
# Type : Filter & Aggregation
# Search query : log_level:ERROR
# Streams : sélectionner le stream concerné
# Aggregation : count() > 50
# Search within : 5 minutes
# Execute every : 1 minute

# Notifications :
# Alerts > Notifications
# Types disponibles :
#   - Email : envoi via SMTP configuré
#   - HTTP : webhook vers Slack, Teams, PagerDuty
#   - Script : exécuter un script personnalisé

# Exemple de notification HTTP (Slack) :
# URL : https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX
# Body template (JSON) :
# {
#   "text": "Alerte Graylog : ${event_definition_title}\n${event.message}\nNombre : ${event.fields.count}"
# }

8.7 Sidecar (collecte distribuée de logs)

Le Sidecar est un agent léger installé sur les serveurs pour gérer la collecte de logs à distance :

# Installation du Sidecar
wget https://packages.graylog2.org/repo/packages/graylog-sidecar-repository_1-5_all.deb
sudo dpkg -i graylog-sidecar-repository_1-5_all.deb
sudo apt-get update
sudo apt-get install graylog-sidecar

# Configuration /etc/graylog/sidecar/sidecar.yml
server_url: "http://graylog-server:9000/api/"
server_api_token: "<token_généré_dans_graylog>"
node_name: "web-server-01"
update_interval: 10       # Intervalle de mise à jour en secondes
send_status: true

# Installer un collecteur (Filebeat recommandé)
sudo apt-get install filebeat

# Enregistrer et démarrer le Sidecar
sudo graylog-sidecar -service install
sudo systemctl enable --now graylog-sidecar

# Configuration centralisée dans Graylog :
# System > Sidecars > Configuration
# Créer une configuration Filebeat qui sera déployée automatiquement
# sur tous les Sidecars associés.

# Avantages du Sidecar :
#   - Configuration centralisée depuis l'interface Graylog
#   - Déploiement automatique des configurations
#   - Monitoring de l'état des collecteurs
#   - Pas besoin de SSH sur chaque serveur pour modifier la collecte

9. SNMP en détail

9.1 Comparaison des versions

Caractéristique	SNMPv1	SNMPv2c	SNMPv3
Authentification	Community string (texte clair)	Community string (texte clair)	Username + mot de passe (MD5/SHA)
Chiffrement	Aucun	Aucun	DES / AES-128 / AES-256
Contrôle d'accès	Basique (community RO/RW)	Basique (community RO/RW)	VACM (View-based Access Control)
Types de données	Counter 32 bits	Counter 64 bits, GetBulk	Counter 64 bits, GetBulk
Niveaux de sécurité	-	-	noAuthNoPriv, authNoPriv, authPriv
Recommandation	Obsolète, à éviter	Acceptable en réseau isolé	Recommandé en production

9.2 Communities

# Les community strings agissent comme des "mots de passe" simples en SNMPv1/v2c

# Types de communities :
# - RO (Read-Only)  : permet uniquement la lecture des informations (GET, WALK)
# - RW (Read-Write) : permet la lecture ET la modification (SET)

# Bonnes pratiques :
# - Ne JAMAIS utiliser "public" ou "private" (valeurs par défaut)
# - Utiliser des chaînes complexes : MonR3s3au_SNMP!2024
# - Limiter l'accès par adresse IP source (ACL)
# - Préférer SNMPv3 dès que possible

# Tester la community :
snmpget -v2c -c MaCommunity 192.168.1.1 sysName.0

9.3 OIDs et MIBs

Les OIDs (Object Identifiers) sont des identifiants numériques uniques organisés en arbre. Les MIBs (Management Information Bases) fournissent la correspondance entre les OIDs numériques et des noms lisibles.

MIBs courantes

MIB	Description	OIDs courants
SNMPv2-MIB	Informations système de base	sysDescr, sysUpTime, sysName, sysContact, sysLocation
IF-MIB	Interfaces réseau	ifDescr, ifOperStatus, ifInOctets, ifOutOctets, ifSpeed, ifHCInOctets
HOST-RESOURCES-MIB	Ressources système (CPU, RAM, disque, processus)	hrProcessorLoad, hrMemorySize, hrStorageUsed, hrSWRunName
UCD-SNMP-MIB	Extension Net-SNMP (Linux)	memTotalReal, memAvailReal, ssCpuIdle, laLoad, dskPercent
IP-MIB	Couche IP	ipForwarding, ipInReceives, ipOutRequests, ipRouteTable
TCP-MIB	Couche TCP	tcpCurrEstab, tcpInSegs, tcpOutSegs, tcpConnTable

Table des OIDs numériques courants

# OIDs système (SNMPv2-MIB)
.1.3.6.1.2.1.1.1.0    = sysDescr       (description du système)
.1.3.6.1.2.1.1.3.0    = sysUpTime      (uptime en ticks)
.1.3.6.1.2.1.1.5.0    = sysName        (nom d'hôte)
.1.3.6.1.2.1.1.6.0    = sysLocation    (localisation)
.1.3.6.1.2.1.1.4.0    = sysContact     (contact administrateur)

# OIDs interfaces (IF-MIB)
.1.3.6.1.2.1.2.2.1.2  = ifDescr        (nom de l'interface)
.1.3.6.1.2.1.2.2.1.5  = ifSpeed        (vitesse de l'interface)
.1.3.6.1.2.1.2.2.1.8  = ifOperStatus   (état opérationnel : 1=up, 2=down)
.1.3.6.1.2.1.2.2.1.10 = ifInOctets     (octets entrants - 32 bits)
.1.3.6.1.2.1.2.2.1.16 = ifOutOctets    (octets sortants - 32 bits)
.1.3.6.1.2.1.31.1.1.1.6  = ifHCInOctets   (octets entrants - 64 bits)
.1.3.6.1.2.1.31.1.1.1.10 = ifHCOutOctets  (octets sortants - 64 bits)

# OIDs ressources (HOST-RESOURCES-MIB)
.1.3.6.1.2.1.25.2.2.0     = hrMemorySize      (RAM totale en Ko)
.1.3.6.1.2.1.25.2.3.1.5   = hrStorageSize     (taille stockage)
.1.3.6.1.2.1.25.2.3.1.6   = hrStorageUsed     (stockage utilisé)
.1.3.6.1.2.1.25.3.3.1.2   = hrProcessorLoad   (charge CPU %)

# OIDs Linux (UCD-SNMP-MIB)
.1.3.6.1.4.1.2021.4.5.0   = memTotalReal    (RAM totale)
.1.3.6.1.4.1.2021.4.6.0   = memAvailReal    (RAM disponible)
.1.3.6.1.4.1.2021.4.11.0  = memTotalFree    (RAM libre)
.1.3.6.1.4.1.2021.11.11.0 = ssCpuIdle       (% CPU idle)
.1.3.6.1.4.1.2021.10.1.3  = laLoad          (load average)

9.4 Commandes SNMP

snmpwalk (parcourir un sous-arbre)

# Installer les outils SNMP
sudo apt-get install snmp snmp-mibs-downloader

# Activer les MIBs (décommenter dans /etc/snmp/snmp.conf)
# mibs +ALL

# snmpwalk - Parcourir toutes les interfaces réseau
snmpwalk -v2c -c MaCommunity 192.168.1.1 IF-MIB::ifDescr

# Parcourir les informations système
snmpwalk -v2c -c MaCommunity 192.168.1.1 SNMPv2-MIB::system

# Parcourir le stockage (disques)
snmpwalk -v2c -c MaCommunity 192.168.1.10 HOST-RESOURCES-MIB::hrStorageDescr

# Version SNMPv3
snmpwalk -v3 -u monUser -l authPriv -a SHA -A "MonAuthPass" -x AES -X "MonPrivPass" 192.168.1.1 IF-MIB::ifDescr

# Sortie en OIDs numériques
snmpwalk -v2c -c MaCommunity -On 192.168.1.1 .1.3.6.1.2.1.2.2.1.2

snmpget (lire une valeur précise)

# Lire le nom du système
snmpget -v2c -c MaCommunity 192.168.1.1 sysName.0

# Lire l'uptime
snmpget -v2c -c MaCommunity 192.168.1.1 sysUpTimeInstance

# Lire l'état d'une interface (index 1)
snmpget -v2c -c MaCommunity 192.168.1.1 IF-MIB::ifOperStatus.1

# Lire le trafic entrant sur l'interface 2 (compteur 64 bits)
snmpget -v2c -c MaCommunity 192.168.1.1 IF-MIB::ifHCInOctets.2

# Lire la charge CPU sur Linux
snmpget -v2c -c MaCommunity 192.168.1.10 UCD-SNMP-MIB::ssCpuIdle.0

# Plusieurs valeurs en une seule commande
snmpget -v2c -c MaCommunity 192.168.1.1 sysName.0 sysUpTime.0 sysLocation.0

snmpset (modifier une valeur)

# Modifier le nom du système (nécessite community RW)
snmpset -v2c -c MaCommunityRW 192.168.1.1 sysName.0 s "nouveau-nom"

# Modifier la localisation
snmpset -v2c -c MaCommunityRW 192.168.1.1 sysLocation.0 s "Salle serveur B2"

# Modifier le contact
snmpset -v2c -c MaCommunityRW 192.168.1.1 sysContact.0 s "admin@example.com"

# Administrativement désactiver une interface (attention !)
snmpset -v2c -c MaCommunityRW 192.168.1.1 IF-MIB::ifAdminStatus.3 i 2

# Types de données pour snmpset :
# s = STRING, i = INTEGER, u = UNSIGNED, a = IPADDRESS, o = OBJID, x = HEX STRING

snmptrap (envoyer un trap)

# Envoyer un trap SNMPv2c
snmptrap -v2c -c MaCommunity 192.168.1.100 '' \
  NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification \
  netSnmpExampleHeartbeatRate i 123456

# Envoyer un trap SNMPv2c avec OID numérique
snmptrap -v2c -c MaCommunity 192.168.1.100 '' \
  .1.3.6.1.4.1.99999.1.0.1 \
  .1.3.6.1.4.1.99999.1.1.1 s "Erreur critique sur le serveur web" \
  .1.3.6.1.4.1.99999.1.1.2 i 1

# Envoyer un trap SNMPv3
snmptrap -v3 -u monUser -l authPriv -a SHA -A "MonAuthPass" -x AES -X "MonPrivPass" \
  192.168.1.100 '' \
  .1.3.6.1.4.1.99999.1.0.1 \
  .1.3.6.1.4.1.99999.1.1.1 s "Service down"

# Réception des traps (snmptrapd)
# Configuration /etc/snmp/snmptrapd.conf
# authCommunity log,execute,net MaCommunity
# traphandle default /usr/local/bin/trap_handler.sh

# Démarrer le démon
sudo systemctl enable --now snmptrapd

9.5 Configuration snmpd sur Linux

# Installer le démon SNMP
sudo apt-get install snmpd snmp

# Configuration /etc/snmp/snmpd.conf

# =========================================
# Configuration SNMPv2c
# =========================================

# Définir les communities et les accès
# Restreindre l'accès par sous-réseau
com2sec readonly  192.168.1.0/24   MaCommunityRO
com2sec readwrite 192.168.1.100/32 MaCommunityRW

# Groupes
group ROGroup v2c readonly
group RWGroup v2c readwrite

# Vues (quels OIDs sont accessibles)
view all    included .1
view system included .1.3.6.1.2.1.1

# Droits d'accès
access ROGroup "" any noauth exact all    none none
access RWGroup "" any noauth exact all    all  none

# =========================================
# Configuration SNMPv3 (recommandé)
# =========================================

# Créer un utilisateur SNMPv3 (arrêter snmpd avant)
sudo systemctl stop snmpd
sudo net-snmp-create-v3-user -ro -A "MonAuthPassphrase" -a SHA -X "MonPrivPassphrase" -x AES monUserV3
sudo systemctl start snmpd

# Ou manuellement dans snmpd.conf :
# createUser monUserV3 SHA "MonAuthPassphrase" AES "MonPrivPassphrase"
# rouser monUserV3 priv

# =========================================
# Options générales
# =========================================

# Informations système
sysLocation    "Datacenter Paris - Salle B2 - Rack 12"
sysContact     "admin@example.com"
sysName        "srv-web-01"

# Écouter sur toutes les interfaces (par défaut localhost uniquement)
# Modifier dans /etc/default/snmpd ou /etc/snmp/snmpd.conf :
agentAddress udp:161

# Activer les métriques étendues
# Monitoring des disques (alerte si < 10% libre)
disk / 10%
disk /var 10%

# Monitoring du load average (alerte si dépassement)
load 4 3 2

# Monitoring des processus
proc apache2 1 0    # Au moins 1 processus apache2
proc sshd 1 0       # Au moins 1 processus sshd

# Extension personnalisée (exécuter un script)
extend check_users /bin/sh -c "who | wc -l"

# Redémarrer pour appliquer
sudo systemctl restart snmpd

# Vérifier
snmpwalk -v2c -c MaCommunityRO localhost system

9.6 SNMP sur équipements réseau (exemple Cisco)

# =========================================
# Configuration SNMP sur un switch/routeur Cisco
# =========================================

# Entrer en mode configuration
enable
configure terminal

# --- SNMPv2c ---

# Définir les communities
snmp-server community MonCommunityRO RO
snmp-server community MonCommunityRW RW

# Restreindre l'accès par ACL
access-list 10 permit 192.168.1.100
access-list 10 permit 192.168.1.101
access-list 10 deny any
snmp-server community MonCommunityRO RO 10

# Définir les informations système
snmp-server location "Datacenter Paris - Salle B2"
snmp-server contact "admin@example.com"

# Configurer les traps (envoi d'alertes)
snmp-server enable traps
snmp-server host 192.168.1.100 version 2c MonCommunityRO

# Traps spécifiques
snmp-server enable traps snmp linkdown linkup coldstart
snmp-server enable traps config
snmp-server enable traps envmon fan shutdown supply temperature
snmp-server enable traps bgp
snmp-server enable traps ospf

# --- SNMPv3 (recommandé) ---

# Créer un groupe SNMPv3
snmp-server group MonGroupeV3 v3 priv read ReadView

# Créer une vue
snmp-server view ReadView iso included

# Créer un utilisateur SNMPv3
snmp-server user monUserV3 MonGroupeV3 v3 auth sha AuthPass123! priv aes 128 PrivPass456!

# Configurer le trap SNMPv3
snmp-server host 192.168.1.100 version 3 priv monUserV3

# Sauvegarder
end
write memory

# --- Vérification ---
show snmp
show snmp community
show snmp user
show snmp host
show snmp group

10. Monitoring réseau

10.1 MRTG et Cacti (RRDtool)

MRTG (Multi Router Traffic Grapher) est l’un des plus anciens outils de supervision réseau. Il interroge les équipements via SNMP et génère des graphiques de trafic au format PNG. Bien que fonctionnel, il est aujourd’hui largement remplacé par des solutions plus modernes.

Cacti reprend le concept de MRTG en y ajoutant une interface web complète, une gestion avancée des templates et le stockage des données dans RRDtool (Round-Robin Database). RRDtool stocke les métriques de manière circulaire, garantissant une taille de base fixe quel que soit l’âge des données.

Caractéristique	MRTG	Cacti
Stockage	Fichiers log propriétaires	RRDtool
Interface	Pages HTML statiques	Interface web dynamique (PHP)
Templates	Configuration manuelle	Templates de graphiques et de données
Scalabilité	Limitée (< 100 équipements)	Moyenne (centaines d’équipements)
Cas d’usage	Petits réseaux, usage basique	PME, graphiques de trafic détaillés

10.2 LibreNMS

LibreNMS est une plateforme de monitoring réseau open source, fork de Observium. Elle offre une auto-découverte complète des équipements réseau via SNMP, CDP, LLDP et ARP.

Fonctionnalités clés

• Auto-découverte : Détection automatique des équipements et de leurs interfaces via SNMP, CDP/LLDP
• Alertes : Système d’alertes flexible avec règles personnalisables (seuils, états, macros)
• Weathermap : Plugin de cartographie réseau affichant le trafic en temps réel sur un schéma topologique
• API REST : API complète pour l’intégration avec d’autres outils
• Distributed polling : Possibilité de répartir la charge de polling sur plusieurs serveurs
• Support multi-OS : Linux, Windows, FreeBSD, Cisco IOS, JunOS, etc.

Installation rapide (Docker)

# Créer le répertoire de travail
mkdir -p /opt/librenms && cd /opt/librenms

# docker-compose.yml minimal
cat <<'EOF' > docker-compose.yml
version: "3.5"
services:
  db:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: librenms_root
      MYSQL_DATABASE: librenms
      MYSQL_USER: librenms
      MYSQL_PASSWORD: librenms_pass
    volumes:
      - db_data:/var/lib/mysql
    restart: unless-stopped

  librenms:
    image: librenms/librenms:latest
    depends_on:
      - db
      - redis
    ports:
      - "8000:8000"
    environment:
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: librenms_pass
      APP_URL: http://localhost:8000
    volumes:
      - librenms_data:/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    restart: unless-stopped

volumes:
  db_data:
  librenms_data:
EOF

# Démarrer
docker compose up -d

# Accéder à http://localhost:8000
# Login par défaut : admin / admin (le changer immédiatement)

Ajouter un équipement

# Via l'interface web : Devices > Add Device
# Ou via la CLI :
lnms device:add 192.168.1.1 --v2c --community public

# Auto-découverte : activer dans Settings > Discovery > General
# Définir les sous-réseaux à scanner
lnms config:set nets.+ "192.168.1.0/24"

10.3 PRTG Network Monitor

PRTG est une solution commerciale (Paessler) de monitoring réseau très populaire en environnement Windows. Elle fonctionne avec un système de capteurs (sensors), chaque capteur surveillant un aspect spécifique (un port, un service, une métrique).

Concepts clés

Concept	Description
Sensor	Unité de mesure de base (ex: Ping, CPU, trafic d’un port, requête HTTP)
Device	Équipement surveillé contenant un ou plusieurs sensors
Group	Regroupement logique de devices (par site, par fonction)
Probe	Serveur d’exécution des sensors (local ou distant “Remote Probe”)
Channel	Sous-métrique d’un sensor (ex: trafic entrant / sortant pour un sensor port)

Fonctionnalités principales

• Auto-découverte : Détection automatique des équipements et des services disponibles sur le réseau
• +250 types de sensors : SNMP, WMI, SSH, HTTP, NetFlow, sFlow, Packet Sniffing, etc.
• Dashboards personnalisables : Cartes, graphiques, jauges, listes en temps réel
• Notifications multi-canaux : Email, SMS, push, Slack, Teams, webhook
• Reporting : Rapports PDF/HTML planifiés, SLA monitoring
• Maps : Cartes réseau automatiques avec état en temps réel

10.4 ntopng – Analyse de flux

ntopng est un outil open source d’analyse de trafic réseau en temps réel. Il capture les paquets ou reçoit des flux NetFlow/sFlow pour fournir une visibilité détaillée sur le trafic.

• Analyse par protocole (L7 DPI – Deep Packet Inspection)
• Top talkers, top destinations, top applications
• Détection d’anomalies et de comportements suspects
• Géolocalisation des flux
• Interface web intuitive avec graphiques interactifs

# Installation ntopng sur Debian/Ubuntu
apt-get install software-properties-common wget
wget https://packages.ntop.org/apt-stable/bookworm/all/apt-ntop-stable.deb
dpkg -i apt-ntop-stable.deb
apt-get update
apt-get install ntopng

# Démarrage
systemctl start ntopng
systemctl enable ntopng

# Accès web : http://localhost:3000
# Login par défaut : admin / admin

10.5 NetFlow, sFlow et IPFIX

Les protocoles de flux permettent de collecter des métadonnées sur le trafic réseau sans capturer l’intégralité des paquets. Ils sont essentiels pour comprendre qui communique avec qui, sur quels ports et avec quel volume.

Protocole	Origine	Principe	Cas d’usage
NetFlow v5/v9	Cisco	Export de métadonnées par flux (IP src/dst, ports, protocole, octets, paquets). V9 ajoute les templates flexibles.	Équipements Cisco, analyse de trafic WAN
IPFIX	IETF (standard)	Évolution standardisée de NetFlow v9. Format extensible via templates. Support natif d’IPv6 et de champs personnalisés.	Environnements multi-constructeurs, conformité
sFlow	InMon	Échantillonnage statistique des paquets (1 paquet sur N). Léger, adapté aux liens haut débit. Inclut aussi des compteurs d’interface.	Datacenters, liens 10/40/100 Gbps, switches compatibles

# Exemple : activer NetFlow v9 sur un routeur Cisco
conf t
ip flow-export version 9
ip flow-export destination 192.168.1.100 9995
ip flow-export source Loopback0

# Activer NetFlow sur une interface
interface GigabitEthernet0/0
 ip flow ingress
 ip flow egress

# Vérifier
show ip flow export
show ip cache flow

10.6 Comparatif des outils de monitoring réseau

Outil	Type	Protocoles	Points forts	Limites
MRTG	Open Source	SNMP	Simple, léger	Obsolète, pas d’interface web dynamique
Cacti	Open Source	SNMP	Templates, graphiques RRDtool	Interface vieillissante, maintenance limitée
LibreNMS	Open Source	SNMP, CDP, LLDP, ARP	Auto-découverte, alertes, API, weathermap	Gourmand en ressources pour les grands parcs
PRTG	Commercial	SNMP, WMI, NetFlow, sFlow, Packet Sniffing	Facile à déployer, dashboards riches, auto-découverte	Windows uniquement (serveur), coût des licences
ntopng	Open Source / Commercial	NetFlow, sFlow, IPFIX, capture paquets	Analyse DPI, géolocalisation, temps réel	Focus analyse de flux, pas de supervision d’état
Zabbix	Open Source	SNMP, ICMP, agent, JMX	Polyvalent, network discovery, maps	Configuration initiale complexe

11. Monitoring applicatif et APM

11.1 Concepts APM

L’APM (Application Performance Monitoring) permet de surveiller les performances des applications de bout en bout. Il s’appuie sur plusieurs concepts fondamentaux :

Concept	Description	Exemple
Trace	Représentation complète d’une requête à travers tous les services (du client au backend et retour)	Une requête HTTP traversant API Gateway → Service Auth → Service Métier → Base de données
Span	Unité de travail individuelle au sein d’une trace (appel de fonction, requête DB, appel HTTP)	SELECT * FROM users WHERE id=42 – durée : 3 ms
Latence	Temps de réponse mesuré pour chaque span ou pour la trace complète	P50 = 45 ms, P95 = 120 ms, P99 = 350 ms
Throughput	Nombre de requêtes traitées par unité de temps	1 200 req/s sur l’endpoint /api/orders
Error Rate	Pourcentage de requêtes en erreur (codes 4xx/5xx, exceptions)	0.5 % de taux d’erreur sur les dernières 24h
Service Map	Cartographie automatique des dépendances entre microservices	Visualisation des appels entre Frontend, API, Auth, DB, Cache

11.2 Uptime Kuma

Uptime Kuma est un outil open source auto-hébergé de monitoring de disponibilité. Léger et simple à déployer, il est idéal pour surveiller la disponibilité de services web, API, serveurs et certificats SSL.

Installation Docker

# Installation rapide avec Docker
docker run -d \
  --name uptime-kuma \
  --restart=unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

# Avec docker-compose
cat <<'EOF' > docker-compose.yml
version: "3"
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:
EOF

docker compose up -d

# Accès : http://localhost:3001
# Créer un compte administrateur au premier lancement

Types de monitors

Type	Description	Vérification
HTTP(S)	Vérifie qu’une URL répond avec le code attendu	Code HTTP 200, mot-clé dans la réponse, temps de réponse
TCP	Vérifie qu’un port TCP est ouvert et répond	Connexion TCP réussie sur le port spécifié
Ping (ICMP)	Vérifie qu’un hôte répond au ping	Réponse ICMP, latence
DNS	Vérifie la résolution DNS d’un domaine	Résolution correcte, temps de réponse DNS
Keyword	Vérifie la présence/absence d’un mot-clé dans une page	Recherche de texte dans le corps de la réponse HTTP
Push	Le service surveillé envoie un heartbeat périodique à Uptime Kuma	Si pas de heartbeat reçu dans le délai, alerte déclenchée
Docker	Vérifie l’état d’un conteneur Docker	Conteneur running, healthy
MySQL/PostgreSQL	Vérifie la connectivité et exécute une requête de test	Connexion réussie, résultat de requête

Notifications et pages de statut

Uptime Kuma supporte plus de 90 services de notification incluant :

• Email (SMTP)
• Slack, Discord, Microsoft Teams
• Telegram, Gotify, Ntfy
• PagerDuty, OpsGenie
• Webhooks personnalisés

Les pages de statut permettent de créer des pages publiques (type status.monsite.fr) affichant l’état de vos services en temps réel, avec historique de disponibilité et incidents.

11.3 Datadog

Datadog est une plateforme SaaS complète d’observabilité couvrant l’infrastructure, les applications, les logs et la sécurité. C’est une solution commerciale haut de gamme utilisée par de nombreuses entreprises tech.

Composants principaux

• Agent Datadog : Agent léger installé sur chaque hôte, collecte les métriques système et applicatives
• Intégrations : Plus de 700 intégrations prêtes à l’emploi (AWS, Docker, Kubernetes, MySQL, Nginx, etc.)
• APM : Tracing distribué avec instrumentation automatique (Java, Python, Node.js, Go, Ruby, PHP, .NET)
• Log Management : Collecte, indexation et analyse des logs centralisés
• Dashboards : Tableaux de bord interactifs avec corrélation métriques/traces/logs

# Installation de l'agent Datadog sur Linux
DD_API_KEY="votre_cle_api" DD_SITE="datadoghq.eu" \
  bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"

# Vérifier le statut de l'agent
sudo datadog-agent status

# Configurer une intégration (ex: MySQL)
sudo nano /etc/datadog-agent/conf.d/mysql.d/conf.yaml
# Ajouter :
# init_config:
# instances:
#   - host: localhost
#     user: datadog
#     pass: motdepasse
#     port: 3306

# Redémarrer l'agent
sudo systemctl restart datadog-agent

11.4 Synthetic monitoring

Le monitoring synthétique simule les actions d’un utilisateur pour vérifier la disponibilité et les performances d’un point de vue externe. Contrairement au monitoring passif (qui analyse le trafic réel), le monitoring synthétique génère activement des requêtes de test.

Types de checks synthétiques

• HTTP Endpoint Check : Vérification périodique d’une URL (code HTTP, temps de réponse, contenu attendu)
• API Check : Tests multi-étapes simulant un parcours API (authentification → requête → vérification réponse)
• Browser Check : Simulation d’un navigateur réel exécutant un scénario (login, navigation, achat) avec mesure des Web Vitals
• Multi-location : Exécution depuis plusieurs points géographiques pour détecter les problèmes régionaux

# Exemple de check HTTP basique avec curl (intégrable dans un cron ou un script)
#!/bin/bash
URL="https://monsite.fr/api/health"
EXPECTED_CODE=200
TIMEOUT=10

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time $TIMEOUT "$URL")

if [ "$HTTP_CODE" -ne "$EXPECTED_CODE" ]; then
    echo "ALERTE : $URL a répondu $HTTP_CODE (attendu: $EXPECTED_CODE)"
    # Envoyer notification (email, webhook, etc.)
fi

11.5 Monitoring des certificats SSL

L’expiration d’un certificat SSL peut rendre un site complètement inaccessible. Il est indispensable de surveiller les dates d’expiration de vos certificats.

# Vérifier l'expiration d'un certificat SSL
echo | openssl s_client -servername monsite.fr -connect monsite.fr:443 2>/dev/null \
  | openssl x509 -noout -dates

# Résultat :
# notBefore=Jan  1 00:00:00 2026 GMT
# notAfter=Apr  1 23:59:59 2026 GMT

# Script de monitoring avec alerte à J-30
#!/bin/bash
DOMAIN="monsite.fr"
WARN_DAYS=30

EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)

EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt "$WARN_DAYS" ]; then
    echo "ATTENTION : Le certificat de $DOMAIN expire dans $DAYS_LEFT jours ($EXPIRY_DATE)"
fi

12. Alerting et notification

12.1 Stratégies d’alerting

Un système d’alerting efficace doit détecter les problèmes rapidement tout en minimisant les fausses alertes. Plusieurs approches complémentaires existent :

Stratégie	Principe	Exemple	Quand l’utiliser
Seuil statique	Alerte quand une métrique dépasse un seuil fixe	CPU > 90 % pendant 5 min	Métriques stables avec des limites connues
Seuil dynamique	Seuil calculé automatiquement à partir de l’historique (baseline)	Trafic 3σ au-dessus de la moyenne hebdomadaire	Métriques saisonnières (trafic web, charge applicative)
Détection d’anomalies	Algorithmes ML détectant les comportements inhabituels	Pic soudain de latence hors pattern habituel	Grandes infrastructures, détection proactive
Tendance (forecast)	Prédiction basée sur la tendance actuelle	Disque plein dans 48h au rythme actuel	Capacity planning, disques, licences
Absence de données	Alerte si aucune donnée reçue pendant une période	Pas de heartbeat depuis 10 min	Agents, tâches planifiées, services critiques
Composite	Combinaison de plusieurs conditions	CPU > 80 % ET RAM > 90 % ET I/O wait > 30 %	Réduire les faux positifs, corrélation

12.2 Alert fatigue – Comment l’éviter

L’alert fatigue est le phénomène où les équipes reçoivent tellement d’alertes qu’elles finissent par les ignorer, y compris les alertes critiques. C’est l’un des problèmes les plus courants en supervision.

Causes principales

• Seuils trop sensibles déclenchant des alertes pour des variations normales
• Absence de déduplication : la même alerte envoyée des dizaines de fois
• Pas de classification : toutes les alertes au même niveau de sévérité
• Alertes non actionnables : on sait qu’il y a un problème mais pas quoi faire
• Manque de corrélation : 50 alertes pour un seul incident root cause

Solutions

• Niveaux de sévérité : Définir clairement Info / Warning / Critical / Emergency avec des canaux différents pour chaque niveau
• Groupement : Regrouper les alertes liées au même incident (Alertmanager : group_by)
• Inhibition : Supprimer les alertes conséquences si la cause racine est déjà signalée
• Silencing / Maintenance : Désactiver temporairement les alertes pendant les maintenances planifiées
• Délai de confirmation : N’alerter qu’après X minutes de problème continu (ex: for: 5m dans Prometheus)
• Révision régulière : Revoir les alertes mensuellement, supprimer celles non actionnables

12.3 Politiques d’escalade

Les politiques d’escalade définissent qui est notifié, quand, et que faire si personne ne répond :

Niveau	Délai	Destinataire	Canal
L1	Immédiat	Technicien d’astreinte	SMS + App mobile + Slack
L2	+15 min sans acquittement	Équipe technique complète	Appel téléphonique + Email
L3	+30 min sans acquittement	Responsable technique / Manager	Appel téléphonique
L4	+1h sans résolution	Direction technique / CTO	Appel + conférence de crise

12.4 Canaux de notification

Canal	Urgence	Avantages	Inconvénients	Outils
Email	Faible	Détaillé, traçabilité, pas intrusif	Délai de lecture, noyé dans la boîte de réception	Tous les outils
Slack	Moyenne	Temps réel, contexte équipe, rich formatting	Peut être ignoré dans le flux de messages	Webhooks, bots natifs
Microsoft Teams	Moyenne	Intégration Office 365, Adaptive Cards	Webhooks moins flexibles que Slack	Incoming Webhooks, Power Automate
Telegram	Moyenne à haute	Notification push immédiate, bot API simple	Usage personnel, moins adapté aux grandes équipes	Bot API
PagerDuty	Haute	Escalade automatique, on-call management, SLA	Coût, complexité de configuration	API, intégrations natives
OpsGenie	Haute	Similaire à PagerDuty, intégration Atlassian (Jira)	Coût	API, intégrations natives
SMS	Haute	Reçu même sans Internet, très intrusif	Coût par message, limite de caractères	Twilio, OVH SMS, passerelles opérateurs

12.5 Templates de notification

Une notification efficace doit contenir toutes les informations nécessaires pour évaluer et réagir rapidement :

# Exemple de template Alertmanager (Go templating)
# Fichier : /etc/alertmanager/templates/custom.tmpl

{{ define "custom_slack_message" }}
{{ range .Alerts }}
*Alerte :* {{ .Labels.alertname }}
*Sévérité :* {{ .Labels.severity }}
*Instance :* {{ .Labels.instance }}
*Description :* {{ .Annotations.description }}
*Valeur actuelle :* {{ .Annotations.value }}
*Début :* {{ .StartsAt.Format "2006-01-02 15:04:05" }}
*Runbook :* {{ .Annotations.runbook_url }}
{{ end }}
{{ end }}

# Exemple de template email Zabbix
# Sujet : [{{ TRIGGER.SEVERITY }}] {{ TRIGGER.NAME }} sur {{ HOST.NAME }}
# Corps :
# Problème détecté à {{ EVENT.TIME }} le {{ EVENT.DATE }}
# Hôte : {{ HOST.NAME }} ({{ HOST.IP }})
# Sévérité : {{ TRIGGER.SEVERITY }}
# Description : {{ TRIGGER.DESCRIPTION }}
# Valeur : {{ ITEM.LASTVALUE }}
# Événement ID : {{ EVENT.ID }}

12.6 Astreintes (on-call) et runbooks

Organisation des astreintes

• Rotation : Alterner les périodes d’astreinte entre les membres de l’équipe (ex: semaines alternées)
• Plages horaires : Définir des plages primaires et secondaires (jours ouvrés / nuits et week-ends)
• Override : Permettre les échanges de permanence entre collègues
• Compensation : Prévoir une compensation (repos, prime) pour les astreintes
• Outils : PagerDuty, OpsGenie, Grafana OnCall (open source) pour gérer les plannings

Structure d’un runbook

# Runbook : Alerte CPU_High_Usage
# Dernière mise à jour : 2026-03-01

## Description
L'utilisation CPU dépasse 90% sur un serveur depuis plus de 5 minutes.

## Impact
- Dégradation des performances applicatives
- Risque de timeout des requêtes utilisateurs

## Diagnostic
1. Se connecter au serveur : ssh user@{{ instance }}
2. Identifier les processus consommateurs : top -bn1 | head -20
3. Vérifier les logs applicatifs : journalctl -u mon-service --since "10 min ago"
4. Vérifier s'il y a un déploiement en cours

## Actions correctives
- Si processus applicatif : redémarrer le service (systemctl restart mon-service)
- Si processus système (backup, cron) : vérifier la planification
- Si OOM proche : ajouter du swap temporairement, planifier un scale-up
- Si attaque/abus : bloquer l'IP source, activer le rate limiting

## Escalade
Si non résolu après 30 min, escalader au L2 (voir politique d'escalade)

13. Bonnes pratiques

13.1 Quoi surveiller en priorité

Il est impossible de tout surveiller dès le départ. Voici un ordre de priorité recommandé :

Priorité	Catégorie	Éléments à surveiller
P0 – Critique	Disponibilité	Services métier accessibles (HTTP 200), bases de données connectées, DNS fonctionnel
P1 – Haute	Ressources vitales	CPU, RAM, espace disque, swap, I/O, charge réseau des serveurs critiques
P2 – Moyenne	Certificats et sécurité	Expiration SSL, backups réussis, mises à jour de sécurité en attente
P3 – Normale	Performances	Temps de réponse applicatif, taux d’erreur, files d’attente, latence DB
P4 – Basse	Capacité	Tendances de croissance, prévisions de saturation, métriques métier

13.2 Baselines et seuils

Une baseline est le comportement normal d’une métrique sur une période donnée. Elle sert de référence pour définir des seuils d’alerte pertinents.

• Établir la baseline : Collecter les métriques pendant au moins 2 à 4 semaines avant de définir des seuils
• Prendre en compte la saisonnalité : Le trafic web peut varier selon l’heure, le jour de la semaine, les périodes commerciales
• Définir deux niveaux : Warning (attention requise mais pas urgente) et Critical (action immédiate nécessaire)
• Revoir régulièrement : Les baselines évoluent avec la croissance de l’infrastructure et du trafic

# Exemple Prometheus : seuils basés sur la baseline
# Warning si CPU au-dessus de la moyenne + 2 écarts types
- alert: CPU_Above_Baseline_Warning
  expr: |
    node_cpu_usage >
    avg_over_time(node_cpu_usage[7d]) + 2 * stddev_over_time(node_cpu_usage[7d])
  for: 15m
  labels:
    severity: warning

# Critical si CPU au-dessus de la moyenne + 3 écarts types
- alert: CPU_Above_Baseline_Critical
  expr: |
    node_cpu_usage >
    avg_over_time(node_cpu_usage[7d]) + 3 * stddev_over_time(node_cpu_usage[7d])
  for: 5m
  labels:
    severity: critical

13.3 Dashboards efficaces – Les quatre signaux d’or

Google SRE définit les quatre signaux d’or (Golden Signals) comme les métriques essentielles à afficher sur tout dashboard de service :

Signal	Description	Métriques typiques	Visualisation recommandée
Latence	Temps de réponse des requêtes (distinguer succès / erreurs)	P50, P95, P99 du temps de réponse HTTP	Graphique en lignes avec percentiles
Trafic	Volume de demandes reçues par le système	Requêtes/seconde, sessions actives, messages/s	Graphique en aires empilées
Erreurs	Taux de requêtes en échec	% HTTP 5xx, exceptions/s, timeout rate	Graphique en barres ou compteur
Saturation	Degré de remplissage des ressources	% CPU, % RAM, % disque, longueur de file d’attente	Jauges (gauges) avec seuils colorés

Bonnes pratiques pour les dashboards

• Un dashboard par service / équipe : Éviter les dashboards fourre-tout qui mélangent tout
• Hiérarchie : Vue d’ensemble (overview) → Dashboard par service → Dashboard de détail
• Annotations : Marquer les déploiements, maintenances et incidents directement sur les graphiques
• Variables : Utiliser les variables Grafana (environment, host, service) pour des dashboards réutilisables
• Alertes visibles : Intégrer l’état des alertes directement dans le dashboard

13.4 Documentation du monitoring

La configuration du monitoring doit être documentée au même titre que l’infrastructure :

• Inventaire des checks : Liste de tous les services surveillés, types de checks, seuils configurés
• Runbooks : Procédure de diagnostic et de résolution pour chaque alerte
• Schéma d’architecture : Diagramme montrant les flux de données de monitoring (agents → collecteurs → stockage → visualisation)
• Matrice d’escalade : Qui est contacté pour chaque type d’alerte et à quel moment
• Infrastructure as Code : Stocker la configuration du monitoring dans Git (règles Prometheus, dashboards Grafana en JSON, templates Zabbix)

13.5 Révision régulière

Le monitoring n’est pas un système « installé et oublié ». Planifiez des revues régulières :

• Mensuelle : Revoir les alertes déclenchées – supprimer les faux positifs, ajuster les seuils
• Trimestrielle : Vérifier que tous les nouveaux services sont surveillés, mettre à jour les runbooks
• Post-incident : Après chaque incident majeur, vérifier si le monitoring a détecté le problème à temps et ajouter les checks manquants
• Annuelle : Évaluer si les outils utilisés sont toujours adaptés aux besoins, considérer les évolutions

13.6 Capacity planning

Le capacity planning utilise les données de monitoring pour anticiper les besoins futurs en ressources :

• Tendances : Analyser la croissance des métriques sur 3, 6, 12 mois (espace disque, nombre d’utilisateurs, trafic)
• Prévisions : Utiliser les fonctions predict_linear() de Prometheus ou les forecasts Grafana pour prédire les dates de saturation
• Alertes préventives : Alerter quand une ressource atteindra sa capacité maximale dans X jours
• Rapports : Générer des rapports de capacité pour justifier les investissements auprès de la direction

# Prometheus : prédire quand le disque sera plein
# predict_linear() extrapole la tendance linéaire
- alert: DiskWillFillIn48Hours
  expr: |
    predict_linear(
      node_filesystem_avail_bytes{mountpoint="/"}[24h], 48 * 3600
    ) < 0
  for: 30m
  labels:
    severity: warning
  annotations:
    description: "Le disque {{ $labels.mountpoint }} sur {{ $labels.instance }} sera plein dans moins de 48h"

13.7 Haute disponibilité du monitoring

Le monitoring lui-même doit être résilient. Un monitoring en panne est le pire scénario : vous ne savez pas ce que vous ne voyez pas.

Composant	Stratégie HA
Prometheus	Deux instances identiques scrapant les mêmes cibles + Thanos ou Cortex pour la déduplication et le stockage longue durée
Alertmanager	Cluster natif de 2-3 instances avec déduplication automatique des alertes via le protocole gossip
Grafana	Plusieurs instances derrière un load balancer, base PostgreSQL/MySQL en HA pour la config
Zabbix	Zabbix Proxy pour le polling distribué, base de données en cluster (Galera, PostgreSQL HA)
ELK	Cluster Elasticsearch multi-nœuds avec réplicas, Logstash en pipeline distribuée, Kafka comme buffer

13.8 Sauvegarde de la configuration de monitoring

La configuration de votre monitoring représente des heures de travail. Sauvegardez-la systématiquement :

• Fichiers de configuration : Rules Prometheus, alertmanager.yml, dashboards Grafana (JSON), templates Zabbix → versionnés dans Git
• Bases de données : Sauvegarder la base Zabbix/Grafana/Centreon régulièrement (mysqldump, pg_dump)
• Données historiques : Configurer la rétention (Prometheus : --storage.tsdb.retention.time, Elasticsearch : ILM policies)
• Automatisation : Utiliser Ansible, Terraform ou des Helm charts pour pouvoir reconstruire l’infrastructure de monitoring rapidement

# Sauvegarder les dashboards Grafana via l'API
#!/bin/bash
GRAFANA_URL="http://localhost:3000"
API_KEY="votre_api_key"
BACKUP_DIR="/opt/backup/grafana/dashboards"

mkdir -p "$BACKUP_DIR"

# Lister tous les dashboards
UIDS=$(curl -s -H "Authorization: Bearer $API_KEY" \
  "$GRAFANA_URL/api/search?type=dash-db" | jq -r '.[].uid')

# Exporter chaque dashboard en JSON
for uid in $UIDS; do
    TITLE=$(curl -s -H "Authorization: Bearer $API_KEY" \
      "$GRAFANA_URL/api/dashboards/uid/$uid" | jq -r '.dashboard.title')
    curl -s -H "Authorization: Bearer $API_KEY" \
      "$GRAFANA_URL/api/dashboards/uid/$uid" > "$BACKUP_DIR/${TITLE}.json"
    echo "Exporté : $TITLE"
done

echo "Sauvegarde terminée : $(ls $BACKUP_DIR | wc -l) dashboards"

14. Comparatif des solutions

14.1 Tableau comparatif général

Solution	Type	Installation	Courbe d’apprentissage	Scalabilité	Communauté	Cas d’usage idéal
Nagios Core	Open Source	Manuelle, complexe	Élevée	Moyenne (plugins)	Très large, historique	Sysadmins expérimentés, monitoring classique
Centreon	Open Source / Commercial	Simplifiée (ISO, paquets)	Moyenne	Bonne (architecture distribuée)	Forte (France, Europe)	PME/ETI, environnements hétérogènes
Zabbix	Open Source	Paquets, Docker, appliance	Moyenne à élevée	Excellente (proxies, partitioning)	Très large, internationale	Toutes tailles, monitoring infrastructure complet
Prometheus + Grafana	Open Source	Binaires, Docker, Helm	Moyenne (PromQL)	Excellente (Thanos, Cortex)	Très large (CNCF)	Cloud-native, Kubernetes, microservices
ELK Stack	Open Source / Commercial	Moyenne (cluster ES)	Élevée	Excellente (cluster distribué)	Très large	Centralisation de logs, recherche full-text, SIEM
Graylog	Open Source / Commercial	Moyenne	Moyenne	Bonne	Large	Gestion de logs structurés, alternative à ELK
PRTG	Commercial	Simple (installeur Windows)	Faible	Bonne (Remote Probes)	Large	PME Windows, monitoring réseau rapide à déployer
Datadog	Commercial (SaaS)	Très simple (agent)	Faible à moyenne	Illimitée (SaaS)	Large	Entreprises cloud, observabilité complète, budget élevé
LibreNMS	Open Source	Simple (Docker, script)	Faible à moyenne	Bonne (distributed polling)	Large	Monitoring réseau, équipements SNMP
Uptime Kuma	Open Source	Très simple (Docker)	Très faible	Limitée (instance unique)	Croissante	Monitoring de disponibilité, pages de statut, petites équipes
Checkmk	Open Source / Commercial	Simple (paquets, appliance)	Moyenne	Bonne (sites distribués)	Large (Europe)	Monitoring infrastructure, alternative moderne à Nagios
Icinga 2	Open Source	Paquets, configuration DSL	Moyenne à élevée	Bonne (cluster, satellites)	Large	Fork moderne de Nagios, grands parcs, automatisation

14.2 Recommandations par taille d’entreprise

TPE / PME (1 à 250 postes)

• Budget limité : Uptime Kuma (disponibilité) + Zabbix ou Checkmk (infrastructure) + Grafana (dashboards)
• Environnement Windows : PRTG (100 sensors gratuits, déploiement rapide)
• Réseau : LibreNMS pour le monitoring des switches, routeurs, AP Wi-Fi
• Priorité : Simplicité de déploiement et de maintenance avec une équipe réduite

ETI (250 à 5 000 postes)

• Infrastructure : Zabbix ou Centreon (support commercial disponible, architecture distribuée)
• Logs : Graylog ou ELK Stack pour la centralisation et l’analyse
• Cloud / Kubernetes : Prometheus + Grafana pour les environnements conteneurisés
• APM : Datadog (si budget) ou stack open source (Jaeger + Prometheus)
• Priorité : Intégration des outils entre eux, automatisation, scalabilité

Grande entreprise (5 000+ postes)

• Observabilité unifiée : Datadog ou combinaison Prometheus + Thanos + Grafana + Loki + Tempo (stack Grafana complète)
• Infrastructure legacy : Zabbix ou Centreon IT Edition avec support éditeur
• SIEM / Sécurité : ELK + Elastic Security ou solution dédiée (Splunk, QRadar)
• Réseau : LibreNMS + ntopng + collecteurs NetFlow/sFlow
• Priorité : HA, scalabilité horizontale, corrélation multi-sources, SLA, conformité