📡 Zabbix – Supervision, Alerting & Métriques (NMS)

Qu'est-ce que Zabbix ?

Zabbix est une solution de supervision (NMS - Network Management System) "All-in-One", mature et open-source.

Contrairement à des outils plus anciens (comme Nagios), Zabbix est une solution intégrée qui gère l'ensemble du cycle de supervision :

1. Collecte : (Agent, SNMP, JMX, Ping...)
2. Stockage : (Base de données SQL - MySQL, Postgres)
3. Analyse & Seuil : (Moteur de Triggers)
4. Alerting : (Actions, Médias)
5. Visualisation : (Interface Web PHP, Dashboards, Graphes)

Le Flux Zabbix

1. [Template] (Définit les checks)
      │
      ▼
2. [Item] (Collecte 1 métrique, ex: "CPU Load")
      │
      ▼
3. [Trigger] (Analyse la métrique, ex: "SI CPU > 90%")
      │
      ▼ (État = PROBLÈME)
4. [Action] (Définit la réaction)
      │
      ▼
5. [Média] (Envoie l'alerte, ex: "Email", "Slack")

Une installation Zabbix (non-proxy) comporte 3 composants principaux :

                                    +-----------------+
                                    | [INTERFACE WEB] | (PHP, Nginx/Apache)
                                    +-----------------+
                                        │ (Navigateur)
                                        ▼
                                    [ ADMIN ]
                                        │ (Configure)
                                        ▼
+-------------------------------------------------------------------------+
| [ SERVEUR ZABBIX ] (Daemon: zabbix_server)                              |
|                                                                         |
|  (Logiciel "Core" : Pollers, Trappers, Alerting, Logique...)            |
|                                                                         |
|  (Lit/Écrit la Config & l'Historique)                                     |
|     │                                                                   |
|     ▼                                                                   |
| [ BASE DE DONNÉES ] (MySQL, Postgres)                                     |
+-------------------------------------------------------------------------+
    │               ▲                  ▲                  ▲
    │ (Polling)     │ (Trap)           │ (Agent Actif)    │ (Agent Passif)
    │ (SNMP)        │ (SNMP)           │ (Push)           │ (Pull)
    ▼               │                  │                  │
[ Switch ]    [ Imprimante ]     [ Serveur Web ]      [ Serveur DB ]
                                (Agent Zabbix)     (Agent Zabbix)

• Zabbix Server (zabbix_server) : Le "cerveau". Daemon (C) qui effectue le polling (SNMP, Passif), reçoit les données (Actif, Traps) et évalue les Triggers.
• Database (BDD) : (MySQL/Postgres) Crucial. Stocke toute la configuration (Hôtes, Items, Triggers) ET toutes les données collectées (Historique, Trends).
• Web UI (Frontend) : L'interface (PHP) pour configurer, voir les dashboards et les problèmes.
• Zabbix Agent (zabbix_agentd) : (Optionnel) Le service installé sur les hôtes à superviser (Linux, Windows).
• Zabbix Proxy (zabbix_proxy) : (Optionnel) Collecteur déporté pour les sites distants/scalabilité (voir 6.1).

Zabbix et Nagios (ou son fork Icinga) sont les deux NMS open-source historiques.

En résumé : Nagios est un ordonnanceur de scripts (checks) simple et léger. Zabbix est une plateforme de métriques (Time-Series) intégrée.

Hôte (Host)

Un Hôte est l'objet (l'entité) que vous souhaitez superviser. C'est l'élément de base de Zabbix.

Un Hôte est défini par :

• Nom : (ex: SRV-WEB-01)
• Interface : Comment le joindre ? (ex: Agent 192.168.1.10:10050, ou SNMP 192.168.1.20:161).
• Templates (Modèles) : (Lien) Ce qu'il faut superviser sur cet hôte.
• Host Groups (Groupes) : (Lien) Où il est rangé.

Groupe d'Hôtes (Host Group)

Un Groupe est un simple "dossier" logique pour organiser les hôtes.

Usage (Organisation) :

• Par Type (ex: "Linux Servers", "Windows Servers", "Cisco Switches").
• Par Lieu (ex: "Datacenter Paris", "Site Lyon").
• Par Équipe (ex: "Equipe Infra", "Equipe Dev").

Usage (Permissions) : Les groupes sont essentiels pour gérer les permissions (ex: "Le 'Rôle Utilisateur Dev' ne peut voir que les 'Host Group Dev'").

L'Item (Métrique) est la donnée brute que Zabbix collecte. C'est la brique fondamentale de la supervision.

Paramètres Clés d'un Item

Un "Item" de type "Zabbix Agent" peut être configuré en mode Passif (défaut) ou Actif. C'est une distinction cruciale pour l'architecture.

L'Item collecte la donnée. Le Trigger analyse cette donnée et définit un seuil (Threshold) qui génère un état (OK ou PROBLÈME).

Syntaxe (Expression)

La syntaxe d'un trigger est : {Hôte:Clé.fonction(paramètre)} Opérateur Valeur

Exemples de Triggers

-- 1. Problème simple (Charge CPU)
-- (La dernière valeur de 'system.cpu.load' est > 5)
{srv-web-01:system.cpu.load.last()} > 5

-- 2. Problème (Moyenne sur 5 min)
-- (La moyenne sur 5 minutes est > 10)
{srv-web-01:system.cpu.load.avg(5m)} > 10

-- 3. Problème (Texte)
-- (La dernière valeur de 'web.test.fail' est 1 (Échec))
{srv-web-01:web.test.fail.last()} = 1

-- 4. Problème (Absence de données)
-- (Pas de nouvelle donnée (ping) reçue depuis 3 minutes)
{srv-ping:icmpping.nodata(3m)} = 1

Hystérésis (Expression de Rétablissement)

Pour éviter les alertes "flapping" (ON/OFF/ON/OFF), on peut définir un seuil de retour à la normale (OK) différent :

• Expression Problème : CPU > 90%
• Expression OK (Hystérésis) : CPU < 70%
• (L'alerte ne disparaîtra que lorsque le CPU redescendra sous 70%).

L'Action est la réaction (le "Alors...") à un Événement.

Logique (Conditions -> Opérations)

Une Action est déclenchée par un événement (ex: Trigger) et vérifie des Conditions (Si) avant d'exécuter des Opérations (Alors).

Conditions (SI) :
 (ET) Événement = "Trigger"
 (ET) Trigger Sévérité = "High" OU "Disaster"
 (ET) Hôte Groupe = "Serveurs Production"
 (ET) Statut Maintenance = "Non"

Opérations (ALORS) :
 1. (Immédiat) Envoyer message à "Admin" via Média "Email"
 2. (Immédiat) Envoyer message à "Admin" via Média "Slack"
 3. (Après 1h) Envoyer message à "Manager" (Escalade)
 4. (Immédiat) Exécuter script "Redémarrer_Service.sh"

Média Types

Le "Média" est le canal de notification (configuré par utilisateur) :

• Email (SMTP)
• SMS (Gateway)
• Script (Script personnalisé)
• Webhook (Ex: Slack, Teams, PagerDuty, JIRA)

C'est le concept le plus important pour la scalabilité et la maintenance de Zabbix. Un Template est un "gabarit" (une "classe" en POO) que l'on applique à un Hôte.

Il est interdit (en bonne pratique) de mettre des Items ou des Triggers directement sur un Hôte. On les met toujours dans un Template, puis on "linke" (lie) le Template à l'Hôte.

Contenu d'un Template

Un Template est un ensemble réutilisable de :

• Items (ex: 10 métriques CPU/RAM)
• Triggers (ex: 5 alertes CPU/RAM)
• Graphs (ex: 1 graphique CPU/RAM)
• Low-Level Discovery (LLD) Rules (ex: 1 règle de découverte des disques)

Exemple (Héritage multiple)

Hôte : "SRV-WEB-01"
  │
  ├─ Template: "Template OS Linux" (CPU, RAM, Disques)
  ├─ Template: "Template App Nginx" (Connexions, 5xx)
  └─ Template: "Template App PHP-FPM" (Processus, Lenteur)

Avantage : Si vous voulez modifier le seuil CPU (Trigger) pour vos 500 serveurs Linux, vous modifiez le Trigger une seule fois (dans le "Template OS Linux"), et Zabbix applique le changement aux 500 hôtes.

Problème : Comment superviser les ressources qui sont dynamiques ou multiples sur un hôte ? (ex: les 20 interfaces réseau d'un switch, les 5 disques (C:, D:, E:...) d'un Windows, les 100 Pods d'un K8s).

On ne va pas créer 20 Items "Trafic Entrant" à la main (Interface 1, Interface 2...).

Solution : LLD (Découverte de bas niveau)

LLD est une règle (dans un Template) qui découvre automatiquement ces ressources et génère les Items/Triggers pour vous (via des "Prototypes").

Processus (Ex: Découverte de Disques)

1. Zabbix exécute la "Discovery Rule" (ex: vfs.fs.discovery) sur l'Agent.
2. L'Agent répond avec un JSON :

   [
     { "{#FSNAME}": "/",      "{#FSTYPE}": "ext4" },
     { "{#FSNAME}": "/boot",  "{#FSTYPE}": "ext4" },
     { "{#FSNAME}": "/data",  "{#FSTYPE}": "xfs"  }
   ]

3. Zabbix lit ce JSON et applique les Prototypes (voir 4.3) pour chaque entrée.
4. Résultat : Zabbix crée automatiquement 3 Items (Usage Disque pour /, /boot, /data).

Les Prototypes (Item, Trigger, Graph) sont les "gabarits" utilisés par la règle LLD (4.2). Ils utilisent les Macros LLD (ex: {#FSNAME}) découvertes.

Exemple (LLD de Disques)

Dans votre Template, vous ne créez pas d'Item. Vous créez (sous la Règle LLD) :

1. Item Prototype (Gabarit d'Item)

• Nom : Espace Disque : {#FSNAME}
• Clé : vfs.fs.size[{#FSNAME},pused] (Utilisation en %)

2. Trigger Prototype (Gabarit de Trigger)

• Nom : Disque {#FSNAME} presque plein
• Expression : {Template:vfs.fs.size[{#FSNAME},pused].last()} > 90

Résultat : Si LLD trouve 3 disques (/, /boot, /data), Zabbix crée automatiquement 3 Items et 3 Triggers (un pour chaque disque).

Le Zabbix Agent (zabbix_agentd ou zabbix_agent2) est le service installé sur l'hôte (Linux/Windows) à superviser. Il est très léger et efficace.

zabbix_agentd.conf (Configuration)

Fichier de configuration principal de l'agent (ex: /etc/zabbix/zabbix_agentd.conf).

# IP/DNS du Serveur (ou Proxy) autorisé à poller (Passif)
Server=192.168.1.100

# IP/DNS du Serveur (ou Proxy) à qui envoyer (Actif)
ServerActive=192.168.1.100

# Nom d'hôte (DOIT correspondre au "Host name" dans l'UI Zabbix)
Hostname=SRV-WEB-01

UserParameter (Checks Personnalisés)

Si une métrique n'existe pas (ex: "Nombre de fichiers .tmp"), vous pouvez l'ajouter via UserParameter.

# Ajouté à zabbix_agentd.conf

# Syntaxe: UserParameter=,
UserParameter=tmp.files.count,find /tmp -name "*.tmp" | wc -l

# Côté Zabbix (Serveur), on crée un Item avec la Clé :
# Key: tmp.files.count

Zabbix est un NMS (Manager) SNMP très puissant. Il permet de superviser des appareils "agentless" (sur lesquels on ne peut pas installer d'agent), comme les Switchs, Routeurs, Imprimantes, NAS...

Configuration (Hôte)

Dans l'UI Zabbix, au lieu d'une interface "Agent", on crée une interface "SNMP" :

• IP : (ex: 192.168.1.1 - Le Switch)
• Version : (ex: SNMPv2)
• Community String : (ex: public) (ou paramètres v3)

Configuration (Template)

On "linke" un Template SNMP (ex: Template Net Cisco IOS SNMP). Ce template contient :

• Items : (Type: SNMPv2 Agent) (Clé: L'OID numérique, ex: .1.3.6.1.2.1.1.3.0 pour Uptime).
• LLD : Une règle LLD qui utilise snmpwalk sur ifDescr (...2.2.1.2) pour découvrir les interfaces, et crée des Items (Prototypes) pour ifInOctets (...2.2.1.10.{#SNMPINDEX}).

Zabbix peut utiliser de nombreux types d'Items :

Le Zabbix Proxy (zabbix_proxy) est un daemon "collecteur" léger qui s'exécute sur un site distant. C'est la solution de Scalabilité de Zabbix.

Problème (Sans Proxy)

Un Zabbix Server à Paris doit superviser 100 serveurs à New York (WAN lent, Firewalls).

• Passif/SNMP : Le serveur de Paris doit faire 1000s de requêtes (Poll) à travers le WAN (lent, fragile).
• Actif : 100 serveurs de NY doivent ouvrir une connexion (Push) vers Paris (cauchemard pour le Firewall).

Solution (Avec Proxy)

On installe 1 Zabbix Proxy à New York.

[ Serveurs NY ] <--(Agent/SNMP)--> [ Proxy NY ] <--(1 seule Connexion)--> [ Zabbix Server (Paris) ]

• Rôle du Proxy :
  1. Il contacte le Serveur (Paris) et télécharge sa "configuration" (la liste des hôtes de NY qu'il doit superviser).
  2. Il fait la collecte locale (Polling SNMP, Polling Agent Passif).
  3. Il reçoit les données des Agents Actifs (de NY).
  4. Il stocke (Buffer) les données (ex: dans une DB SQLite).
  5. Toutes les 1 minute (configurable), il envoie (Push) un "paquet" de données agrégées au Serveur (Paris).
• Avantages : Allège le Serveur (la collecte est déportée), résiste aux coupures WAN (Buffer), 1 seule règle de firewall.

Zabbix intègre un module de Monitoring Web (Synthetics) pour simuler des parcours utilisateurs (exécuté par le Serveur ou un Proxy).

Scénario Web

On définit un "Scénario" (ex: "Tunnel de connexion") composé de plusieurs "Étapes".

Exemple (Scénario : "Login")

• Étape 1 : GET /login
  • Check : Doit répondre 200 OK.
  • Check : Doit contenir le texte "Connexion".
• Étape 2 : POST /login
  • Variables POST : user=test, pass=123
  • Check : Doit répondre 302 Found (Redirection).
• Étape 3 : GET /dashboard (Suit la redirection)
  • Check : Doit répondre 200 OK.
  • Check : Doit contenir le texte "Bienvenue test".

Zabbix crée des Items (ex: Vitesse de l'Étape 1, Code Réponse Étape 2) et un Trigger (ex: "Scénario 'Login' a échoué à l'Étape 3").

Zabbix intègre un système de Dashboards (Tableaux de bord) (via son interface Web PHP) pour visualiser les données collectées.

Widgets Courants

• Graph (Graphique) : Graphique Time-Series (basé sur 1 ou N Items).
• Graph (Simple) : (Widget moderne, plus flexible).
• Problems : La liste des problèmes actuellement ouverts (le widget N1/SOC).
• Data Overview : Une "grille" montrant la dernière valeur (ex: CPU) de N hôtes.
• Map (Carte) : Une carte topologique (statique ou dynamique) montrant les liens (ex: entre routeurs).
• Clock (Horloge) : Affiche l'heure.

Intégration Grafana

Bien que Zabbix ait ses propres dashboards, beaucoup d'équipes préfèrent utiliser Grafana (l'outil de visualisation de référence) pour créer des dashboards plus avancés et esthétiques.

Cela se fait via le "Zabbix Plugin for Grafana", qui permet à Grafana d'interroger l'API Zabbix (et non la BDD SQL) pour récupérer les données.

Problème : Vous devez redémarrer un serveur de production (ex: pour une mise à jour) le Dimanche à 3h du matin. Vous ne voulez pas que Zabbix envoie 50 alertes (CPU Down, Ping Down, Service Down...) et réveille l'équipe d'astreinte.

Solution : Périodes de Maintenance

Zabbix permet de définir des périodes de maintenance (planifiées ou "à la volée") pour un Hôte ou un Groupe d'Hôtes.

Types de Maintenance

• Avec collecte de données : (Défaut) L'hôte est mis en "Mode Maintenance". Zabbix continue de collecter les métriques (CPU, RAM...), mais il supprime (suppress) les Actions (les alertes ne sont pas envoyées).
• Sans collecte de données : Zabbix arrête *complètement* de superviser l'hôte pendant la fenêtre (non recommandé).

Permet de garder l'historique des données pendant la maintenance, sans générer de "bruit" (alertes inutiles).

Outils CLI (côté Serveur/Proxy ou Client) pour le diagnostic.

# Syntaxe: zabbix_get -s [IP_Agent] -k [Clé]

# Teste la clé "agent.ping" (le "Hello World")
$ zabbix_get -s 192.168.1.10 -k agent.ping
1

# Teste la charge CPU
$ zabbix_get -s 192.168.1.10 -k system.cpu.load[all,avg1]
0.75

# Échec (ex: Firewall, Agent down, Clé inconnue)
$ zabbix_get -s 192.168.1.10 -k agent.ping
zabbix_get [12345]: Get value error: ZBX_TCP_READ() failed: [104] Connection reset by peer

# Syntaxe: zabbix_sender -z [IP_Serveur] -p 10051 -s [Nom_Hôte] -k [Clé] -o [Valeur]

# Envoyer la valeur "0" (Succès) à l'Item "backup.status"
# sur l'Hôte "SRV-FILE-01"
$ zabbix_sender -z 192.168.1.1 -s "SRV-FILE-01" -k backup.status -o 0

Zabbix (traditionnel) et Prometheus (Cloud Native) sont deux philosophies différentes.