Aller au contenu

TP – Superviser, centraliser les journaux et diagnostiquer

BTS SIO SISR 2e année – Bloc 2 – S11 – binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Tu choisis des indicateurs et des seuils pour le Cabinet Delorme, tu centralises les journaux de deux machines avec rsyslog, tu configures une supervision avec Zabbix (alerte sur un service et sur un script), puis tu exploites des alertes pour diagnostiquer un incident.

Durée : 2 h 40 (parties A à E), plus le bilan. Prérequis : cours S11 lu ; S09 (scripts) ; supervision de première année ; un serveur Zabbix fonctionnel (celui de la première année ou un modèle fourni).

Note

Comment ce TP fonctionne. Avant de manipuler, tu écris ce que tu anticipes, puis tu testes et tu notes ce que tu constates. Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Le laboratoire

Machine Rôle Adresse
SUP Serveur Zabbix et serveur de journaux 192.168.10.10/24
web1 Serveur web supervisé, client de journaux 192.168.10.11/24
web2 Second serveur, client de journaux 192.168.10.12/24

(Les mêmes machines que S08. Chaque machine doit être à l'heure : timedatectl doit afficher System clock synchronized: yes.)

Partie A – Choisir indicateurs et seuils (≈ 25 min)

Pour le Cabinet Delorme (serveur de fichiers, messagerie, comptabilité, accès Internet), complète :

Service Indicateur mesuré Avertissement Critique Mesures consécutives Réaction
Serveur de fichiers
Messagerie
Sauvegarde nocturne
Accès Internet

Service dégradé. Pour la messagerie, quelle alerte de niveau service dégradé ajoutes-tu (un composant redondant arrêté, service encore rendu) ? ______________________

J'anticipe. Pourquoi « le processeur dépasse 90 % » est-il un mauvais déclencheur d'astreinte à lui seul ? ______________________

Éléments de réponse

Un pic de processeur est souvent normal (sauvegarde, mise à jour) et ne cause pas de gêne pour l'utilisateur : alerte non actionnable, donc ignorée. On alerte sur le service rendu (temps de réponse, échecs) et on garde le processeur comme indicateur de diagnostic ou d'avertissement sur une durée.

Service dégradé : alerte sur l'arrêt d'un des deux serveurs (ou de la copie de secours) alors que l'envoi de test réussit ; réaction : ticket sous 24 h, rétablissement de la redondance.

Exemple de réponse : fichiers : espace disque libre, 20 % puis 10 %, 3 mesures, ticket puis appel ; messagerie : envoi et réception de test, échec 2 mesures, appel ; sauvegarde : code de retour de la tâche, tout échec, ticket le jour même ; Internet : ping d'une adresse extérieure et test DNS, échec 3 mesures, appel de l'opérateur.

Partie B – Centraliser les journaux avec rsyslog (≈ 45 min)

Préparation (SUP, web1, web2). Sur Debian, rsyslog n'est pas toujours installé : sudo apt -y install rsyslog (carte NAT temporaire si besoin, voir S06).

Sur SUP (serveur).

1. Crée /etc/rsyslog.d/10-serveur.conf :

module(load="imtcp")
input(type="imtcp" port="514")

template(name="ParHote" type="string" string="/var/log/centralise/%HOSTNAME%/%PROGRAMNAME%.log")
if $fromhost-ip != '127.0.0.1' then {
    action(type="omfile" dynaFile="ParHote")
    stop
}

2. Prépare le dossier, vérifie la syntaxe, redémarre, contrôle l'écoute :

sudo mkdir -p /var/log/centralise
sudo rsyslogd -N1
sudo systemctl restart rsyslog
ss -tln | grep :514

Sur web1 et web2 (clients).

3. Crée /etc/rsyslog.d/90-client.conf :

*.* action(type="omfwd" target="192.168.10.10" port="514" protocol="tcp"
           action.resumeRetryCount="-1" queue.type="LinkedList" queue.size="10000" queue.filename="fwd_srv" queue.saveOnShutdown="on")

4. Vérifie, redémarre, puis émets des messages de test :

sudo rsyslogd -N1
sudo systemctl restart rsyslog
logger -t sauvegarde "OK test depuis $(hostname)"
logger -t sauvegarde "ECHEC test depuis $(hostname)"

5. Sur SUP, retrouve les messages :

sudo ls -R /var/log/centralise
sudo grep -r ECHEC /var/log/centralise

J'anticipe. Dans quel fichier de SUP arrivera le message de web1 ? Et si web2 est éteint, que fera le client web2 de ses messages ? ______________________

Éléments de réponse

Dans /var/log/centralise/web1/sauvegarde.log (dossier par machine, fichier par programme, d'après le modèle ParHote). Si SUP est injoignable, le client met les messages en file d'attente (queue.type="LinkedList", sauvegarde sur disque) et les envoie au retour du serveur : la ligne action.resumeRetryCount="-1" signifie « réessayer indéfiniment ».

Je comprends. Pourquoi utiliser TCP plutôt qu'UDP pour envoyer les journaux ? Quelle autre protection faudrait-il en production ? ______________________

Éléments de réponse

UDP n'a aucune garantie de livraison : un message perdu pendant l'incident est justement celui qu'on cherche. TCP accuse réception. En production, on chiffre le transport (TLS), on restreint les machines autorisées à envoyer (pare-feu) et l'accès aux journaux, et on fixe une durée de conservation.

Point de contrôle : le message ECHEC test depuis web1 apparaît sur SUP.

Partie C – Alerter avec Zabbix (≈ 45 min)

Note

Cette partie s'appuie sur l'interface web de Zabbix (version 6.0 ou 7.0). Les intitulés de menus changent légèrement d'une version à l'autre.

1. Service rendu. Ajoute web1 comme hôte (agent ou, plus simplement, contrôles simples). Crée un item :

Champ Valeur
Nom Service web répond
Type Contrôle simple
Clé net.tcp.service[http,192.168.10.11]
Intervalle 30 s

La clé renvoie 1 si le service répond, 0 sinon.

2. Déclencheur avec plusieurs mesures. Crée un déclencheur :

Champ Valeur
Nom Service web indisponible sur
Expression min(/web1/net.tcp.service[http,192.168.10.11],#3)=0
Gravité Haute

(« Les 3 dernières mesures valent toutes 0 ».)

3. Provoquer et constater. Sur web1 : sudo systemctl stop apache2. Note l'heure d'arrêt, puis l'heure d'apparition du problème dans Zabbix ; redémarre Apache, note l'heure de résolution.

Événement Heure
Arrêt d'Apache
Problème affiché
Retour du service
Problème résolu

J'anticipe. Avec un intervalle de 30 s et l'expression #3, après combien de temps environ le problème s'affiche-t-il ? Quel est le prix de ce choix ? ______________________

Éléments de réponse

Environ 60 à 90 secondes : trois mesures consécutives à 30 s d'intervalle. Le prix : un délai de détection plus long, en échange de la suppression des fausses alertes dues à une mesure isolée. C'est un compromis à fixer avec le client (S02).

4. Superviser un script (S09). Sur web1, copie rapport.sh dans /usr/local/bin/ (droits d'exécution), puis déclare un paramètre utilisateur dans /etc/zabbix/zabbix_agentd.d/rapport.conf (ou zabbix_agent2.d selon l'agent) :

UserParameter=rapport.code,/usr/local/bin/rapport.sh 80 90 >/dev/null 2>&1; echo $?

Redémarre l'agent, crée l'item rapport.code et un déclencheur last(/web1/rapport.code)=1. Provoque l'alerte en abaissant temporairement le seuil à 1 dans la ligne UserParameter.

Je comprends. Pourquoi superviser le code de retour d'un script plutôt que de lire son affichage ? ______________________

Éléments de réponse

Le code de retour est une valeur simple, mesurable, comparable à un seuil : c'est ce que sait traiter un système d'alerte. Un affichage en texte libre demande de l'analyser. C'est aussi pourquoi les scripts de S09 renvoient des codes précis.

5. Notification. Crée une action qui envoie une notification (messagerie ou media type du laboratoire) à un utilisateur de ton choix quand ce déclencheur passe en problème. Vérifie la réception.

Partie D – Corréler alerte et journal (≈ 25 min)

Sur web1, simule un échec de sauvegarde puis cherche-le sans te connecter à web1 :

logger -t sauvegarde "ECHEC (code 2) : /home/utilisateur/donnees"

Sur SUP :

sudo grep -r "ECHEC" /var/log/centralise/
sudo grep -r "" /var/log/centralise/web1/ | sort | tail -20

Je comprends. Quelle information l'alerte te donne-t-elle ? Que t'apporte le journal en plus ? ______________________

Éléments de réponse

L'alerte dit quoi (service indisponible) et quand. Le journal dit pourquoi et ce qui s'est passé juste avant (autres messages de la même machine, erreurs d'un service voisin). Les deux, corrélés dans le temps, permettent le diagnostic.

Partie E – Diagnostiquer à partir des alertes (≈ 20 min)

Voici ce que montrent Zabbix et les journaux centralisés un lundi matin :

Heure Source Message
02:00 web1 / sauvegarde DEBUT : /home/utilisateur/donnees
02:03 web1 / sauvegarde ECHEC (code 2) : /home/utilisateur/donnees
02:04 Zabbix Espace disque faible sur web1 (95 %)
07:30 Zabbix Service web indisponible sur web1
07:31 web1 / apache2 No space left on device
07:35 Zabbix Appels des utilisateurs : « le site ne répond plus »
  1. Quelle est la cause racine ? Quelle alerte aurait dû déclencher une intervention avant 07:35 ?
  2. Quelles deux corrections proposes-tu (immédiate, durable) ?
  3. Quel seuil ou quelle règle modifierais-tu dans la supervision ?
Éléments de réponse
  1. Disque saturé : la sauvegarde a échoué à 02:03 (plus de place) puis l'espace faible a été signalé à 02:04 et personne n'a réagi ; Apache n'a plus pu écrire (07:31). L'alerte de 02:04 (ou l'échec de sauvegarde à 02:03) devait déclencher l'intervention.
  2. Immédiate : libérer de l'espace (anciens journaux, archives), redémarrer Apache, relancer la sauvegarde. Durable : rotation des archives, journaux limités, augmentation du disque, supervision de la croissance.
  3. Passer l'espace disque en avertissement à 80 % (ticket) et critique à 90 % (appel), et faire de l'échec de sauvegarde une alerte critique ; vérifier que quelqu'un est destinataire des notifications.

Pour aller plus loin

  • Ajoute une dépendance : web1 et web2 dépendent d'un routeur ; que devient l'alerte si le routeur tombe ?
  • Chiffre l'envoi des journaux en TLS (module gtls de rsyslog).
  • Ajoute une rotation de /var/log/centralise avec logrotate.

Retour en entreprise (si ta situation le permet)

  • Observer : que supervise ton entreprise ? Qui reçoit les alertes ? Existe-t-il un serveur de journaux ?
  • Documenter : liste cinq alertes réelles et classe-les : actionnables ou non, trop sensibles ou trop tolérantes.

Rendu

Compte rendu PDF, nommé RENDU-B2A2-S11-NOM.pdf, contenant : le tableau des indicateurs, les fichiers rsyslog, la capture du message arrivé sur SUP, les captures Zabbix (item, déclencheur, problème, résolution) avec le tableau des heures, le raisonnement de la partie E.

Bilan de la séance

Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise, ou Non évalué.

Compétence du référentiel Ce que j'ai fait dans cette séance Niveau
B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau

Note

Les codes sont ceux du référentiel.

Je sais faire, sans aide :

  • Choisir des indicateurs proches du service rendu et des seuils utiles ;
  • Centraliser les journaux de plusieurs machines (rsyslog, TCP) ;
  • Configurer un item, un déclencheur et une notification ;
  • Superviser un script par son code de retour ;
  • Corréler alerte et journaux pour retrouver la cause.

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________