L'intégration nginx collecte les métriques de connexion et les journaux d'accès. Les métriques de connexion capturent l'état actuel de la connexion : active, en lecture ou en attente. Les journaux d'accès sont analysés pour connaître leurs détails de connexion, qui incluent les champs mappés à la requête, au client, au serveur et au message.
Pour en savoir plus sur nginx, consultez la documentation nginx.
Prérequis
Pour collecter les données de télémétrie nginx, vous devez installer l'agent Ops :
- Pour les métriques, installez la version 2.1.0 ou ultérieure.
- Pour les journaux, installez la version 2.1.0 ou ultérieure.
Cette intégration est compatible avec les versions 1.18 et 1.20 de nginx.
Configurer votre instance nginx
Vous devez activer le module stub_status
dans le fichier de configuration nginx pour configurer une URL accessible localement (par exemple, http://www.example.com/nginx_status
pour la page d'état). Procédez comme suit pour activer le module stub_status
:
Modifiez le fichier
status.conf
ou créez-le s'il n'existe pas. Vous trouverez ce fichier dans le répertoire de configuration nginx, généralement situé dans/etc/nginx/conf.d
.Ajoutez les lignes suivantes à la section
server
:location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; }
Votre fichier de configuration pourrait ressembler à l'exemple suivant :
server { listen 80; server_name 127.0.0.1; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } location / { root /dev/null; } }
Actualisez la configuration nginx.
sudo service nginx reload
La commande suivante vous permet d'automatiser les étapes précédentes. Elle crée un fichier status.conf
s'il n'existe pas ou, s'il existe, écrase le fichier existant. La commande active stub_status
, actualise nginx et vérifie que les informations attendues sont exposées via le point de terminaison.
sudo tee /etc/nginx/conf.d/status.conf > /dev/null << EOF
server {
listen 80;
server_name 127.0.0.1;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
location / {
root /dev/null;
}
}
EOF
sudo service nginx reload
curl http://127.0.0.1:80/nginx_status
Voci un exemple de sortie :
Active connections: 1 server accepts handled requests 23 23 74 Reading: 0 Writing: 1 Waiting: 0
Au lieu d'utiliser un fichier status.conf
distinct, vous pouvez également intégrer directement les lignes au fichier nginx.conf
principal, qui se trouve généralement dans l'un des répertoires suivants : /etc/nginx
, /usr/local/nginx/conf
ou /usr/local/etc/nginx
.
Configurer l'agent Ops pour nginx
Suivez le guide Configurer l'agent un agent, ajoutez les éléments requis ; pour collecter la télémétrie des instances nginx redémarrez l'agent.
Exemple de configuration
Les commandes suivantes créent la configuration de collecte et d'ingestion de la télémétrie pour nginx et redémarrent l'agent Ops.
Configurer la collecte de journaux
Pour ingérer des métriques à partir de nginx, vous devez créer un récepteur pour les métriques produites par nginx, puis créer un pipeline pour le nouveau récepteur.
Pour configurer un récepteur pour vos journaux nginx_access
, spécifiez les champs suivants :
Champ | Par défaut | Description |
---|---|---|
exclude_paths |
Liste des formats de chemin d'accès au système de fichiers à exclure de l'ensemble correspondant à include_paths . |
|
include_paths |
[/var/log/nginx/access.log] |
Liste des chemins d'accès du système de fichiers à lire en affichant chaque fichier. Un caractère générique (* ) peut être utilisé dans les chemins d'accès. |
record_log_file_path |
false |
Si cette valeur est définie sur true , le chemin d'accès au fichier spécifique à partir duquel l'enregistrement de journal a été obtenu apparaît dans l'entrée de journal de sortie en tant que valeur du libellé agent.googleapis.com/log_file_path . Lorsque vous utilisez un caractère générique, seul le chemin du fichier à partir duquel l'enregistrement a été obtenu est enregistré. |
type |
Cette valeur doit être nginx_access . |
|
wildcard_refresh_interval |
60s |
Intervalle d'actualisation pour les chemins d'accès de fichiers utilisant des caractères génériques dans include_paths . Renseigné sous la forme d'une durée, par exemple, 30s ou 2m . Cette propriété peut s'avérer utile lorsque le débit de journalisation est élevé et que les fichiers journaux sont alternés plus rapidement que l'intervalle par défaut. |
Pour configurer un récepteur pour vos journaux nginx_error
, spécifiez les champs suivants :
Champ | Par défaut | Description |
---|---|---|
exclude_paths |
Liste des formats de chemin d'accès au système de fichiers à exclure de l'ensemble correspondant à include_paths . |
|
include_paths |
[/var/log/nginx/error.log] |
Liste des chemins d'accès du système de fichiers à lire en affichant chaque fichier. Un caractère générique (* ) peut être utilisé dans les chemins d'accès. |
record_log_file_path |
false |
Si cette valeur est définie sur true , le chemin d'accès au fichier spécifique à partir duquel l'enregistrement de journal a été obtenu apparaît dans l'entrée de journal de sortie en tant que valeur du libellé agent.googleapis.com/log_file_path . Lorsque vous utilisez un caractère générique, seul le chemin du fichier à partir duquel l'enregistrement a été obtenu est enregistré. |
type |
Cette valeur doit être nginx_error . |
|
wildcard_refresh_interval |
60s |
Intervalle d'actualisation pour les chemins d'accès de fichiers utilisant des caractères génériques dans include_paths . Renseigné sous la forme d'une durée, par exemple, 30s ou 2m . Cette propriété peut s'avérer utile lorsque le débit de journalisation est élevé et que les fichiers journaux sont alternés plus rapidement que l'intervalle par défaut. |
Contenu consigné
Le champ logName
est dérivé des ID de récepteur spécifiés dans la configuration. Les champs détaillés dans l'entrée de journal (LogEntry
) sont les suivants.
Les journaux nginx_access
contiennent les champs suivants dans LogEntry
:
Champ | Type | Description |
---|---|---|
httpRequest |
objet | Consultez HttpRequest |
jsonPayload.host |
chaîne | Contenu de l'en-tête Hôte (généralement non signalé par nginx) |
jsonPayload.level |
chaîne | Niveau de l'entrée de journal |
jsonPayload.user |
chaîne | Nom d'utilisateur authentifié pour la requête |
severity |
chaîne (LogSeverity ) |
Niveau d'entrée de journal (traduit). |
Les journaux nginx_error
contiennent les champs suivants dans LogEntry
:
Champ | Type | Description |
---|---|---|
jsonPayload.client |
chaîne | Adresse IP du client (facultatif) |
jsonPayload.connection |
nombre | ID de connexion |
jsonPayload.host |
chaîne | En-tête de l'hôte (facultatif) |
jsonPayload.level |
chaîne | Niveau de l'entrée de journal |
jsonPayload.message |
chaîne | Message du journal |
jsonPayload.pid |
nombre | ID du processus émettant le journal. |
jsonPayload.referer |
chaîne | En-tête Referer (optional) |
jsonPayload.request |
chaîne | Requête HTTP d'origine (facultatif) |
jsonPayload.server |
chaîne | Nom du serveur nginx (facultatif) |
jsonPayload.subrequest |
chaîne | Sous-requête nginx (facultatif) |
jsonPayload.tid |
nombre | ID du thread d'où provient le journal |
jsonPayload.upstream |
chaîne | URI de la demande en amont (facultatif) |
severity |
chaîne (LogSeverity ) |
Niveau d'entrée de journal (traduit). |
Configurer la collecte de métriques
Pour ingérer des métriques à partir de nginx, vous devez créer un récepteur pour les métriques produites par nginx, puis créer un pipeline pour le nouveau récepteur.
Ce récepteur ne permet pas d'utiliser plusieurs instances dans la configuration, par exemple pour surveiller plusieurs points de terminaison. Toutes ces instances écrivent dans la même série temporelle, et Cloud Monitoring n'a aucun moyen de les distinguer.
Pour configurer un récepteur pour vos métriques nginx
, spécifiez les champs suivants :
Champ | Par défaut | Description |
---|---|---|
collection_interval |
60s |
Une valeur time duration, telle que 30s ou 5m . |
server_status_url |
http://localhost/status |
URL exposée par le module d'état de bouchon nginx. |
type |
Cette valeur doit être nginx . |
Métriques surveillées
Le tableau suivant fournit la liste des métriques que l'agent Ops collecte à partir de l'instance nginx.
Type de métrique | |
---|---|
Genre, type Ressources surveillées |
Étiquettes |
workload.googleapis.com/nginx.connections_accepted
|
|
CUMULATIVE , INT64 gce_instance |
|
workload.googleapis.com/nginx.connections_current
|
|
GAUGE , INT64 gce_instance |
state
|
workload.googleapis.com/nginx.connections_handled
|
|
CUMULATIVE , INT64 gce_instance |
|
workload.googleapis.com/nginx.requests
|
|
CUMULATIVE , INT64 gce_instance |
Vérifier la configuration
Cette section explique comment vérifier que vous avez bien configuré le récepteur nginx. La collecte de la télémétrie par l'agent Ops peut prendre une ou deux minutes.
Pour vérifier que les journaux nginx sont envoyés à Cloud Logging, procédez comme suit:
-
Dans la console Google Cloud, accédez à la page Explorateur de journaux.
Accéder à l'explorateur de journaux
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.
- Saisissez la requête suivante dans l'éditeur, puis cliquez sur Exécuter la requête :
resource.type="gce_instance" (log_id("nginx_access") OR log_id("nginx_error"))
Pour vérifier que les métriques nginx sont envoyées à Cloud Monitoring, procédez comme suit:
-
Dans la console Google Cloud, accédez à la page leaderboardExplorateur de métriques :
Accéder à l'explorateur de métriques
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.
- Dans la barre d'outils du volet de création de requêtes, sélectionnez le bouton nommé code MQL ou code PromQL.
- Vérifiez que MQL est sélectionné dans le bouton d'activation Langage. Le bouton de langage se trouve dans la barre d'outils qui vous permet de mettre en forme votre requête.
- Saisissez la requête suivante dans l'éditeur, puis cliquez sur Exécuter la requête :
fetch gce_instance | metric 'workload.googleapis.com/nginx.requests' | every 1m
Afficher le tableau de bord
Pour afficher vos métriques nginx, vous devez configurer un graphique ou un tableau de bord. L'intégration nginx inclut un ou plusieurs tableaux de bord. Tous les tableaux de bord sont automatiquement installés après la configuration de l'intégration et que l'agent Ops a commencé à collecter des données de métriques.
Vous pouvez également afficher des aperçus statiques de tableaux de bord sans installer l'intégration.
Pour afficher un tableau de bord installé, procédez comme suit :
-
Dans la console Google Cloud, accédez à la page Tableaux de bord .
Accéder à la page Tableaux de bord
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.
- Sélectionnez l'onglet Liste des tableaux de bord, puis choisissez la catégorie Intégrations.
- Cliquez sur le nom du tableau de bord que vous souhaitez afficher.
Si vous avez configuré une intégration, mais que le tableau de bord n'a pas été installé, vérifiez que l'agent Ops est en cours d'exécution. Lorsqu'un graphique ne contient aucune donnée de métrique, l'installation du tableau de bord échoue. Une fois que l'agent Ops a commencé à collecter des métriques, le tableau de bord est installé.
Pour afficher un aperçu statique du tableau de bord, procédez comme suit :
-
Dans la console Google Cloud, accédez à la page Intégrations :
Accéder à la page Intégrations
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.
- Cliquez sur le filtre de plate-forme de déploiement Compute Engine.
- Recherchez l'entrée pour nginx, puis cliquez sur Afficher les détails.
- Cliquez sur l'onglet Tableaux de bord pour afficher un aperçu statique. Si le tableau de bord est installé, vous pouvez y accéder en cliquant sur Afficher le tableau de bord.
Pour en savoir plus sur les tableaux de bord dans Cloud Monitoring, consultez la page Tableaux de bord et graphiques.
Pour en savoir plus sur l'utilisation de la page Intégrations, consultez la page Gérer les intégrations.
Installer des règles d'alerte
Les règles d'alerte indiquent à Cloud Monitoring de vous avertir lorsque des conditions spécifiées se produisent. L'intégration nginx inclut une ou plusieurs règles d'alerte à utiliser. Vous pouvez afficher et installer ces règles d'alerte à partir de la page Intégrations dans Monitoring.
Pour afficher la description des règles d'alerte disponibles et les installer, procédez comme suit :
-
Dans la console Google Cloud, accédez à la page Intégrations :
Accéder à la page Intégrations
Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.
- Recherchez l'entrée pour nginx, puis cliquez sur Afficher les détails.
- Sélectionnez l'onglet Alertes. Cet onglet fournit une description des règles d'alerte disponibles et fournit une interface pour les installer.
- Installez les règles d'alerte. Les règles d'alerte doivent savoir où envoyer des notifications indiquant que l'alerte a été déclenchée. Elles nécessitent donc des informations de votre part pour l'installation.
Pour installer des règles d'alerte, procédez comme suit :
- Dans la liste des règles d'alerte disponibles, sélectionnez celles que vous souhaitez installer.
Dans la section Configurer les notifications, sélectionnez un ou plusieurs canaux de notification. Vous avez la possibilité de désactiver l'utilisation des canaux de notification. Toutefois, si vous le faites, vos règles d'alerte se déclenchent en mode silencieux. Vous pouvez vérifier leur état dans Monitoring, mais vous ne recevez aucune notification.
Pour plus d'informations sur les canaux de notification, consultez la section Gérer les canaux de notification.
- Cliquez sur Créer des règles.
Pour plus d'informations sur les règles d'alerte dans Cloud Monitoring, consultez la section Présentation des alertes.
Pour en savoir plus sur l'utilisation de la page Intégrations, consultez la page Gérer les intégrations.
Dépannage
Dans la plupart des distributions, nginx est fourni avec ngx_http_stub_status_module
activé.
Vous pouvez vérifier s'il est activé en exécutant la commande suivante :
sudo nginx -V 2>&1 | grep -o with-http_stub_status_module
Le résultat attendu est with-http_stub_status_module
, ce qui signifie que le module est activé. Dans de rares cas, si la commande ne renvoie aucun résultat, vous devez compiler nginx à partir de la source avec -with-http_stub_status_module
en suivant la documentation publique nginx.
Étape suivante
Pour accéder à un tutoriel pas à pas expliquant comment utiliser Ansible pour installer l'agent Ops, configurer une application tierce et installer un exemple de tableau de bord, consultez la vidéo Install the Ops Agent to troubleshoot third-party applications (Installer l'agent Ops pour résoudre les problèmes liés à des applications tierces).