7 Surveillance Web
Aperçu
Avec Zabbix, vous pouvez vérifier plusieurs aspects de la disponibilité des sites web.
Pour effectuer la surveillance web, le serveur Zabbix doit être initialement configuré avec la prise en charge de cURL (libcurl).
Pour activer la surveillance web, vous devez définir des scénarios web. Un scénario web se compose d'une ou plusieurs requêtes HTTP ou "étapes". Les étapes sont exécutées périodiquement par le serveur Zabbix dans un ordre prédéfini. Si un hôte est surveillé par un proxy, les étapes sont exécutées par le proxy.
Les scénarios web sont associés aux hôtes/modèles de la même manière que les éléments, déclencheurs, etc. Cela signifie que les scénarios web peuvent également être créés au niveau d'un modèle, puis appliqués à plusieurs hôtes en une seule opération.
Les informations suivantes sont collectées dans tout scénario web :
- vitesse moyenne de téléchargement par seconde pour toutes les étapes de l'ensemble du scénario
- numéro de l'étape ayant échoué
- dernier message d'erreur
Les informations suivantes sont collectées dans toute étape d'un scénario web :
- vitesse de téléchargement par seconde
- temps de réponse
- code de réponse
Pour plus de détails, voir éléments de surveillance web.
Les données collectées lors de l'exécution des scénarios web sont conservées dans la base de données. Ces données sont automatiquement utilisées pour les graphiques, les déclencheurs et les notifications.
Zabbix peut également vérifier si une page HTML récupérée contient une chaîne prédéfinie. Il peut exécuter une connexion simulée et suivre un chemin de clics de souris simulés sur la page.
La surveillance web de Zabbix prend en charge HTTP et HTTPS. Lors de l'exécution d'un scénario web, Zabbix suivra éventuellement les redirections (voir l'option Suivre les redirections ci-dessous). Le nombre maximal de redirections est fixé en dur à 10 (à l'aide de l'option cURL CURLOPT_MAXREDIRS). Tous les cookies sont conservés pendant l'exécution d'un scénario unique.
Configuration d'un scénario web
Pour configurer un scénario web :
- Accédez à : Collecte de données → Hôtes (ou Modèles)
- Cliquez sur Web dans la ligne de l'hôte/modèle
- Cliquez sur Créer un scénario web à droite (ou sur le nom du scénario pour modifier un scénario existant)
- Saisissez les paramètres du scénario dans le formulaire
L'onglet Scenario permet de configurer les paramètres généraux d'un scénario web.

Tous les champs obligatoires sont marqués d'un astérisque rouge.
Paramètres du scénario :
| Parameter | Description |
|---|---|
| Name | Nom unique du scénario. Les macros utilisateur sont prises en charge. Note : si des macros utilisateur sont utilisées, ces macros resteront non résolues dans les noms des élément de surveillance web. |
| Update interval | Fréquence d'exécution du scénario. Les suffixes de temps sont pris en charge, par exemple 30s, 1m, 2h, 1d. Les macros utilisateur sont prises en charge. Note : si une macro utilisateur est utilisée et que sa valeur est modifiée (par exemple 5m → 30s), la prochaine vérification sera exécutée selon la valeur précédente (plus tard dans le futur avec les valeurs de l'exemple). Les nouveaux scénarios web seront vérifiés dans les 60 secondes suivant leur création. |
| Attempts | Nombre de tentatives pour l'exécution des étapes du scénario web. En cas de problèmes réseau (expiration du délai, absence de connectivité, etc.), Zabbix peut répéter l'exécution d'une étape plusieurs fois. La valeur définie s'appliquera de manière identique à chaque étape du scénario. Jusqu'à 10 tentatives peuvent être spécifiées, la valeur par défaut est 1. Note : Zabbix ne répétera pas une étape en raison d'un code de réponse incorrect ou d'une chaîne requise non correspondante. |
| Agent | Sélectionnez un agent client. Zabbix se fera passer pour le navigateur sélectionné. Cela est utile lorsqu'un site web renvoie un contenu différent selon le navigateur. Les macros utilisateur peuvent être utilisées dans ce champ. |
| HTTP proxy | Vous pouvez spécifier un proxy HTTP à utiliser, au format [protocol://][username[:password]@]proxy.example.com[:port].Cela définit l'option cURL CURLOPT_PROXY. Le préfixe facultatif protocol:// peut être utilisé pour spécifier d'autres protocoles de proxy (la prise en charge du préfixe de protocole a été ajoutée dans cURL 7.21.7). En l'absence de protocole spécifié, le proxy sera traité comme un proxy HTTP.Par défaut, le port 1080 sera utilisé. Si elle est spécifiée, la valeur du proxy remplacera les variables d'environnement liées au proxy, comme http_proxy, HTTPS_PROXY. Si elle n'est pas spécifiée, le proxy ne remplacera pas les variables d'environnement liées au proxy. La valeur saisie est transmise telle quelle, sans vérification de cohérence. Vous pouvez également saisir une adresse de proxy SOCKS. Si vous spécifiez le mauvais protocole, la connexion échouera et l'élément deviendra non pris en charge. Note : seule l'authentification simple est prise en charge avec le proxy HTTP. Les macros utilisateur peuvent être utilisées dans ce champ. |
| Variables | Variables pouvant être utilisées dans les étapes du scénario (URL, variables de post). Elles ont le format suivant : {macro1}=value1 {macro2}=value2 {macro3}=regex:<regular expression> {macro4}=jsonpath:<jsonpath> {macro5}=xmlxpath:<xmlxpath> {macro6}={{macro}.function()} (voir fonctions de macro) Par exemple : {username}=Alexei {password}=kj3h5kJ34bd {hostid}=regex:hostid is ([0-9]+) {url}=jsonpath:$.host_url {status}=xmlxpath://host/response/status {newvar}={{myvar}.btoa()} Les macros peuvent ensuite être référencées dans les étapes sous la forme {username}, {password}, {hostid}, etc. Zabbix les remplacera automatiquement par les valeurs réelles. Notez que les variables avec regex: nécessitent une étape pour obtenir la valeur de l'expression régulière, de sorte que la valeur extraite ne peut être appliquée qu'à l'étape suivante.Si la partie valeur commence par regex:, la partie qui suit est traitée comme une expression régulière qui recherche dans la page web et, si elle est trouvée, stocke la correspondance dans la variable. Au moins un sous-groupe doit être présent afin que la valeur correspondante puisse être extraite.Les macros utilisateur et les macros} sont prises en charge. Les variables sont automatiquement encodées en URL lorsqu'elles sont utilisées dans les champs de requête ou les données de formulaire pour les variables de post, mais doivent être encodées manuellement lorsqu'elles sont utilisées dans un post brut ou directement dans l'URL. |
| Headers | Les en-têtes HTTP sont utilisés lors de l'exécution d'une requête. Les en-têtes par défaut et personnalisés peuvent être utilisés. Les en-têtes seront attribués à l'aide des paramètres par défaut selon le type d'agent sélectionné dans une liste déroulante au niveau du scénario, et seront appliqués à toutes les étapes, sauf s'ils sont définis de manière personnalisée au niveau d'une étape. Il convient de noter que la définition de l'en-tête au niveau d'une étape supprime automatiquement tous les en-têtes définis précédemment, à l'exception d'un en-tête par défaut attribué en sélectionnant 'User-Agent' dans une liste déroulante au niveau du scénario. Cependant, même l'en-tête par défaut 'User-Agent' peut être remplacé en le spécifiant au niveau d'une étape. Pour supprimer l'en-tête au niveau d'un scénario, l'en-tête doit être nommé et attribué sans valeur au niveau d'une étape. Les en-têtes doivent être listés en utilisant la même syntaxe que celle qu'ils auraient dans le protocole HTTP, avec éventuellement certaines fonctionnalités supplémentaires prises en charge par l'option cURL CURLOPT_HTTPHEADER. Par exemple : Accept-Charset=utf-8 Accept-Language=en-US Content-Type=application/xml; charset=utf-8 Les macros utilisateur et les macros} sont prises en charge. |
| Enabled | Le scénario est actif si cette case est cochée, sinon - désactivé. |
Notez que lors de la modification d'un scénario existant, deux boutons supplémentaires sont disponibles dans le formulaire :
![]() |
Créer un autre scénario basé sur les propriétés de celui existant. |
![]() |
Supprimer les données d'historique et de tendances du scénario. Cela fera exécuter le scénario immédiatement par le serveur après la suppression des données. |
Si le champ HTTP proxy est laissé vide, une autre façon d'utiliser un proxy HTTP consiste à définir les variables d'environnement liées au proxy.
Pour les vérifications HTTP - définissez la variable d'environnement http_proxy pour l'utilisateur du serveur Zabbix. Par exemple,
http_proxy=http://proxy_ip:proxy_port.
Pour les vérifications HTTPS - définissez la variable d'environnement HTTPS_PROXY. Par
exemple, HTTPS_PROXY=http://proxy_ip:proxy_port. Plus de détails
sont disponibles en exécutant une commande shell : # man curl.
L'onglet Steps permet de configurer les étapes du scénario web. Pour ajouter une étape de scénario web, cliquez sur Add dans le bloc Steps.

