Cours/Saison B3
Saison B34 modules

Saison B3. Supervision

Modules

B301B301. Introduction : Monitoring & SupervisionB302B302. Présentation de ZabbixB303️ B303. Les Agents ZabbixB304B304. Nagios

Cette saison se concentre sur la "santé" du Système d'Information. L'objectif est de passer d'une gestion réactive ("C'est cassé, on répare") à une gestion proactive ("Ça va casser, on intervient"). On y apprendra à collecter des métriques, gérer des alertes et utiliser les protocoles standards comme SNMP.

📊 B301. Introduction : Monitoring & Supervision

Ce premier cours pose les bases théoriques. Il distingue la collecte de données (Monitoring) de l'analyse décisionnelle (Supervision) et introduit le protocole roi des réseaux : SNMP.

1. Supervision vs Monitoring : Quelle différence ?

Bien que souvent utilisés comme synonymes, ces termes ont une nuance importante :

  • Monitoring (Surveillance) : C'est l'action technique de collecter des données en temps réel sur l'état des composants (ex: "Le CPU est à 80%"). C'est le thermomètre.
  • Supervision (Pilotage) : C'est l'étape supérieure. Elle analyse ces données pour prendre des décisions, déclencher des alertes, visualiser l'état global et parfois automatiser des corrections (ex: "Le CPU est > 80% depuis 5min -> Alerte Critique -> Redémarrage du service").

Pourquoi superviser ? Pour garantir la disponibilité (le service est-il accessible ?), la performance (est-il rapide ?) et la sécurité du SI. L'objectif final est de réduire les temps d'arrêt et d'améliorer la productivité.

2. Les Données de la Supervision

Pour surveiller un système, on s'appuie sur trois piliers :

  • Les Métriques (Chiffres) : Données quantitatives mesurables (ex: Temps de réponse, % RAM utilisée, Débit réseau). Elles servent à faire des graphiques et voir l'évolution.

  • Les Logs (Journaux) : Données qualitatives/textuelles. Ce sont les enregistrements d'événements passés (ex: "Connexion échouée de l'utilisateur admin").

  • Les Alertes (Notifications) : Message envoyé à l'administrateur lorsqu'une métrique dépasse un seuil. On distingue 3 niveaux :

    • ℹ️ Info : Pour suivi.
    • ⚠️ Warning : Problème potentiel, à surveiller.
    • 🚨 Critique : Incident majeur, intervention immédiate requise.

    KPI & SLA : Les métriques deviennent des KPI (Indicateurs Clés de Performance) qui permettent de vérifier si l'on respecte les SLA (Accords de niveau de service définis avec le client) .

3. Méthodes et Stratégies

  • Proactif vs Réactif : Le but est d'être Proactif (anticiper la panne avant qu'elle n'impacte l'utilisateur) plutôt que Réactif (réparer après la panne) .

  • Push vs Pull :

    • Polling (Pull) : Le serveur de supervision demande régulièrement "Ça va ?" à l'équipement.
    • Push : L'équipement envoie lui-même l'info quand elle change.

  • Agent vs Agentless :

    • Avec Agent : On installe un petit logiciel sur le serveur cible (plus précis, mais intrusif).
    • Agentless : On utilise des protocoles standards sans rien installer (ex: SNMP, WMI).

4. Le Protocole SNMP (Simple Network Management Protocol)

C'est le standard universel pour superviser les équipements réseaux (routeurs, switchs) et serveurs sans agent.

Architecture en 3 composants :

  1. Manager (Serveur de supervision) : Il pose les questions (Zabbix, Nagios...).
  2. Agent (Équipement) : Il répond aux questions ou envoie des alertes.
  3. MIB (Management Information Base) : La base de données hiérarchique qui contient toutes les infos possibles. Chaque info a une adresse unique appelée OID (ex: 1.3.6.1... pour le nom du système).

Fonctionnement :

  • GET : Le Manager demande une info ("Quelle est ta charge CPU ?"). C'est du Polling.
  • TRAP : L'Agent envoie une alerte spontanée ("Alerte ! Interface Down !"). C'est du Push (ou Alerting).

