Supervise une infrastructure avec Centreon

01Ce TP ne reconstruit pas le cours d’observabilité

Les principes existent déjà dans SORIA Académie. Réutilise notamment :

reseaux/superviser-symptomes-alerter
reseaux/diagnostiquer-service-bout-en-bout
reseaux/cartographier-services-ports-chiffrement
reseaux/filtrer-flux-inter-vlan-nftables
reseaux/sauvegarder-documenter-exploitation

hardening/etablir-etat-initial-surfaces-exposition
hardening/reduire-services-ports-logiciels-inutiles
hardening/construire-baseline-role-criticite

bts-sisr/construire-dossier-preuves
bts-sisr/conduire-diagnostic-remediation
linux/deployer-apache-dmz

Prometheus/Grafana restent la référence SORIA pour métriques, tableaux de bord et alertes orientées signaux. Ici, le geste nouveau est ciblé : superviser des hôtes et services d’infrastructure avec Centreon puis exploiter un incident.

02Scénario SORIA Distribution

Le laboratoire dispose d’une plateforme Centreon déjà installée et d’une infrastructure minimale :

ZONE-MONITORING
  MON-CENTREON01
       |
       | checks autorisés et documentés
       v
DMZ
  WEB-DMZ01
  - Nginx : HTTPS 443
  - Apache backend local : 127.0.0.1:8080

LAN-SERVERS
  SRV-DNS01

Le TP ne transforme pas l’installation complète de Centreon en prérequis pédagogique. L’objectif est l’exploitation : déclarer ou découvrir les objets utiles, appliquer des checks, comprendre leurs résultats et conduire un incident.

La topologie et les adresses restent synthétiques. Aucun équipement de production SORIA n’est utilisé.

03Commence par le service rendu, pas par l’outil

Avant de créer un objet Centreon, écris ce que tu veux prouver.

Exemple :

Une ressource UP n’implique pas que son service applicatif est fonctionnel. Inversement, un check UNKNOWN peut signaler un problème de sonde, d’argument, d’agent ou de chemin de supervision plutôt qu’une panne du service utilisateur.

04Établis la matrice de flux de supervision

Ne désactive jamais le filtrage « pour que Centreon fonctionne ». Documente les besoins avant toute règle.

Exemple de matrice à adapter à ton laboratoire :

Pour chaque règle ajoutée, conserve :

source
destination
protocole/port
raison
preuve positive
preuve négative
mécanisme de rollback

05Ajoute l’hôte avec un modèle explicite

Centreon organise la supervision autour d’hôtes et de services. Les modèles et Monitoring Connectors permettent de réutiliser les checks sans recopier chaque configuration.

Pour WEB-DMZ01, renseigne au minimum :

nom logique       : WEB-DMZ01
adresse            : IP ou FQDN du laboratoire
poller             : poller prévu par l'architecture
host template      : adapté au type de supervision retenu
service critique   : HTTPS du portail

Après modification de la configuration, applique le mécanisme de déploiement prévu par ton environnement Centreon puis vérifie que l’objet n’est plus PENDING et qu’un résultat de check réel est disponible.

L’interface exacte peut évoluer selon la version. La preuve demandée porte sur l’objet, le check exécuté et son résultat, pas sur la mémorisation d’un chemin de menu.

06Ajoute un service qui teste réellement le portail

Le check du portail doit viser le service tel qu’il est consommé.

Paramètres fonctionnels attendus :

protocole        = HTTPS
nom attendu      = portail.dmz.soria.test
port             = 443
réponse attendue = succès HTTP défini par le scénario
TLS              = validation cohérente avec le laboratoire

Un Monitoring Connector ou une commande de check appelle un plugin. Les templates servent à transmettre les paramètres et seuils de façon réutilisable.

Ne crée pas un plugin maison si un check standard couvre le besoin. Un custom command est une extension avancée, pas le point de départ de ce TP.

07Lis correctement les états

Pour un service, Centreon expose notamment :

OK       = le check satisfait les conditions attendues
WARNING  = seuil ou condition dégradée
CRITICAL = condition critique détectée
UNKNOWN  = le check n'a pas pu déterminer correctement l'état
PENDING  = aucun résultat exploitable n'est encore disponible

