Avec Áú»¢¶Ä²©, vous pouvez v¨¦rifier plusieurs aspects de la disponibilit¨¦ des sites Web.
Pour effectuer une supervision Web, le serveur Áú»¢¶Ä²© doit ¨ºtre initialement ³¦´Ç²Ô´Ú¾±²µ³Ü°ù¨¦ avec le support cURL (libcurl).
Pour activer la supervision Web, vous devez d¨¦finir des sc¨¦narios Web. Un sc¨¦nario Web consiste en une ou plusieurs requ¨ºtes HTTP ou "¨¦tapes". Les ¨¦tapes sont ex¨¦cut¨¦es p¨¦riodiquement par le serveur Áú»¢¶Ä²© dans un ordre pr¨¦d¨¦fini. Si un h?te est supervis¨¦ par proxy, les ¨¦tapes sont ex¨¦cut¨¦es par le proxy.
Depuis Áú»¢¶Ä²© 2.2, les sc¨¦narios Web sont associ¨¦s aux h?tes/mod¨¨les de la m¨ºme mani¨¨re que les ¨¦l¨¦ments, les d¨¦clencheurs, etc. Cela signifie que les sc¨¦narios Web peuvent ¨¦galement ¨ºtre cr¨¦¨¦s au niveau du mod¨¨le, puis appliqu¨¦s ¨¤ plusieurs h?tes en m¨ºme temps.
Les informations suivantes sont collect¨¦es dans n'importe quel sc¨¦nario Web :
Les informations suivantes sont collect¨¦es dans chaque ¨¦tape de sc¨¦nario Web :
Pour plus de d¨¦tails, voir les ¨¦l¨¦ments de supervision web.
Les donn¨¦es collect¨¦es lors de l'ex¨¦cution de sc¨¦narios Web sont conserv¨¦es dans la base de donn¨¦es. Les donn¨¦es sont automatiquement utilis¨¦es pour les graphiques, les d¨¦clencheurs et les notifications.
Áú»¢¶Ä²© 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 simul¨¦s sur la page.
La supervision Web Áú»¢¶Ä²© prend en charge ¨¤ la fois HTTP et HTTPS. Lors de l'ex¨¦cution d'un sc¨¦nario Web, Áú»¢¶Ä²© suit ¨¦ventuellement les redirections (voir l'option Suivre les redirections en dessous). Le nombre maximal de redirections est cod¨¦ en dur ¨¤ 10 (en utilisant l'option cURL ). Tous les cookies sont conserv¨¦s lors de l'ex¨¦cution d'un sc¨¦nario unique.
Voir aussi les probl¨¨mes connus pour la supervision Web ¨¤ l'aide du protocole HTTPS.
Pour configurer un scenario web :
L'onglet ³§³¦¨¦²Ô²¹°ù¾±´Ç vous permet de configurer les param¨¨tres g¨¦n¨¦raux d'un sc¨¦nario Web.
Tous les champs de saisie obligatoires sont marqu¨¦s d'un ast¨¦risque rouge.
±Ê²¹°ù²¹³¾¨¨³Ù°ù±ðs de sc¨¦nario :
±Ê²¹°ù²¹³¾¨¨³Ù°ù±ð | Description | |||
---|---|---|---|---|
H?te | Nom de l'h?te/mod¨¨le auquel le sc¨¦nario appartient. | |||
Nom | Nom unique du sc¨¦nario. Les macros utilisateurs et les macros {HOST.*} sont support¨¦es depuis Áú»¢¶Ä²© 2.2. |
|||
Application | S¨¦lectionnez une application ¨¤ laquelle le sc¨¦nario appartiendra. Les ¨¦l¨¦ments du sc¨¦nario Web seront regroup¨¦s sous l'application s¨¦lectionn¨¦e dans // Surveillance ¡ú Derni¨¨res donn¨¦es . | |Nouvelle application// |
Entrez le nom de la nouvelle application pour le sc¨¦nario. | ||
Intervalle de mise ¨¤ jour | A quelle fr¨¦quence le sc¨¦nario sera ex¨¦cut¨¦. Les suffixes de temps sont support¨¦s, ex : 30s, 1m, 2h, 1d, depuis Áú»¢¶Ä²© 3.4.0. Les macros utilisateurs sont support¨¦es depuis Áú»¢¶Ä²© 3.4.0. Notez que si une macro utilisateur est utilis¨¦e et que sa valeur change (e.g. 5m ¡ú 30s), la prochaine v¨¦rification sera ex¨¦cut¨¦e selon la valeur pr¨¦c¨¦dente (plus tard dans le futur avec les valeurs d'exemple). |
|||
Tentatives | Nombre de tentatives d'ex¨¦cution des ¨¦tapes du sc¨¦nario Web. En cas de probl¨¨mes r¨¦seau (timeout, absence de connectivit¨¦, etc.), Áú»¢¶Ä²© peut r¨¦p¨¦ter plusieurs fois l'ex¨¦cution d'une ¨¦tape. Le chiffre positionn¨¦ affectera ¨¦galement chaque ¨¦tape du sc¨¦nario. Vous pouvez sp¨¦cifier jusqu'¨¤ 10 tentatives, la valeur par d¨¦faut est 1. // Note //: Áú»¢¶Ä²© ne r¨¦p¨¨tera pas une ¨¦tape en raison d'un code de r¨¦ponse erron¨¦ ou d'une non-concordance d'une cha?ne requise. Ce param¨¨tre est pris en charge ¨¤ partir de Áú»¢¶Ä²© 2.2. |
|||
Agent | S¨¦lectionnez un agent client. Áú»¢¶Ä²© fera semblant d'¨ºtre le navigateur s¨¦lectionn¨¦. Ceci est utile lorsqu'un site Web renvoie un contenu diff¨¦rent pour diff¨¦rents navigateurs. Les macros utilisateur peuvent ¨ºtre utilis¨¦es dans ce champ, // ¨¤ partir de Áú»¢¶Ä²© 2.2 . | |Proxy HTTP// |
Vous pouvez sp¨¦cifier un proxy HTTP ¨¤ utiliser, en utilisant le format suivant : http://[username[:password]@]proxy.mycompany.com[:port] Par d¨¦faut, le port 1080 sera utilis¨¦. Si sp¨¦cifi¨¦, le proxy remplacera les variables d'environnement li¨¦es au proxy, telles que http_proxy, HTTPS_PROXY. S'il n'est pas sp¨¦cifi¨¦, le proxy n'¨¦crasera pas les variables d'environnement li¨¦es au proxy. La valeur saisie est transmise "telle quelle", aucune v¨¦rification de la validit¨¦ n'est effectu¨¦e. Vous pouvez ¨¦galement entrer une adresse proxy SOCKS. Si vous sp¨¦cifiez le mauvais protocole, la connexion ¨¦chouera et l'¨¦l¨¦ment ne sera plus pris en charge. En l'absence de protocole sp¨¦cifi¨¦, le proxy sera trait¨¦ comme un proxy HTTP. //Remarque //: Seule une authentification simple est prise en charge avec le proxy HTTP. Les macros utilisateur peuvent ¨ºtre utilis¨¦es dans ce champ. Ce param¨¨tre est pris en charge ¨¤ partir de // Áú»¢¶Ä²© 2.2 . | |Variables// |
Variables pouvant ¨ºtre utilis¨¦es dans les ¨¦tapes du sc¨¦nario (URL, variables post). Elles ont le format suivant : {macro1}=value1 {macro2}=value2 {macro3}=regex:<regular expression> Par exemple : {username}=Alexei {password}=kj3h5kJ34bd {hostid}=regex:hostid is ([0-9]+) Les macros peuvent ensuite ¨ºtre r¨¦f¨¦renc¨¦es dans les ¨¦tapes sous la forme {username}, {password} et {hostid}. Áú»¢¶Ä²© les remplacera automatiquement par des valeurs r¨¦elles. Notez que les variables avec regex: ont besoin d'une ¨¦tape pour obtenir la valeur de l'expression r¨¦guli¨¨re afin que la valeur extraite ne puisse ¨ºtre appliqu¨¦e qu'¨¤ l'¨¦tape suivante.Si la partie valeur commence par "regex:", la partie apr¨¨s celle-ci est trait¨¦e comme une expression r¨¦guli¨¨re qui recherche la page Web et, si elle est trouv¨¦e, stocke la correspondance dans la variable. Au moins un sous-groupe doit ¨ºtre pr¨¦sent pour que la valeur correspondante puisse ¨ºtre extraite. La correspondance des expressions r¨¦guli¨¨res dans les variables est prise en charge // depuis Áú»¢¶Ä²© 2.2 . Les macros utilisateur et les macros {HOST.*} sont pris en charge, depuis Áú»¢¶Ä²© 2.2. Les variables sont automatiquement encod¨¦es en URL lorsqu'elles sont utilis¨¦es dans des champs de requ¨ºte ou des donn¨¦es de formulaire pour des variables post, mais doivent ¨ºtre encod¨¦es manuellement lorsqu'elles sont utilis¨¦es en post brut ou directement dans l'URL. | |Headers// |
Les en-t¨ºtes HTTP personnalis¨¦s qui seront envoy¨¦s lors de l'ex¨¦cution d'une requ¨ºte. Les en-t¨ºtes doivent ¨ºtre r¨¦pertori¨¦s en utilisant la m¨ºme syntaxe qu'ils appara?ssent dans le protocole HTTP, en utilisant ¨¦ventuellement certaines fonctionnalit¨¦s suppl¨¦mentaires prises en charge par l'option cURL . Par exemple : Accept-Charset=utf-8 Accept-Language=en-US Content-Type=application/xml; charset=utf-8 Les macros utilisateur et les macros {HOST.*} sont support¨¦es. La sp¨¦cification des en-t¨ºtes personnalis¨¦es est support¨¦e ¨¤ partir de Áú»¢¶Ä²© 2.4. |
Activer | Le sc¨¦nario est activ¨¦ sur cette case est coch¨¦e, sinon - d¨¦sactiv¨¦. |
Notez que lors de l'¨¦dition d'un sc¨¦nario existant, deux boutons suppl¨¦mentaires sont disponibles dans le formulaire :
![]() |
Cr¨¦ez un autre sc¨¦nario bas¨¦ sur les propri¨¦t¨¦s d'un sc¨¦nario existant. |
![]() |
Supprimer l'historique et les donn¨¦es de tendance du sc¨¦nario. Cela obligera le serveur ¨¤ ex¨¦cuter le sc¨¦nario imm¨¦diatement apr¨¨s la suppression des donn¨¦es. |
Si le champs proxy HTTP est laiss¨¦ vide, un autre moyen d'utiliser un proxy HTTP est de positionner les variables d'environnement li¨¦s au proxy.
Pour les v¨¦rifications HTTP - positionnez la variable d'environnement http_proxypour l'utilisateur du serveur Áú»¢¶Ä²© server user. Par exemple : //http_proxy=.
Pour les v¨¦rifications HTTPS - positionnez la variable d'environnement HTTPS_PROXY. Par exemple, //HTTPS_PROXY=. Plus de d¨¦tails sont disponibles en ex¨¦cutant la commande : # man curl.
L'onglet Etapes vous permet de configurer les ¨¦tapes du sc¨¦nario web. Pour ajouter une ¨¦tape d'un sc¨¦nario web, cliquez sur Ajouter dans le bloc Etapes.
Step parameters:
Parameter | Description |
---|---|
Name | Unique step name. User macros and {HOST.*} macros are supported, since Áú»¢¶Ä²© 2.2. |
URL | URL to connect to and retrieve data. For example: https://www.google.com http://www.zabbix.com/download Domain names can be specified in Unicode characters since Áú»¢¶Ä²© 3.4. They are automatically punycode-converted to ASCII when executing the web scenario step. The Parse button can be used to separate optional query fields (like ?name=Admin&password=mypassword) from the URL, moving the attributes and values into Query fields for automatic URL-encoding. Variables can be used in the URL, using the {macro} syntax. Variables can be URL-encoded manually using a {{macro}.urlencode()} syntax. User macros and {HOST.*} macros are supported, since Áú»¢¶Ä²© 2.2. Limited to 2048 characters starting with Áú»¢¶Ä²© 2.4. |
Query fields | HTTP GET variables for the URL. Specified as attribute and value pairs. Values are URL-encoded automatically. Values from scenario variables, user macros or {HOST.*} macros are resolved and then URL-encoded automatically. Using a {{macro}.urlencode()} syntax will double URL-encode them. User macros and {HOST.*} macros are supported since Áú»¢¶Ä²© 2.2. |
Post | HTTP POST variables. In Form data mode, specified as attribute and value pairs. Values are URL-encoded automatically. Values from scenario variables, user macros or {HOST.*} macros are resolved and then URL-encoded automatically. In Raw data mode, attributes/values are displayed on a single line and concatenated with a & symbol. Raw values can be URL-encoded/decoded manually using a {{macro}.urlencode()} or {{macro}.urldecode()} syntax. For example: id=2345&userid={user} If {user} is defined as a variable of the web scenario, it will be replaced by its value when the step is executed. If you wish to URL-encode the variable, substitute {user} with {{user}.urlencode()}. User macros and {HOST.*} macros are supported, since Áú»¢¶Ä²© 2.2. |
Variables | Step-level variables that may be used for GET and POST functions. Specified as attribute and value pairs. Step-level variables override scenario-level variables or variables from the previous step. However, the value of a step-level variable only affects the step after (and not the current step). They have the following format: {macro}=value {macro}=regex:<regular expression> For more information see variable description on the scenario level. Having step-level variables is supported since Áú»¢¶Ä²© 2.2. Variables are automatically URL-encoded when used in query fields or form data for post variables, but must be URL-encoded manually when used in raw post or directly in URL. |
Headers | Custom HTTP headers that will be sent when performing a request. Specified as attribute and value pairs. Headers on the step level will overwrite the headers specified for the scenario. For example, setting a 'User-Agent' attribute with no value will remove the User-Agent value set on scenario level. User macros and {HOST.*} macros are supported. This sets the cURL option. Specifying custom headers is supported starting with Áú»¢¶Ä²© 2.4. |
Follow redirects | Mark the checkbox to follow HTTP redirects. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
Retrieve only headers | Mark the checkbox to retrieve only headers from the HTTP response. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
Timeout | Áú»¢¶Ä²© will not spend more than the set amount of time on processing the URL (maximum is 1 hour). Actually this parameter defines the maximum time for making connection to the URL and maximum time for performing an HTTP request. Therefore, Áú»¢¶Ä²© will not spend more than 2 x Timeout seconds on the step. Time suffixes are supported, e.g. 30s, 1m, 1h. User macros are supported. |
Required string | Required regular expressions pattern. Unless retrieved content (HTML) matches required pattern the step will fail. If empty, no check is performed. For example: Homepage of Áú»¢¶Ä²© Welcome.*admin Note: Referencing regular expressions created in the Áú»¢¶Ä²© frontend is not supported in this field. User macros and {HOST.*} macros are supported, since Áú»¢¶Ä²© 2.2. |
Required status codes | List of expected HTTP status codes. If Áú»¢¶Ä²© gets a code which is not in the list, the step will fail. If empty, no check is performed. For example: 200,201,210-299 User macros are supported since Áú»¢¶Ä²© 2.2. |
Any changes in web scenario steps will only be saved when the whole scenario is saved.
See also a real-life example of how web monitoring steps can be configured.
The Authentication tab allows you to configure scenario authentication options.
Authentication parameters:
Parameter | Description |
---|---|
Authentication | Authentication options. None - no authentication used. Basic authentication - basic authentication is used. NTLM authentication - NTLM ( authentication is used. Selecting an authentication method will provide two additional fields for entering a user name and password. User macros can be used in user and password fields, starting with Áú»¢¶Ä²© 2.2. |
SSL verify peer | Mark the checkbox to verify the SSL certificate of the web server. The server certificate will be automatically taken from system-wide certificate authority (CA) location. You can override the location of CA files using Áú»¢¶Ä²© server or proxy configuration parameter SSLCALocation. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
SSL verify host | Mark the checkbox to verify that the Common Name field or the Subject Alternate Name field of the web server certificate matches. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
SSL certificate file | Name of the SSL certificate file used for client authentication. The certificate file must be in PEM1 format. If the certificate file contains also the private key, leave the SSL key file field empty. If the key is encrypted, specify the password in SSL key password field. The directory containing this file is specified by Áú»¢¶Ä²© server or proxy configuration parameter SSLCertLocation.HOST.* macros and user macros can be used in this field.This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
SSL key file | Name of the SSL private key file used for client authentication. The private key file must be in PEM1 format. The directory containing this file is specified by Áú»¢¶Ä²© server or proxy configuration parameter SSLKeyLocation.HOST.* macros and user macros can be used in this field.This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
SSL key password | SSL private key file password. User macros can be used in this field. This sets the cURL option. This option is supported starting with Áú»¢¶Ä²© 2.4. |
[1] Áú»¢¶Ä²© supports certificate and private key files in PEM format only. In case you have your certificate and private key data in PKCS #12 format file (usually with extention *.p12 or *.pfx) you may generate the PEM file from it using the following commands:
Áú»¢¶Ä²© server picks up changes in certificates without a restart.
If you have client certificate and private key in a single file just specify it in a "SSL certificate file" field and leave "SSL key file" field empty. The certificate and key must still be in PEM format. Combining certificate and key is easy:
To view detailed data of defined web scenarios, go to Monitoring ¡ú Web or Latest data. Click on the scenario name to see more detailed statistics.
An overview of web monitoring scenarios can be viewed in Monitoring ¡ú Dashboard.
Sometimes it is necessary to log received HTML page content. This is especially useful if some web scenario step fails. Debug level 5 (trace) serves that purpose. This level can be set in server and proxy configuration files or using a runtime control option (-R log_level_increase="http poller,N"
, where N is the process number). The following examples demonstrate how extended monitoring can be started provided debug level 4 is already set:
Increase log level of all http pollers:
shell> zabbix_server -R log_level_increase="http poller"
Increase log level of second http poller:
shell> zabbix_server -R log_level_increase="http poller,2"
If extended web monitoring is not required it can be stopped using the -R log_level_decrease
option.