Les macros utilisateur secrètes ne doivent pas être utilisées dans les URL, car elles seront résolues en "******".
Configuration des étapes

Paramètres de l'étape :
| Paramètre | Description |
|---|---|
| Nom | Nom unique de l'étape. Les macros utilisateur sont prises en charge. Notez que si des macros utilisateur sont utilisées, ces macros resteront non résolues dans les noms des éléments de supervision web. |
| URL | URL à laquelle se connecter et depuis laquelle récupérer des données. Par exemple : https://www.example.com http://www.example.com/download Les noms de domaine peuvent être spécifiés avec des caractères Unicode. Ils sont automatiquement convertis de punycode en ASCII lors de l'exécution de l'étape du scénario web. Le bouton Analyser peut être utilisé pour séparer les champs de requête facultatifs (comme ?name=Admin&password=mypassword) de l'URL, en déplaçant les attributs et les valeurs dans Champs de requête pour un encodage URL automatique. Des variables peuvent être utilisées dans l'URL à l'aide de la syntaxe {macro}. Les variables peuvent être encodées en URL manuellement à l'aide de la syntaxe {{macro}.urlencode()}. Les macros utilisateur et les macros} sont prises en charge. Limité à 2048 caractères. |
| Champs de requête | Variables HTTP GET pour l'URL. Spécifiées sous forme de paires attribut-valeur. Les valeurs sont automatiquement encodées en URL. Les valeurs provenant des variables du scénario, des macros utilisateur ou des macros {HOST.*} sont résolues puis automatiquement encodées en URL. L'utilisation de la syntaxe {{macro}.urlencode()} les encodera deux fois. Les macros utilisateur et les macros} sont prises en charge. |
| Post | Variables HTTP POST. En mode Données de formulaire, elles sont spécifiées sous forme de paires attribut-valeur. Les valeurs sont automatiquement encodées en URL. Les valeurs provenant des variables du scénario, des macros utilisateur ou des macros {HOST.*} sont résolues puis automatiquement encodées en URL. En mode Données brutes, les attributs/valeurs sont affichés sur une seule ligne et concaténés avec le symbole &. Les valeurs brutes peuvent être encodées/décodées en URL manuellement à l'aide de la syntaxe {{macro}.urlencode()} ou {{macro}.urldecode()}. Par exemple : id=2345&userid={user} Si {user} est défini comme variable du scénario web, il sera remplacé par sa valeur lors de l'exécution de l'étape. Si vous souhaitez encoder l'URL de la variable, remplacez {user} par {{user}.urlencode()}. Les macros utilisateur et les macros} sont prises en charge. |
| Variables | Variables au niveau de l'étape pouvant être utilisées pour les fonctions GET et POST. Spécifiées sous forme de paires attribut-valeur. Les variables au niveau de l'étape remplacent les variables au niveau du scénario ou les variables de l'étape précédente. Cependant, la valeur d'une variable au niveau de l'étape n'affecte que l'étape suivante (et non l'étape actuelle). Elles ont le format suivant : {macro}=value {macro}=regex:<regular expression> Pour plus d'informations, voir la description des variables au niveau du scénario. Les variables sont automatiquement encodées en URL lorsqu'elles sont utilisées dans les champs de requête ou les données de formulaire pour les variables post, mais doivent être encodées en URL manuellement lorsqu'elles sont utilisées dans des données post brutes ou directement dans l'URL. |
| En-têtes | En-têtes HTTP personnalisés qui seront envoyés lors de l'exécution d'une requête. Spécifiés sous forme de paires attribut-valeur. Un en-tête défini au niveau d'une étape sera utilisé pour cette étape particulière. Il convient de noter que la définition d'un en-tête au niveau d'une étape supprime automatiquement tous les en-têtes précédemment définis, à l'exception d'un en-tête par défaut attribué en sélectionnant le 'User-Agent' dans une liste déroulante au niveau du scénario. Cependant, même l'en-tête par défaut 'User-Agent' peut être remplacé en le spécifiant au niveau de l'étape. Par exemple, attribuer un nom à un en-tête sans définir de valeur supprimera l'en-tête par défaut au niveau du scénario. Les macros utilisateur et les macros {HOST.*} sont prises en charge. Cela définit l'option cURL CURLOPT_HTTPHEADER. |
| Suivre les redirections | Cochez la case pour suivre les redirections HTTP. Cela définit l'option cURL CURLOPT_FOLLOWLOCATION. |
| Mode de récupération | Sélectionnez le mode de récupération : Corps - récupérer uniquement le corps de la réponse HTTP En-têtes - récupérer uniquement les en-têtes de la réponse HTTP Corps et en-têtes - récupérer le corps et les en-têtes de la réponse HTTP |
| Délai d'expiration | Zabbix ne passera pas plus que le temps défini à traiter l'URL (d'une seconde jusqu'à un maximum d'1 heure). En réalité, ce paramètre définit le temps maximal pour établir une connexion à l'URL et le temps maximal pour exécuter une requête HTTP. Par conséquent, Zabbix ne passera pas plus de 2 x Timeout secondes sur l'étape. Les suffixes de temps sont pris en charge, par ex. 30s, 1m, 1h. Les macros utilisateur sont prises en charge. |
| Chaîne requise | Modèle d'expression régulière requis. À moins que le contenu récupéré (HTML) ne corresponde au modèle requis, l'étape échouera. Si ce champ est vide, aucune vérification de la chaîne requise n'est effectuée. Par exemple : Homepage of Zabbix Welcome.*admin Remarque : la référence aux expressions régulières créées dans l'interface Zabbix n'est pas prise en charge dans ce champ. Les macros utilisateur et les macros} sont prises en charge. |
| Codes d'état requis | Liste des codes d'état HTTP attendus. Si Zabbix obtient un code qui ne figure pas dans la liste, l'étape échouera. Si ce champ est vide, aucune vérification des codes d'état n'est effectuée. Par exemple : 200,201,210-299 Les macros utilisateur sont prises en charge. |
Toute modification des étapes du scénario web ne sera enregistrée que lorsque l'ensemble du scénario sera enregistré.
Voir aussi un exemple concret de la façon dont les étapes de supervision web peuvent être configurées.
Configuration des tags
L'onglet Tags permet de définir des tags au niveau du scénario.

Les tags permettent de filtrer les scénarios Web et les éléments de surveillance Web.
Configuration de l'authentification
L'onglet Authentication permet de configurer les options d'authentification du scénario. Un point vert à côté du nom de l'onglet indique qu'un type d'authentification HTTP est activé.

Paramètres d'authentification :
| Parameter | Description |
|---|---|
| HTTP authentication | Sélectionnez l'option d'authentification : None - aucune authentification utilisée ; Basic - authentification de base utilisée ; NTLM - authentification NTLM (Windows NT LAN Manager) utilisée ; Kerberos - authentification Kerberos utilisée (voir aussi : Configuration de Kerberos avec Zabbix) ; Digest - authentification Digest utilisée. |
| User | Saisissez le nom d'utilisateur (jusqu'à 255 caractères). Ce champ est disponible si HTTP authentication est défini sur Basic, NTLM, Kerberos ou Digest. Les macros utilisateur sont prises en charge. |
| Password | Saisissez le mot de passe de l'utilisateur (jusqu'à 255 caractères). Ce champ est disponible si HTTP authentication est défini sur Basic, NTLM, Kerberos ou Digest. Les macros utilisateur sont prises en charge. |
| SSL verify peer | Cochez la case pour vérifier le certificat SSL du serveur web. Le certificat du serveur sera automatiquement pris depuis l'emplacement de l'autorité de certification (CA) défini à l'échelle du système. Vous pouvez remplacer l'emplacement des fichiers CA à l'aide du paramètre de configuration du serveur ou du proxy Zabbix SSLCALocation. Cela définit l'option cURL CURLOPT_SSL_VERIFYPEER. |
| SSL verify host | Cochez la case pour vérifier que le champ Common Name ou le champ Subject Alternate Name du certificat du serveur web correspond. Cela définit l'option cURL CURLOPT_SSL_VERIFYHOST. |
| SSL certificate file | Nom du fichier de certificat SSL utilisé pour l'authentification du client. Le fichier de certificat doit être au format PEM1. Si le fichier de certificat contient également la clé privée, laissez le champ SSL key file vide. Si la clé est chiffrée, indiquez le mot de passe dans le champ SSL key password. Le répertoire contenant ce fichier est défini par le paramètre de configuration du serveur ou du proxy Zabbix SSLCertLocation. Les macros HOST.* et les macros utilisateur peuvent être utilisées dans ce champ.Cela définit l'option cURL CURLOPT_SSLCERT. |
| SSL key file | Nom du fichier de clé privée SSL utilisé pour l'authentification du client. Le fichier de clé privée doit être au format PEM1. Le répertoire contenant ce fichier est défini par le paramètre de configuration du serveur ou du proxy Zabbix SSLKeyLocation. Les macros HOST.* et les macros utilisateur peuvent être utilisées dans ce champ.Cela définit l'option cURL CURLOPT_SSLKEY. |
| SSL key password | Mot de passe du fichier de clé privée SSL. Les macros utilisateur peuvent être utilisées dans ce champ. Cela définit l'option cURL CURLOPT_KEYPASSWD. |
[1] Zabbix prend en charge les fichiers de certificat et de clé privée uniquement au format PEM. Si votre certificat et vos données de clé privée sont dans un fichier au format PKCS #12 (généralement avec l'extension *.p12 ou *.pfx), vous pouvez en générer le fichier PEM à l'aide des commandes suivantes :
openssl pkcs12 -in ssl-cert.p12 -clcerts -nokeys -out ssl-cert.pem
openssl pkcs12 -in ssl-cert.p12 -nocerts -nodes -out ssl-cert.key
Le serveur Zabbix prend en compte les modifications des certificats sans redémarrage.
Si vous avez le certificat client et la clé privée dans un seul fichier, indiquez simplement ce fichier dans le champ "SSL certificate file" et laissez le champ "SSL key file" vide. Le certificat et la clé doivent néanmoins être au format PEM. La combinaison du certificat et de la clé est simple :
cat client.crt client.key > client.pem
Affichage
Pour afficher les scénarios web configurés pour un hôte, allez dans Monitoring → Hosts, repérez l'hôte dans la liste et cliquez sur le lien hypertexte Web dans la dernière colonne. Cliquez sur le nom du scénario pour obtenir des informations détaillées.

Un aperçu des scénarios web peut également être affiché dans Dashboards à l'aide du widget de surveillance web.
Les résultats récents de l'exécution du scénario web sont disponibles dans la section Monitoring → Latest data.
Surveillance étendue
Il est parfois nécessaire d'enregistrer le contenu HTML de la page reçue.
Cela est particulièrement utile si une étape de scénario web échoue.
Le niveau de débogage 5 (trace) sert à cet effet.
Ce niveau peut être défini dans les fichiers de configuration serveur et proxy ou à l'aide d'une option de contrôle à l'exécution (-R log_level_increase="http poller,N", où N est le numéro du processus).
Les exemples suivants montrent comment la surveillance étendue peut être démarrée, à condition que le niveau de débogage 4 soit déjà défini :
# Augmenter le niveau de journalisation de tous les http pollers :
zabbix_server -R log_level_increase="http poller"
# Augmenter le niveau de journalisation du deuxième http poller :
zabbix_server -R log_level_increase="http poller,2"
Si la surveillance web étendue n'est pas requise, elle peut être arrêtée à l'aide de l'option
-R log_level_decrease.