Ne transforme jamais mécaniquement UNKNOWN en « serveur en panne ».

Construis une fiche d’interprétation :

08Établis la baseline saine

Avant toute panne volontaire, collecte une preuve commune T0 :

WEB-DMZ01 : état hôte observé
HTTPS     : état OK
sortie du check : conservée
heure du dernier check : conservée
résolution DNS depuis le poller : validée
flux réseau attendu : validé
accès HTTPS depuis un client légitime : validé
accès interdit vers une cible non autorisée : toujours refusé

Cette baseline permet de comparer l’incident et la reprise.

09Panne A — arrête le service exposé

Dans le laboratoire uniquement, provoque une panne simple du frontal web, par exemple en arrêtant le service Nginx après avoir préparé le rollback.

Observe successivement :

T1 : service utilisateur indisponible
T2 : nouveau résultat Centreon
T3 : état non-OK confirmé selon la politique de checks
T4 : diagnostic de la cause

Conserve le message du check et l’heure de transition.

Ne modifie pas le seuil ou la commande pour faire disparaître l’alerte. Répare la cause.

10Prends en compte l’incident sans masquer la panne

Un acknowledgement signifie que l’incident a été pris en compte. Il ne répare pas le service et ne doit pas servir à transformer visuellement un problème en succès.

Dans le commentaire d’acquittement, indique au minimum :

qui prend l'incident en charge
hypothèse actuelle
prochaine action
ticket ou référence pédagogique

Un downtime correspond à une période de maintenance planifiée ou contrôlée. Il sert notamment à éviter des notifications inutiles pendant une intervention connue ; il ne doit pas être utilisé après coup pour cacher un incident réel dans les preuves.

11Restaure puis prouve le recovery

Remets le service dans son état attendu avec le mécanisme de retour préparé.

La preuve de reprise doit relier :

service restauré côté système
→ service accessible depuis le client
→ check Centreon redevenu sain
→ heure de recovery
→ politique réseau toujours respectée

Une capture OK sans preuve de la restauration ni du test utilisateur n’est pas suffisante.

12Panne B — casse le chemin de supervision, pas le service

Cette deuxième panne est essentielle pour distinguer indisponibilité métier et indisponibilité de mesure.

Dans le laboratoire, bloque uniquement le flux nécessaire entre le poller et la cible ou introduis une erreur contrôlée dans le paramètre du check, sans arrêter le portail lui-même.

Tu dois démontrer :

portail toujours accessible depuis le client légitime
check Centreon en échec ou UNKNOWN selon le scénario
cause située dans la chaîne de supervision
correction bornée
retour du check à l'état sain

Ce test montre qu’une alerte est un signal à interpréter, pas une preuve automatique de cause racine.

13Ajoute des seuils seulement lorsqu’ils ont un sens

Un seuil doit représenter une dégradation exploitable.

Pour une mesure quantitative, documente :

métrique observée
unité
seuil WARNING
seuil CRITICAL
raison de ces valeurs
risque de faux positif / faux négatif

N’invente pas un seuil « standard BTS ». Les valeurs dépendent du scénario, du service et de la politique d’exploitation.

Pour un simple check fonctionnel HTTPS, l’état attendu peut être binaire sans seuil numérique artificiel.

14Durcis aussi la supervision

Le système de supervision concentre des informations sensibles sur l’infrastructure. Applique les mêmes principes de moindre privilège que pour les autres composants :

console non exposée publiquement
comptes nominatifs ou rôles adaptés au laboratoire
secrets de checks hors captures et dépôt Git
flux du poller limités aux besoins
checks non privilégiés lorsque possible
accès d'administration séparé du trafic supervisé
changements traçables

Si des droits Centreon sont délégués, limite les actions au périmètre nécessaire : lecture, acquittement ou maintenance ne justifient pas automatiquement des droits d’administration globale.

15Compare Centreon et Prometheus sans chercher un vainqueur

Complète le tableau avec ce que tu as réellement observé :

La conclusion attendue n’est pas « l’un remplace l’autre ». Les deux approches peuvent se compléter et la compétence BTS reste indépendante du produit.

16Dossier de preuves

Pour clôturer le TP, construis un tableau :

Ajoute les preuves négatives qui montrent que les flux interdits restent interdits.