Superviser un service HTTPS avec Zabbix 7.4 : disponibilité, temps de réponse et alertes

Introduction

Surveiller qu’un service HTTPS n’accepte pas seulement une connexion TCP sur le port 443 mérite toute l’attention d’un administrateur homelab. Un simple contrôle de port (avec icmpping ou un check natif du type tcpconn) ne vérifie que la présence du processus écoutant. Il ne garantit ni le code HTTP retourné, ni la validité du certificat TLS, ni le temps de réponse réel perçu par un client. C’est précisément ce qu’apportent les scénarios web (web scenarios) dans Zabbix : une série pas-à-pas de requêtes HTTP(S) simulées, exécutées par le serveur Zabbix lui-même via cURL, avec retour sur le code de réponse, la durée et le contenu.

Cet article montre comment configurer un scénario web basique, extraire les métriques clés, créer des déclencheurs d’alerte pertinents, et diagnostiquer les erreurs courantes — le tout dans Zabbix 7.4.

Prérequis

• Zabbix 7.4 (server ou proxy) installé et opérationnel.
• Le serveur Zabbix doit être compilé avec le support cURL (libcurl). C’est le cas par défaut sur les paquets officiels [1].
• Un accès à l’interface web de Zabbix (Web UI), avec des droits suffisants pour créer des scénarios web (Configuration → Hosts, onglet Web).
• Un hôte ou service cible déjà enregistré dans Zabbix, sur lequel le serveur a une connectivité réseau.

Note : la surveillance directe du certificat SSL/TLS (expiration, chaîne de certificats) utilise une clé distincte — web.certificate.get via l’agent 2 [6]. Elle ne fait pas partie des scénarios web mais complète idéalement cette approche.

Configurer un scénario web dans Zabbix 7.4

Créer le scénario

Depuis la configuration de l’hôte cible :

1. Cliquez sur Web dans la ligne de l’hôte.
2. Puis Create web scenario.
3. Renseignez :
4. Name : un nom explicite, par exemple HTTPS Homepage check.
5. Update interval : fréquence d’exécution — 1m pour une minute, 5m, etc.
6. Agent (User-Agent) : le type d’agent simulé (Zabbix, Mozilla, Custom).
7. Authentication : aucune, Basic, ou Negotiate/NTLM.
8. Sauvegardez.

Ajouter les étapes du scénario

Chaque étape correspond à une requête HTTP(S) exécute dans l’ordre. Cliquez sur Add dans le bloc Steps.

Étape 1 — Page d’accueil :

Paramètre	Valeur
Name	Homepage
No	1 (numéro séquentiel)
URL	https://exemple.local/health
Follow redirects	1 par défaut (suit jusqu’à 10 redirections max, fixé par CURLOPT_MAXREDIRS) [2]
Timeout	30s — durée maximale pour établir la connexion + effectuer la requête
HTTP method	GET
Headers	Exemple : Accept: application/json (une ligne de header par entrée)
Required status codes	200,201 — codes acceptés ; le scénario échoue autrement [2]
Required string	"ok" — texte obligatoire dans le corps de la réponse

Étape 2 — Endpoint secondaire (optionnel) :

Paramètre	Valeur
Name	API health
No	2
URL	https://exemple.local/api/health
HTTP method	GET
Timeout	15s
Required status codes	200

L’ordre des étapes est déterminé par le champ No. Le numéro 1 s’exécute avant le numéro 2.

Paramètres au niveau du scénario (rappel)

Les champs globaux du scénario — Agent, Authentication (nom d’utilisateur/mot de passe), HTTP proxy, verify_peer / verify_host pour TLS — s’appliquent à toutes les étapes, sauf si une étape redéfinit un header. La documentation rappelle que définir un header au niveau de l’étape remplace tous les headers préalablement définis au niveau du scénario [2].

Métriques extraites par Zabbix

Dès la création d’un scénario web, Zabbix crée automatiquement des items liés :

Items au niveau du scénario :

Nom (description)	Clé de l’item	Type
Download speed for scenario	web.test.in[Scenario,,bps]	Numeric(float)
Failed step of scenario	web.test.fail[Scenario]	Numeric(unsigned)
Error for scenario	web.test.error[Scenario]	Character

Items au niveau de chaque étape (Step) :

Nom (description)	Clé de l’item	Type
Download speed for step	web.test.in[Scenario,Step,bps]	Numeric(float)
Response time for step	web.test.time[Scenario,Step,resp]	Numeric(float)
Response code for step	web.test.rspcode[Scenario,Step]	Numeric(unsigned)
Failed step of scenario	web.test.fail[Scenario,Step]	Numeric(unsigned) [1]

Le scénario web est visible via Monitoring → Web [3].

Ces item clés sont documentées dans la section officielle « 1 Web monitoring items » de Zabbix 7.4 [1].

Exemples de triggers (déclencheurs)

1. Scénario web échoué

Le scénario a échoué sur au moins une étape :

last(/hote/cible,web.test.fail[HTTPS Homepage check])<>0

Pour un descriptif dans le nom du trigger, on peut inclure le texte d’erreur :

Web scenario "HTTPS Homepage check": {ITEM.VALUE}

2. Échecs répétés (dern())

Si le scénario doit échouer 3 fois de suite pour déclencher l’alerte :