Les Versions de SNMP :

  • v1 & v2c (Le plus courant) : Simple mais non sécurisé. Le mot de passe (appelé Community String) circule en clair sur le réseau.

  • v3 (Le standard recommandé) : Complexe mais sécurisé. Il apporte l'authentification (login/mdp) et le chiffrement des échanges.

5. Outils du marché

Quelques noms cités dans le cours pour la culture générale:

  • Open Source : Zabbix, Nagios, Centreon.
  • Commercial : PRTG.

En résumé 💡

  • Supervision = Analyse & Décision / Monitoring = Collecte.

  • SNMP est le protocole roi du réseau. Il utilise le Port 161 (UDP) pour les questions (GET) et 162 (UDP) pour les alertes (TRAP).

  • En production, on évite SNMP v1/v2c (mot de passe "public" en clair) et on privilégie SNMP v3 pour la sécurité.

Challenge B301 : Installation de Zabbix

📚 Ressources :

Retour en haut

🤖 B302. Présentation de Zabbix

Découvrons Zabbix, la solution Open Source de référence pour la supervision d'entreprise. Comprendre comment ses différents composants s'articulent pour collecter, stocker et visualiser l'état de santé du Système d'Information.

1. Qu'est-ce que Zabbix ?

Zabbix est un logiciel de supervision "tout-en-un" créé en 2001. Il est gratuit (Open Source sous licence GPLv2) et conçu pour passer à l'échelle de la petite PME au grand groupe.

  • Périmètre de surveillance : Il surveille absolument tout :

    • Infrastructure : Serveurs (Linux/Windows), Réseau (Switchs/Routeurs via SNMP).
    • Cloud & Virtualisation : VMs, Conteneurs (Docker/K8s), Services Cloud.
    • Applications : Bases de données, serveurs Web (Apache/Nginx), applications Java.

  • Philosophie : Centraliser toutes les métriques en un point unique pour alerter en cas de problème.

2. Architecture & Composants

Zabbix repose sur une architecture modulaire composée de 4 briques essentielles :

  • Zabbix Server (Le Cerveau) :

    • C'est le processus central (backend en C).
    • Rôle : Il ordonne la collecte des données, traite les informations reçues, calcule les déclencheurs (triggers) et envoie les alertes (mails, SMS).

  • Base de Données (La Mémoire) :

    • Rôle : Tout est stocké ici : la configuration de Zabbix ET l'historique des données collectées.
    • Technologies : Compatible avec MySQL, MariaDB, PostgreSQL (et Oracle pour les versions pro).

  • Zabbix Frontend (Le Visage) :

    • Rôle : L'interface Web (en PHP) qui permet à l'administrateur de configurer la supervision et de visualiser les graphiques/tableaux de bord.

  • Zabbix Agent (Les Bras) :

    • Rôle : Petit logiciel installé directement sur les serveurs à surveiller (Linux ou Windows).
    • Il récupère les infos locales (CPU, RAM, Disque) et les renvoie au serveur.
    • Note : Pour le matériel réseau où on ne peut pas installer d'agent, Zabbix utilise le protocole SNMP.

3. Fonctionnement : Le Flux de Données

Comment une donnée arrive-t-elle sur votre écran ?

  1. Collecte : L'Agent (ou le Serveur via SNMP) mesure une valeur (ex: CPU à 90%).
  2. Stockage : La valeur est envoyée au Serveur Zabbix qui l'écrit en Base de Données.
  3. Analyse : Le Serveur compare cette valeur à un seuil défini (Trigger).
    • Exemple : "Si CPU > 80% alors ALERTE".
  4. Visualisation : L'administrateur voit l'alerte clignoter sur l'Interface Web.

4. Concepts Clés (Vocabulaire Zabbix)

Pour maîtriser Zabbix, il faut parler son langage :

  • Host (Hôte) : Tout équipement surveillé (Serveur, Switch).
  • Item (Élément) : Une métrique précise que l'on surveille (ex: "Charge CPU", "Espace Disque C:").
  • Trigger (Déclencheur) : La règle qui définit un problème (ex: "Espace libre < 10%").
  • Action : Ce que fait Zabbix en cas de problème (Envoyer un email, redémarrer un service).

En résumé 💡

  • Zabbix = Solution complète (OS + Réseau + App).
  • Agent = Installé sur les serveurs pour des infos précises.
  • Serveur + BDD + Frontend = Le trio central pour gérer la supervision.
  • SNMP = Utilisé par Zabbix pour surveiller ce qui ne supporte pas d'agent (Routeurs/Switchs).