last(/hote/cible,web.test.fail[HTTPS Homepage check])<>0 and last(/hote/cible,web.test.fail[HTTPS Homepage check],#2)=last(/hote/cible,web.test.fail[HTTPS Homepage check]) and last(/hote/cible,web.test.fail[HTTPS Homepage check],#3)=last(/hote/cible,web.test.fail[HTTPS Homepage check])

Une formulation plus concise utilise count() :

count(/hote/cible,web.test.fail[HTTPS Homepage check],5m,0)=5

Cela détecte 5 échecs consécutifs dans les 5 dernières minutes. La fonction last() prend en charge la notation ,#N pour le n-ème valeur précédente [4].

3. Temps de réponse anormalement élevé

On vérifie ici le temps de réponse de l’étape « Homepage » du scénario :

last(/hote/cible,web.test.time[HTTPS Homepage check,Homepage,resp])>3

Si la moyenne glissante dépasse 3 secondes sur les 2 dernières remontées :

max(/hote/cible,web.test.time[HTTPS Homepage check,Homepage,resp],2m)>3

4. Code HTTP inattendu sur une étape

Superviser qu’une étape retourne systématiquement le code 200 :

last(/hote/cible,web.test.rspcode[HTTPS Homepage check,Homepage])<>200

Remarque importante : les expressions de trigger citées ici utilisent la syntaxe de Zabbix 7.4 (nouvelle syntaxe depuis 5.4) avec la fonction last() en forme standard /host/key[params] [4]. La syntaxe ancienne au format {HOST.KEY}.func() est encore acceptée mais considérée comme obsolète dans les récentes versions de Zabbix.

Vérification des alertes et notification

Pour s’assurer que le mécanisme d’alerte fonctionne à l’aide d’un scénario web :

1. Fausser manuellement un résultat en modifiant temporairement la valeur attendue dans zéro (par exemple changer Required status codes de 200 à 200,500 pour désactiver ou mettre un code erroné comme 404 seul).
2. Patienter le temps que l’intervalle d’exécution effectue au moins deux cycles (ex. 2 × 1 min = 2 min si l’intervalle est de 1 minute) [5].
3. Consulter Monitoring → Problems : si un événement Problem apparaît, la notification est opérationnelle. Le problème doit inclure le trigger associé et le statut PROBLEM.
4. Restaurer la configuration correcte du scénario immédiatement après le test.

Cette méthode est une procédure de validation manuelle non documentée dans l’interface ; aucun bouton officiel n’existe pour « simuler » un scénario web. La seule manière fiable reste d’attendre qu’une condition de trigger soit réellement atteinte par les données collectées [5].

Limites et erreurs courantes

Erreurs SSL/TLS invalides

Zabbix 7.4 gère la vérification du certificat via verify_peer et verify_host au niveau du scénario [2] : si leur valeur impose une validation stricte mais que le certificat de l’hôte cible est auto-signé, le scénario échouera systématiquement avec un code d’erreur SSL. Dans ce cas, soit placer ces deux paramètres à 0, ou ajouter l’autorité racine au dépôt de confiance (SSLCertLocation dans la configuration du serveur Zabbix [2]).

Timeouts trop courts par défaut

Chaque étape dispose d’un Timeout (par défaut 15 s). Si le service est lent, un timeout de 15 s peut être insuffisant. La valeur maximale est de 1 heure (1h), exprimée avec suffixe : 30s, 1m, 1h [2]. Attention : Zabbix consomme jusqu’à 2 × Timeout secondes par étape au maximum (temps de connexion + temps de requête).

Résolution DNS masquée

Si un nom de domaine utilisé dans une URL ne peut pas être résolu, le scénario échouera avec une erreur Couldn't resolve host name, sans distinguer si c’est le timeout ou le DNS qui a causé l’échec. Pour diagnostiquer, consulter l’item web.test.error[Scenario] pour obtenir le message d’erreur exact [1]. Il n’existe pas de résulateur DNS explicite — ce comportement est celui de cURL sous-jacent ; la documentation officielle ne mentionne aucune étape DNS séparée dans un scénario web [2]. Pour contourner : utiliser une adresse IP brute (IPv4/IPv6) dans l’URL, ou vérifier que le serveur Zabbix resolve correctement le nom (dig ou nslookup en ligne de commande).

Proxy non configuré pour les check HTTPS

Pour les vérifications HTTPS via proxy, la variable d’environnement HTTPS_PROXY (en majuscule selon la convention curl) doit être définie pour l’utilisateur du serveur Zabbix [2]. De même, HTTP_PROXY pour les requêtes HTTP. Ces variables ne sont pas dans un champ de la configuration Zabbix classique : elles relèvent de l’environnement système du processus zabbix_server ou zabbix_proxy.

---

Sources et vérifications

• Clés d’items web monitoring (web.test.fail[], web.test.time[], web.test.rspcode[]) — Documentation Zabbix 7.4 « 1 Web monitoring items » — https://www.zabbix.com/documentation/current/en/manual/web_monitoring/items — relevé le 2026-11-06
• Propriétés du web scenario step URL (timeout, follow_redirects, status_codes) — Documentation Zabbix 7.4 API reference « Web scenario object » — https://www.zabbix.com/documentation/7.4/en/manual/api/reference/httptest/object — relevé le 2026-11-06
• Page d’exemple réel (real life scenario) web monitoring — Documentation Zabbix 7.4 « 2 Real-life scenario » — https://www.zabbix.com/documentation/current/en/manual/web_monitoring/example — relevé le 2026-11-06
• Syntaxe des expressions de trigger (fonction last(), notation ,#N) — Documentation Zabbix 7.4 « Trigger expression and functions » — https://www.zabbix.com/documentation/7.4/en/manual/config/triggers/expression — relevé le 2026-11-06
• Accès Web scenario via Monitoring → Web, création du scénario — Documentation Zabbix 7.4 « 9 Web monitoring » — https://www.zabbix.com/documentation/current/en/manual/web_monitoring — relevé le 2026-11-06
• Surveillance de certificat SSL/TLS via web.certificate.get (clé agent 2) — Documentation Zabbix 7.4 « Website certificate by Zabbix agent 2 » — https://www.zabbix.com/integrations/ssl — relevé le 2026-11-06