Challenge B302 : Installation d'Agents Zabbix pour étendre la supervision à l’ensemble de l’infrastructure.

📚 Ressources :

Retour en haut

🕵️ B303. Les Agents Zabbix

Comprendre le fonctionnement de la brique "collecte" de Zabbix. L'agent est le composant essentiel pour une surveillance fine et granulaire des systèmes (OS, Hardware) et des applications.

1. Qu'est-ce qu'un Agent Zabbix ?

L'Agent Zabbix est un démon (service) léger installé directement sur l'hôte à surveiller (Serveur Linux, Windows, BSD...).

  • Rôle : Il accède aux ressources locales (CPU, RAM, journaux, disques) pour collecter des métriques précises que le serveur Zabbix ne pourrait pas voir depuis l'extérieur.
  • Compatibilité : Multiplateforme (Linux, Windows, macOS, BSD, AIX, Solaris...).

2. Les Deux Versions d'Agents

Zabbix propose deux déclinaisons de son agent. Elles peuvent cohabiter, mais on en choisit généralement une selon le besoin :

  • Zabbix Agent (Classic) :

    • L'agent historique, écrit en C.
    • Très léger, stable et éprouvé.
    • Fonctionne sur toutes les architectures (même très anciennes).

  • Zabbix Agent 2 :

    • La version moderne, écrite en Go.
    • Modulaire : Il intègre nativement des plugins pour surveiller des applications complexes (Docker, MySQL, PostgreSQL, Redis) sans avoir besoin de scripts externes compliqués.
    • Gère mieux les connexions persistantes et la concurrence.

3. Modes de Communication : Actif vs Passif

C'est la notion technique la plus importante. Comment l'Agent et le Serveur se parlent-ils ? Le choix dépend de votre architecture réseau (Firewall, NAT).

ModeQui initie la connexion ?FonctionnementCas d'usage idéal
Passif (Défaut)Le Serveur (Poller)Le Serveur demande : "Donne-moi ton CPU". L'Agent répond.Réseau local sécurisé, charge faible. Facile à configurer.
ActifL'Agent (Trapper)L'Agent demande sa config au démarrage, puis pousse les données tout seul périodiquement.Machines derrière un NAT/Firewall, ou surveillance de PC portables instables.

Le Port : Par défaut, l'Agent écoute sur le port 10050. (Le Serveur contacte l'Agent sur le 10050 en mode passif).

4. Configuration et Extension

  • Fichier de configuration :

    • Sous Linux : /etc/zabbix/zabbix_agentd.conf
    • Paramètres clés :
      • Server= (IP du serveur Zabbix autorisé à interroger l'agent - Mode Passif).
      • ServerActive= (IP du serveur à qui envoyer les données - Mode Actif).
      • Hostname= (Nom unique de la machine, doit correspondre à l'interface Web).

  • Que surveille-t-on ? :

    • Système : Charge CPU, Mémoire libre, IO Disque, Espace disque, Uptime.
    • Réseau : Bande passante entrante/sortante, erreurs de paquets.
    • Services : État d'un service (Systemd, Service Windows), Processus en cours.

  • Extension (UserParameter) :

    • Si Zabbix ne sait pas récupérer une info nativement, on peut créer un UserParameter.
    • C'est une ligne dans le fichier de config qui associe une clé Zabbix à une commande shell personnalisée.
    • Exemple : Créer une métrique qui compte le nombre de fichiers dans un dossier spécifique.

En résumé 💡

  1. Port : L'agent écoute sur le 10050 (TCP).
  2. Agent 2 = Nouvelle version en Go avec plugins intégrés (Docker/DB).
  3. Mode Passif = Le Serveur interroge (Polling).
  4. Mode Actif = L'Agent envoie (Push) -> Indispensable si l'agent est derrière un pare-feu bloquant l'entrée.
  5. UserParameter = La méthode pour exécuter vos propres scripts via l'agent.

Challenge B303 : Exploration plus en détail des paramètres, alertes de Zabbix avec les Agents, configuration d'une alerte pour fichiers.

📚 Ressources :

Retour en haut

🍟 B304. Nagios

Découvrir Nagios, le standard historique de la supervision Open Source. Bien que son interface soit vieillissante, son moteur et sa logique de "Plugins" sont à la base de la majorité des outils modernes (Centreon, Icinga, Shinken).

1. Qu'est-ce que Nagios ?

Né en 1999 (sous le nom NetSaint), Nagios Core est un moteur de supervision pur et dur. Contrairement à Zabbix qui stocke tout en base de données, Nagios repose historiquement sur des fichiers de configuration texte et une exécution de scripts.

  • Philosophie : "Fais une chose et fais-la bien". Nagios est un ordonnanceur (scheduler). Il ne sait rien faire tout seul, il délègue tout le travail de vérification à des Plugins.
  • Réputation : Extrêmement stable, mais difficile à configurer (pas d'interface de config native dans la version Core) et interface web "rétro".

2. Architecture Modulaire

Nagios fonctionne selon le principe Cœur + Plugins.

  • Le Scheduler (Le Cœur) :

    • C'est le chef d'orchestre. Il lit les fichiers de config et dit : "Il est 14h00, je dois lancer la vérification du disque sur le serveur A".

  • Les Plugins (Les Ouvriers) :

    • C'est la grande force de Nagios. Ce sont de petits programmes (scripts Bash, Perl, Python, C...) exécutables en ligne de commande.
    • Exemple : ./check_ping -H 192.168.1.1
    • Nagios exécute le plugin, récupère le résultat et l'affiche.
    • Avantage : Si vous savez écrire un script, vous savez créer un plugin Nagios.

  • L'Interface Web (CGI) :

    • Permet de voir l'état des services (Vert/Rouge), mais pas de modifier la configuration dans la version gratuite.

3. Les États (Status) & Codes Retour

C'est le standard de l'industrie créé par Nagios. Un plugin doit renvoyer un Code de retour précis pour dire à Nagios comment ça va.

CodeÉtatCouleurSignification
0OK🟢 VertTout va bien (ex: Ping répond, Disque à 40%).
1WARNING🟡 JauneAvertissement, seuil dépassé mais fonctionne encore (ex: Disque à 85%).
2CRITICAL🔴 RougeProblème critique, service HS (ex: Site Web down, Disque à 99%).
3UNKNOWN🟠 OrangeImpossible de vérifier (ex: Timeout, erreur du script).

4. Concepts Clés de Configuration

La configuration de Nagios se fait traditionnellement via des fichiers textes (.cfg). On y définit des Objets :

  • Hosts : Les machines physiques ou virtuelles (Serveurs, Routeurs).

  • Services : Ce qu'on surveille sur un hôte (HTTP, SSH, Espace Disque).

  • Contacts : Qui prévenir en cas de panne (Admins).

  • Timeperiods : Quand surveiller (24x7 ou seulement aux heures de bureau).

    Soft vs Hard States** : Pour éviter les fausses alertes, Nagios distingue deux états :

    • Soft : Le service vient de planter (1ère fois). Nagios attend et re-vérifie (ex: 3 fois).
    • Hard : Le service est toujours planté après 3 essais. Là, l'alerte est envoyée.

5. Agents & Surveillance à Distance

Comme Zabbix, Nagios surveille le réseau via SNMP, mais pour entrer dans les serveurs (Linux/Windows), il utilise des agents spécifiques :

  • NRPE (Nagios Remote Plugin Executor) : L'agent standard pour Linux/Unix. Il permet au serveur Nagios d'exécuter des plugins locaux sur la machine cible.
  • NSClient++ : L'agent standard pour Windows.

En résumé 💡

  1. Architecture : Nagios est un moteur qui lance des scripts (Plugins).
  2. Codes Retour : 0=OK, 1=Warning, 2=Critical, 3=Unknown. (À connaître par cœur !).
  3. Configuration : Basée sur des fichiers textes (complexe), pas de BDD de configuration par défaut.
  4. Héritage : Nagios est le "père" de Centreon (qui est une surcouche graphique française pour Nagios à l'origine) et d'Icinga.

Challenge B304 : Installation de Nagios et de ses agents.

📚 Ressources :

Retour en haut

Précédent

💾 Stockage & sauvegarde

Suivant

📜 Scripting