Journaux et métriques pour les services de backend

Ce document explique comment configurer et utiliser Cloud Logging et Cloud Monitoring avec des équilibreurs de charge d'application classiques, des équilibreurs de charge d'application externes globaux et Cloud CDN.

Journalisation

Vous pouvez activer, désactiver et afficher les journaux d'un service de backend d'équilibreur de charge d'application externe. Pour les équilibreurs de charge d'application externes avec des buckets backend, la journalisation est automatiquement activée et ne peut pas être désactivée.

Vous activez ou désactivez la journalisation pour chaque service de backend. Vous pouvez configurer la journalisation pour toutes les requêtes ou seulement pour une fraction échantillonnée de manière aléatoire.

Vous devez vérifier qu'aucune exclusion de journaux ne s'applique aux équilibreurs de charge d'application externes. Pour savoir comment vérifier si les journaux Cloud HTTP Load Balancer sont autorisés, consultez la section Afficher les exclusions de types de ressources.

Échantillonnage et collecte des journaux

Les requêtes (et les réponses correspondantes) gérées par les instances de machine virtuelle (VM) de backend d'équilibreur de charge sont échantillonnées. Ces requêtes échantillonnées sont ensuite traitées pour générer des journaux. Vous contrôlez la fraction des requêtes émises en tant qu'entrées de journal en fonction du paramètre logConfig.sampleRate. Lorsque logConfig.sampleRate est défini sur 1.0 (100%), cela signifie que les journaux sont générés pour toutes les requêtes et écrits dans Cloud Logging.

Activer la journalisation sur un nouveau service de backend

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de votre équilibreur de charge.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configuration du backend.

  5. Sélectionnez Créer un service backend.

  6. Renseignez les champs obligatoires du service de backend.

  7. Dans la section Journalisation, cochez la case Activer la journalisation.

  8. Définissez un taux d'échantillonnage. Vous pouvez définir un nombre compris entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100% des requêtes sont enregistrées. La valeur par défaut est 1.0.

  9. Pour terminer la modification du service de backend, cliquez sur Mettre à jour.

  10. Pour terminer la modification de l'équilibreur de charge, cliquez sur Mettre à jour.

gcloud : mode global

Créez un service de backend et activez la journalisation à l'aide de la commande gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec les équilibreurs de charge d'application externes globaux.
  • --enable-logging active la journalisation pour ce service de backend.
  • --logging-sample-rate permet de spécifier une valeur entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. Ce paramètre n'est pertinent que lorsqu'il est associé au paramètre --enable-logging. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

gcloud : mode classique

Créez un service de backend et activez la journalisation à l'aide de la commande gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
 --global \
 --enable-logging \
 --logging-sample-rate=VALUE \
 --load-balancing-scheme=EXTERNAL

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec un équilibreur de charge d'application classique.
  • --enable-logging active la journalisation pour ce service de backend.
  • --logging-sample-rate permet de spécifier une valeur entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. Ce paramètre n'est pertinent que lorsqu'il est associé au paramètre --enable-logging. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

Activer la journalisation sur un service de backend existant

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de votre équilibreur de charge.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configuration du backend.

  5. Cliquez sur Modifier () à côté de votre service de backend.

  6. Dans la section Journalisation, cochez la case Activer la journalisation.

  7. Dans le champ Taux d'échantillonnage, définissez la probabilité d'échantillonnage. Vous pouvez définir un nombre compris entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. La valeur par défaut est 1.0.

  8. Pour terminer la modification du service de backend, cliquez sur Mettre à jour.

  9. Pour terminer la modification de l'équilibreur de charge, cliquez sur Mettre à jour.

gcloud : mode global

Activez la journalisation sur un service de backend existant à l'aide de la commande gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec les équilibreurs de charge d'application externes globaux.
  • --enable-logging active la journalisation pour ce service de backend.
  • --logging-sample-rate permet de spécifier une valeur entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. Ce paramètre n'est pertinent que lorsqu'il est associé au paramètre --enable-logging. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

gcloud : mode classique

Activez la journalisation sur un service de backend existant à l'aide de la commande gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec un équilibreur de charge d'application classique.
  • --enable-logging active la journalisation pour ce service de backend.
  • --logging-sample-rate permet de spécifier une valeur entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. Ce paramètre n'est pertinent que lorsqu'il est associé au paramètre --enable-logging. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

Désactiver ou modifier la journalisation sur un service de backend existant

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de votre équilibreur de charge.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configuration du backend.

  5. Cliquez sur Modifier () à côté de votre service de backend.

  6. Pour désactiver complètement la journalisation, décochez la case Activer la journalisation dans la section Journalisation.

  7. Si vous laissez la journalisation activée, vous pouvez définir un autre taux d'échantillonnage. Vous pouvez définir un nombre compris entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100% des requêtes sont enregistrées. La valeur par défaut est 1.0. Par exemple, 0.2 signifie que 20% des requêtes échantillonnées génèrent des journaux.

  8. Pour terminer la modification du service de backend, cliquez sur Mettre à jour.

  9. Pour terminer la modification de l'équilibreur de charge, cliquez sur Mettre à jour.

gcloud : mode global

Désactivez la journalisation sur un service de backend à l'aide de la commande gcloud compute backend-services update.

Désactiver complètement la journalisation

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec les équilibreurs de charge d'application externes globaux.
  • --region indique que le service de backend est régional. Utilisez ce champ pour les services de backend utilisés avec les équilibreurs de charge d'application externes régionaux.
  • --no-enable-logging désactive la journalisation pour ce service de backend.

Modifier le taux d'échantillonnage des journaux

gcloud compute backend-services update BACKEND_SERVICE \
 --global \
 --logging-sample-rate=VALUE

gcloud : mode classique

Désactivez la journalisation sur un service de backend à l'aide de la commande gcloud compute backend-services update.

Désactiver complètement la journalisation

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec un équilibreur de charge d'application classique.
  • --no-enable-logging désactive la journalisation pour ce service de backend.

Modifier le taux d'échantillonnage des journaux

gcloud compute backend-services update BACKEND_SERVICE \
 --global \
 --logging-sample-rate=VALUE

Où :

  • --global indique que le service de backend est global. Utilisez ce champ pour les services de backend utilisés avec un équilibreur de charge d'application classique.
  • --logging-sample-rate permet de spécifier une valeur entre 0.0 et 1.0, où 0.0 signifie qu'aucune requête n'est enregistrée et 1.0 signifie que 100 % des requêtes sont enregistrées. Ce paramètre n'est pertinent que lorsqu'il est associé au paramètre --enable-logging. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation.

Afficher les journaux

Pour obtenir des instructions détaillées sur cette tâche directement dans la console Google Cloud, cliquez sur Visite guidée :

Visite guidée

Les journaux HTTP(S) sont d'abord indexés par une règle de transfert, puis par un mappage d'URL.

Pour afficher les journaux, accédez à la page Explorateur de journaux :

Accéder à l'explorateur de journaux

  • Pour afficher tous les journaux, dans le menu de filtre Ressource, sélectionnez Équilibreur de charge HTTP Cloud > Toutes les règles de transfert.

  • Pour afficher les journaux d'une seule règle de transfert, sélectionnez un nom de règle de transfert.

  • Pour afficher les journaux d'un seul mappage d'URL, sélectionnez une règle de transfert, puis un mappage d'URL.

Les champs de journal de type booléen n'apparaissent généralement que s'ils comportent la valeur true. Si un champ booléen a la valeur false, il est omis du journal.

Le codage UTF-8 est appliqué aux champs de journaux. Les caractères qui ne sont pas au format UTF-8 sont remplacés par des points d'interrogation. Pour les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application externes globaux, vous pouvez exporter des métriques basées sur les journaux à l'aide des journaux de ressources (resource.type="http_load_balancer"). Les métriques créées sont basées sur la ressource "Règle d'équilibreur de charge d'application (métriques basées sur les journaux)" (l7_lb_rule), qui est disponible sous les tableaux de bord Cloud Monitoring, mais pas sous la ressource https_lb_rule.

Contenu consigné

Les entrées des journaux d'équilibreur de charge d'application externe contiennent des informations utiles pour surveiller et déboguer votre trafic HTTP(S). Les enregistrements de journal contiennent des champs obligatoires, qui sont les champs par défaut de chaque enregistrement de journal.

Champ Format du champ Type de champ : obligatoire ou facultatif Description
severity
insertID
logName		 LogEntry Requis Champs généraux décrits dans une entrée de journal.
timestamp string (Timestamp format) Facultatif Heure à laquelle le GFE de la première couche reçoit la requête.
httpRequest HttpRequest Requis Protocole courant pour la journalisation des requêtes HTTP.

HttpRequest.protocol n'est pas renseigné pour resource.type="http_load_balancer"

.
resource MonitoredResource Requis

MonitoredResource est le type de ressource associé à une entrée de journal.

MonitoredResourceDescriptor décrit le schéma d'un objet MonitoredResource à l'aide d'un nom de type et d'un ensemble de libellés. Pour en savoir plus, consultez la section Libellés de ressources.
jsonPayload object (format Struct) Requis Charge utile de l'entrée de journal, exprimée sous la forme d'un objet JSON. L'objet JSON contient les champs suivants :
  • statusDetails
  • backendTargetProjectNumber
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • loadBalancingScheme
chaîne Requis Le champ statusDetails contient une chaîne qui explique la raison pour laquelle l'équilibreur de charge a renvoyé l'état HTTP. Pour en savoir plus sur ces chaînes de journaux, consultez les sections Messages de réussite HTTP statusDetails et Messages d'échec HTTP statusDetails.
string Requis Le champ backendTargetProjectNumber contient le numéro du projet dans lequel la cible backend (service de backend ou bucket backend) a été créée. Ce champ est au format suivant : "projects/PROJECT_NUMBER". Ces informations ne sont disponibles que pour les équilibreurs de charge d'application externes globaux qui utilisent des réponses d'erreur personnalisées.
entier Obligatoire overrideResponseCode contient le code de réponse de remplacement appliqué à la réponse envoyée au client. Ces informations ne sont disponibles que pour les équilibreurs de charge d'application externes globaux qui utilisent des réponses d'erreur personnalisées.
chaîne Obligatoire Le champ errorService contient le service de backend qui a fourni la réponse d'erreur personnalisée. Ces informations ne sont disponibles que pour les équilibreurs de charge d'application externes globaux qui utilisent des réponses d'erreur personnalisées.
chaîne Obligatoire Le champ errorBackendStatusDetails contient l'statusDetails de la réponse finale envoyée au client. Ces informations ne sont disponibles que pour les équilibreurs de charge d'application externes globaux qui utilisent des réponses d'erreur personnalisées.
chaîne Facultatif Le champ loadBalancingScheme n'est renseigné que pour les clients qui utilisent la fonctionnalité de migration de l'équilibreur de charge d'application classique. Ce champ contient une chaîne qui décrit le schéma d'équilibrage de charge utilisé pour acheminer la requête. Les valeurs possibles sont EXTERNAL ou EXTERNAL_MANAGED.

Étiquettes de ressource

Le tableau suivant liste les libellés de ressources pour resource.type="http_load_balancer".

Champ Type Description
backend_service_name string Nom du service de backend.
forwarding_rule_name string Nom de l'objet de règle de transfert.
project_id string Identifiant du projet Google Cloud associé à cette ressource.
target_proxy_name string Nom de l'objet de proxy cible référencé par la règle de transfert.
url_map_name string Nom de l'objet de mappage d'URL configuré pour sélectionner un service de backend.
zone string Zone dans laquelle l'équilibreur de charge est en cours d'exécution. La zone définie est global.

Messages de réussite HTTP statusDetails

statusDetails (réussite) Signification Codes de réponse d'accompagnement courants
byte_range_caching La requête HTTP a été diffusée à l'aide de la mise en cache de la plage d'octets Cloud CDN. Tout code de réponse pouvant être mis en cache est possible.
response_from_cache La requête HTTP a été diffusée à partir du cache Cloud CDN. Tout code de réponse pouvant être mis en cache est possible.
response_from_cache_validated Le code de retour a été défini à partir d'une entrée en cache Cloud CDN validée par un backend. Tout code de réponse pouvant être mis en cache est possible.
response_sent_by_backend La requête HTTP a bien été envoyée par proxy au backend et la réponse a été renvoyée par le backend. Le code de réponse HTTP est défini par le logiciel exécuté sur le backend.

Messages d'échec HTTP statusDetails

statusDetails (échec) Signification Codes de réponse d'accompagnement courants
aborted_request_due_to_backend_early_response Une requête avec un corps a été abandonnée, car le backend a envoyé une réponse anticipée avec un code d'erreur. La réponse a été transmise au client. La requête a été arrêtée. 4XX ou 5XX
backend_connection_closed_after_partial_response_sent La connexion backend s'est interrompue de manière inattendue après l'envoi d'une réponse partielle au client.

Le code de réponse HTTP est défini par le logiciel exécuté sur le backend. Le code de réponse HTTP 0 (zéro) signifie que le backend a envoyé des en-têtes HTTP incomplets.

Le code de réponse HTTP est 101 si la connexion HTTP(S) a été mise à niveau vers une connexion WebSocket.
backend_connection_closed_before_data_sent_to_client Le backend a fermé de manière inattendue sa connexion à l'équilibreur de charge avant que la réponse ne soit envoyée par proxy au client.

502, 503

Le code de réponse HTTP est 101 si la connexion HTTP(S) a été mise à niveau vers une connexion WebSocket.
backend_early_response_with_non_error_status Le backend a envoyé une réponse sans erreur (1XX ou 2XX) à une requête avant de recevoir l'intégralité du corps de la requête. 502, 503
backend_interim_response_not_supported Le backend a envoyé une réponse 1XX provisoire à la requête alors que les réponses provisoires ne sont pas acceptées.

502, 503
backend_response_corrupted Le corps de la réponse HTTP envoyée par le backend présente un encodage de transfert en bloc non valide ou une autre forme de corruption. Tout code de réponse possible en fonction de la nature de la corruption. Il s'agit souvent du 502, 503.
backend_response_headers_too_long Les en-têtes de réponse HTTP envoyés par le backend dépassent la limite autorisée. Pour en savoir plus, consultez la section Taille d'en-tête pour les équilibreurs de charge d'application externes. 502, 503
backend_timeout

Le backend a expiré lors de la génération d'une réponse.

Pour une connexion WebSocket:

  • Pour l'équilibreur de charge d'application externe global, une erreur est générée lorsque le GFE ferme la connexion WebSocket à l'état inactif après l'expiration du délai avant expiration du service de backend.
  • Pour l'équilibreur de charge d'application classique, une erreur est générée lorsque le GFE ferme la connexion WebSocket à l'état inactif ou actif, une fois le délai avant expiration du service de backend expiré.

502, 503

Le code de réponse HTTP est 101 si la connexion HTTP(S) a été mise à niveau vers une connexion WebSocket.
banned_by_security_policy La requête a été interdite par une règle d'interdiction basée sur le taux Google Cloud Armor. 429
body_not_allowed Le client a envoyé une requête HTTP avec un corps, mais la méthode HTTP utilisée n'autorise pas de corps. 400
byte_range_caching_aborted L'équilibreur de charge a reçu une réponse indiquant que la ressource pouvait être mise en cache et acceptait les plages d'octet. Cloud CDN a reçu une réponse incohérente (par exemple, une réponse dont le code était différent du code "206 Partial Content" attendu). Cela s'est produit lors de la tentative de remplissage du cache à l'aide d'une requête de plage d'octets. L'équilibreur de charge a donc annulé la réponse au client. 2XX
byte_range_caching_forwarded_backend_response L'équilibreur de charge a reçu une réponse indiquant que la ressource pouvait être mise en cache et acceptait les plages d'octet. Cloud CDN a reçu une réponse incohérente (par exemple, une réponse dont le code était différent du code "206 Partial Content" attendu). Cela s'est produit lors de la tentative de remplissage du cache à l'aide d'une requête de plage d'octets. L'équilibreur de charge a ensuite transféré la réponse incohérente au client.

Renvoyé à partir du backend de VM. Tout code de réponse est possible.
byte_range_caching_retrieval_abandoned Le client a annulé une requête de plage d'octets ou une requête de validation lancée par Cloud CDN.

Renvoyé à partir du backend de VM. Tout code de réponse est possible.
byte_range_caching_retrieval_from_backend_failed_after_partial_response Une requête de plage d'octets ou une requête de validation lancée par Cloud CDN a rencontré une erreur. Reportez-vous à l'entrée de journal Cloud Logging correspondant à la requête lancée par Cloud CDN pour obtenir l'état détaillé du backend. 2XX
cache_lookup_failed_after_partial_response L'équilibreur de charge n'a pas pu diffuser une réponse complète à partir du cache Cloud CDN en raison d'une erreur interne. 2XX
cache_lookup_timeout_after_partial_response Le flux de recherche dans le cache Cloud CDN a expiré, car le client n'a pas récupéré le contenu en temps opportun. 2XX
client_disconnected_after_partial_response La connexion au client a été interrompue après que l'équilibreur de charge a envoyé une réponse partielle.

Renvoyé à partir du backend de VM. Tout code de réponse est possible.

Le code de réponse HTTP est 101 si la connexion HTTP(S) a été mise à niveau vers une connexion WebSocket.
client_disconnected_before_any_response La connexion au client a été interrompue avant que l'équilibreur de charge n'ait envoyé de réponse.

0

Le code de réponse HTTP est 101 si la connexion HTTP(S) a été mise à niveau vers une connexion WebSocket.
client_timed_out Le Google Front End (GFE) a rendu inactive la connexion au client en raison d'un manque de progression lors de l'envoi par proxy de la requête ou de la réponse. 0 ou 408
client_cert_invalid_rsa_key_size La taille de la clé RSA d'un certificat intermédiaire ou feuille client n'est pas valide. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_unsupported_elliptic_curve_key Un client ou un certificat intermédiaire utilise une courbe elliptique non compatible. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_unsupported_key_algorithm Un client ou un certificat intermédiaire utilise un algorithme non RSA ou ECEC. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_pki_too_large L'infrastructure PKI à utiliser pour la validation dispose de plus de trois certificats intermédiaires partageant les mêmes informations "Objet" et "Clé publique d'objet". Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_chain_max_name_constraints_exceeded Un certificat intermédiaire fourni pour la validation comportait plus de 10 contraintes de nom. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_chain_invalid_eku Le certificat client ou son émetteur ne dispose pas de Extended Key Usage (EKU) qui inclut clientAuth. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_validation_timed_out Le délai a été dépassé lors de la validation de la chaîne de certificats. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_validation_search_limit_exceeded La limite de profondeur ou d'itération est atteinte lors de la tentative de validation de la chaîne de certificats. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_validation_not_performed Vous avez configuré mTLS sans configurer de clé TrustConfig. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_not_provided Le client n'a pas fourni le certificat demandé lors du handshake. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
client_cert_validation_failed La validation du certificat client échoue avec l'TrustConfig lorsque des algorithmes de hachage tels que MD4, MD5 et SHA-1 sont utilisés. Pour en savoir plus, consultez la section Erreurs consignées pour les connexions fermées. 0
config_not_found

La configuration du projet est manquante de l'équilibreur de charge. Cela peut se produire de manière intermittente, en particulier après avoir effectué des modifications de configuration qui ajoutent une ressource.

Étant donné qu'il existe deux couches de proxys, il est possible que le GFE de première couche ne parvienne pas à atteindre le GFE de deuxième couche. Cela peut être dû à une erreur interne, comme un déploiement en cours, une surcharge de l'équilibreur de charge ou des problèmes de configuration intermittents.

 404, 502, 503
direct_response L'équilibreur de charge a remplacé cette requête et renvoyé une réponse fixe. Tout code de réponse HTTP peut s'afficher en fonction de la nature du problème. Par exemple, le code de réponse HTTP 410 signifie que le backend est indisponible en raison d'un défaut de paiement.
denied_by_security_policy L'équilibreur de charge a refusé cette requête en raison d'une règle de sécurité Google Cloud Armor. Configuré dans la règle de sécurité.
error_uncompressing_gzipped_body Une erreur s'est produite lors de la décompression d'une réponse HTTP compressée avec gzip. 502, 503
failed_to_connect_to_backend L'équilibreur de charge n'a pas pu se connecter au backend. Cela inclut les délais avant expiration pendant la phase de connexion. 502, 503
failed_to_pick_backend L'équilibreur de charge n'a pas pu sélectionner un backend opérationnel pour traiter la requête. 502, 503
failed_to_negotiate_alpn L'équilibreur de charge et le backend n'ont pas réussi à négocier un protocole de couche application (tel que HTTP/2) en vue de leur communication via TLS. 502, 503
headers_too_long Les en-têtes de requête dépassaient la taille maximale autorisée. 413
http_version_not_supported La version HTTP n'est pas acceptée. Actuellement, seuls les protocoles HTTP 0.9, 1.0, 1.1 et 2.0 sont compatibles. 400
internal_error Une erreur interne s'est produite au niveau de l'équilibreur de charge. Représente normalement une erreur temporaire dans l'infrastructure de l'équilibreur de charge. Relancez la requête. 4XX
invalid_external_origin_endpoint La configuration du backend externe n'est pas valide. Examinez la configuration du NEG Internet et assurez-vous qu'elle spécifie un port et une adresse FQDN/IP valides. 4XX
invalid_request_headers

Les en-têtes de requêtes HTTP reçus d'un client contiennent au moins un caractère non autorisé par une spécification HTTP applicable.

Par exemple, les noms de champ d'en-tête qui incluent des guillemets doubles (") ou des caractères en dehors de la plage ASCII standard (c'est-à-dire tout octet >= 0x80) ne sont pas valides.

Pour en savoir plus, consultez les pages suivantes :

 400
invalid_http2_client_header_format Les en-têtes HTTP/2 d'un client ne sont pas valides. Pour en savoir plus, consultez la section invalid_request_headers 400
invalid_http2_client_request_path

Le chemin d'accès de la requête HTTP/2 d'un client contient au moins un caractère non autorisé par la spécification de l'URI.

Pour en savoir plus, consultez la section 3.3. "Path" de la RFC 3986.

 400
multiple_iap_policies Il n'est pas possible de combiner plusieurs règles Identity-Aware Proxy (IAP). Si une règle IAP est associée à un service de backend et qu'une autre est associée à un objet sans serveur, vous devez en supprimer une, puis réessayer. Les objets sans serveur incluent App Engine, Cloud Run et Cloud Run Functions. 500
malformed_chunked_body Le corps de la requête n'a pas été correctement encodé en blocs. 411
request_loop_detected L'équilibreur de charge a détecté une boucle de requête. Cette boucle peut être imputable à une erreur de configuration du backend, lequel a renvoyé la requête à l'équilibreur de charge. 502, 503
required_body_but_no_content_length La requête HTTP nécessite un corps, mais les en-têtes de requête n'incluent pas d'en-tête en bloc Content-Length ou Transfer-Encoding. 400 ou 403
secure_url_rejected Une requête avec une URL https:// a été reçue via une connexion HTTP/1.1 en texte brut. 400
ssl_certificate_san_verification_failed L'équilibreur de charge n'a pas trouvé d'autre nom de l'objet (SAN, Subject Alternative Name) dans le certificat SSL présenté par le backend correspondant au nom d'hôte configuré. 502, 503
ssl_certificate_chain_verification_failed La validation du certificat SSL présenté par le backend a échoué. 502, 503
throttled_by_security_policy La requête a été bloquée par une règle de limitation de Google Cloud Armor. 429
unsupported_method Le client a fourni une méthode de requête HTTP non compatible. 400
unsupported_100_continue La requête client contenait l'en-tête "Expect: 100-continue" sur un protocole qui n'est pas compatible. 400
upgrade_header_rejected La requête HTTP du client contenait l'en-tête Upgrade et a été refusée. 400
websocket_closed La connexion WebSocket a été fermée. 101
websocket_handshake_failed Le handshake WebSocket a échoué. Tout code de réponse possible en fonction de la nature de l'échec du handshake.
request_body_too_large Le corps de la requête HTTP dépasse la limite maximale acceptée par le backend. Non applicable aux backends de VM. 413
handled_by_identity_aware_proxy Cette réponse a été générée par Identity-Aware Proxy lors de la vérification d'identité du client avant d'autoriser l'accès.

200, 302, 400, 401, 403, 500, 502, 503

429 (limité par l'IAP)
serverless_neg_routing_failed Impossible d'envoyer la requête NEG sans serveur. Cette erreur peut se produire lorsque la région spécifiée dans le NEG est inaccessible ou lorsque le nom de la ressource (par exemple, le nom des fonctions Cloud Run) est introuvable. 404, 502, 503
fault_filter_abort Cette erreur peut se produire si le client a configuré un filtre d'erreur et que celui-ci a été déclenché pour la requête donnée. La valeur doit être comprise entre 200 et 599.

Afficher les journaux pour la validation du certificat client mTLS

Pour afficher les erreurs consignées pour les connexions fermées lors de la validation du certificat client mutuel TLS, procédez comme suit :

Requête de la console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Cliquez sur le bouton Afficher la requête.

  3. Collez le texte suivant dans le champ de la requête. Remplacez FORWARDING_RULE_NAME par le nom de votre règle de transfert.

    jsonPayload.statusDetails=~"client_cert"
jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME

  4. Cliquez sur Exécuter la requête.

Journaux des requêtes de règles d'autorisation

L'objet authz_info de la charge utile JSON de l'entrée de journal de l'équilibreur de charge contient des informations sur les règles d'autorisation. Vous pouvez configurer des métriques basées sur les journaux pour le trafic autorisé ou refusé par ces règles.

Champ Type Description
authz_info.policies[] objet Liste des règles correspondant à la requête.
authz_info.policies[].name chaîne Nom de la règle d'autorisation correspondant à la requête.
Le nom est vide pour les raisons suivantes :
  • Aucune règle ALLOW ne correspond à la requête, et celle-ci est refusée.
  • Aucune règle DENY ne correspond à la requête, et celle-ci est autorisée.
authz_info.policies[].result énum Le résultat peut être ALLOWED ou DENIED.
authz_info.policies[].details chaîne Ces détails incluent les suivants :
  • allowed_as_no_deny_policies_matched_request
  • denied_as_no_allow_policies_matched_request
  • denied_by_authz_extension
  • denied_by_cloud_iap
authz_info.overall_result énum Le résultat peut être ALLOWED ou DENIED.

Journalisation pour Google Cloud Armor

La table des messages d'échec HTTP statusDetail contient des messages qui s'appliquent à Google Cloud Armor. Pour en savoir plus sur les journaux Google Cloud Armor, consultez la page Utiliser la journalisation des requêtes.

Journalisation pour les déploiements de VPC partagé

Les journaux et les métriques de l'équilibreur de charge d'application sont généralement exportés vers le projet qui comporte la règle de transfert. Par conséquent, les administrateurs de service (propriétaires ou utilisateurs de projets dans lesquels le service de backend est créé) n'ont pas accès aux journaux et aux métriques de l'équilibreur de charge par défaut. Vous pouvez utiliser les rôles IAM pour accorder ces autorisations aux administrateurs de service. Pour en savoir plus sur les rôles IAM disponibles et sur les étapes pour fournir l'accès, consultez la page Accorder l'accès à Monitoring.

Interagir avec les journaux

Vous pouvez interagir avec les journaux de l'équilibreur de charge d'application externe à l'aide de l'API Cloud Logging. L'API Logging permet de filtrer de manière interactive les journaux pour lesquels des champs spécifiques sont définis. Il exporte les journaux correspondants vers Cloud Logging, Cloud Storage, BigQuery ou Pub/Sub. Pour en savoir plus sur l'API Logging, consultez la page Présentation de l'API Cloud Logging.

Surveillance

L'équilibreur de charge exporte les données de surveillance vers Cloud Monitoring.

Vous pouvez utiliser des métriques de surveillance pour effectuer les opérations suivantes :

  • Évaluer la configuration, l'utilisation et les performances d'un équilibreur de charge
  • Identifier et résoudre les problèmes
  • Améliorer l'utilisation des ressources et l'expérience utilisateur

Fréquence et conservation des rapports sur les métriques

Les métriques des équilibreurs de charge d'application externes sont exportées vers Cloud Monitoring par lots de précision d'une minute. Les données de surveillance sont conservées pendant six semaines.

Le tableau de bord fournit une analyse des données à des intervalles par défaut d'une heure, de six heures, d'un jour, d'une semaine et de six semaines. Vous pouvez demander manuellement une analyse à un intervalle compris entre une minute et six semaines.

Métriques de surveillance

Vous pouvez surveiller les métriques suivantes pour les équilibreurs de charge d'application externes.

Les métriques suivantes pour les équilibreurs de charge d'application externes globaux sont consignées dans Cloud Monitoring. Ces métriques sont précédées du préfixe loadbalancing.googleapis.com/.

Métrique Nom Description
Nombre de requêtes https/request_count Nombre de requêtes diffusées par l'équilibreur de charge d'application externe
Nombre d'octets de requête https/request_bytes_count Nombre d'octets envoyés en tant que requêtes par les clients à l'équilibreur de charge d'application externe.
Nombre d'octets de réponse https/response_bytes_count Nombre d'octets envoyés en tant que réponses aux clients par l'équilibreur de charge d'application externe
Total des latences https/total_latencies

Distribution de la latence. La latence correspond au temps écoulé entre le premier octet de la requête reçue et le dernier octet de la réponse envoyée par le GFE.

Le total des latences est mesuré par requête/réponse. Les pauses entre les requêtes sur la même connexion qui utilisent Connection: keep-alive n'ont pas d'incidence sur la mesure. Cette mesure est généralement réduite au 95e centile dans les vues Cloud Monitoring.

Pour les connexions WebSocket, ce champ fait référence à la durée totale de la connexion.†

Exemple : un équilibreur de charge reçoit une requête par seconde en provenance du Royaume-Uni, avec une latence de 100 ms, et neuf requêtes par seconde en provenance des États-Unis, avec une latence de 50 ms. En une minute, il y a eu 60 requêtes en provenance du Royaume-Uni et 540 requêtes en provenance des États-Unis. Les métriques de surveillance conservent la distribution sur toutes les dimensions. Vous pouvez demander les informations suivantes :

  • Latence globale médiane (300/600) : 50 ms
  • Latence médiane pour le Royaume-Uni (30/60) : 100 ms
  • Latence globale au 95e centile (570/600) : 100 ms
DAR d'interface* https/frontend_tcp_rtt Distribution du délai aller-retour (DAR) lissé mesurée pour chaque connexion entre le client et le GFE (mesurée par la pile TCP du GFE). Le DAR lissé est un algorithme qui traite les variations et les anomalies pouvant se produire dans les mesures de latence DAR.
Latences de backend* https/backend_latencies

Distribution de la latence mesurée entre le moment où le premier octet de la requête est envoyé par le proxy au backend et le moment où le proxy reçoit le dernier octet de la réponse du backend.

Pour les connexions WebSocket, les latences de backend s'appliquent à toute la durée de la session WebSocket.†
Fraction par classe de code de réponse Fraction du total des réponses de l'équilibreur de charge d'application externe figurant dans chaque classe de code de réponse (2XX, 4XX, etc.). Dans Cloud Monitoring, cette valeur n'est disponible que dans les tableaux de bord par défaut. Elle n'est pas disponible dans les tableaux de bord personnalisés. Vous pouvez utiliser l'API pour définir des alertes pour cette métrique.
Nombre de requêtes des backends https/backend_request_count Nombre de requêtes envoyées par l'équilibreur de charge d'application externe aux backends.
Nombre d'octets de requête des backends https/backend_request_bytes_count Nombre d'octets envoyés en tant que requêtes de l'équilibreur de charge d'application externe aux backends.
Nombre d'octets de réponse des backends https/backend_response_bytes_count Nombre d'octets envoyés en tant que réponses par les backends (y compris le cache) à l'équilibreur de charge d'application externe.

* Il n'est pas garanti que la somme du DAR d'interface et des latences de backend soit inférieure ou égale au total des latences. En effet, bien que nous interrogions le DAR sur le socket du GFE au client au moment où l'accusé de réception de la réponse HTTP est envoyé, nous dépendons des rapports du noyau pour certaines des mesures, et nous ne pouvons pas garantir que le noyau aura une mesure du DAR spécifique pour la réponse HTTP concernée. Le résultat final est une valeur DAR lissée qui est également affectée par les précédentes réponses HTTP, les demandes de synchronisation/accusés de réception (SYN/ACK) et les handshakes SSL qui n'affectent pas les durées réelles des requêtes HTTP.

† Pour surveiller les connexions WebSocket, créez un service de backend spécifiquement pour les WebSocket.

Filtrer les dimensions pour les métriques

Vous pouvez appliquer des filtres de métriques pour les équilibreurs de charge d'application externes.

Les métriques sont agrégées pour chaque équilibreur de charge d'application classique et équilibreur de charge d'application externe global. Vous pouvez filtrer les métriques agrégées selon les dimensions suivantes pour resource.type="http_load_balancer" ou resource.type="https_lb_rule". Notez que toutes les dimensions ne sont pas disponibles pour toutes les métriques.

Propriété Description
backend_scope Champ d'application Google Cloud (région ou zone) du groupe d'instances de service de backend ayant diffusé la connexion.

Si aucun groupe d'instances n'était disponible ou si la requête a été diffusée par une autre entité, l'une des valeurs suivantes s'affiche à la place de la région ou de la zone du groupe d'instances de service de backend.

  • FRONTEND_5XX : une erreur interne s'est produite avant que le GFE ne puisse sélectionner un backend. Le GFE a renvoyé un code 5XX au client.
  • INVALID_BACKEND : le GFE n'a pas pu trouver un backend opérationnel auquel attribuer la requête. Par conséquent, il a renvoyé une réponse 5XX au demandeur.
  • NO_BACKEND_SELECTED : une erreur ou une autre interruption s'est produite avant qu'un backend puisse être sélectionné ou qu'une redirection d'URL ne se produise.
  • MULTIPLE_BACKENDS : la requête a potentiellement été diffusée par plusieurs backends. Cela peut se produire lorsque Cloud CDN a diffusé la requête partiellement à partir de son cache et a également envoyé une ou plusieurs requêtes de plage d'octets au backend. Utilisez la répartition backend_scope pour visualiser chaque requête de l'équilibreur de charge vers le backend.

Une fois cette répartition effectuée, les graphiques affichent les métriques de backend (équilibreur de charge vers backends), et non les métriques d'interface (client vers équilibreur de charge).
backend_type

Nom du groupe d'instances ayant diffusé la requête du client. Peut être INSTANCE GROUP, NETWORK_ENDPOINT_GROUP ou UNKNOWN si le backend n'a pas été attribué. Si aucun groupe de backend n'était disponible ou si la requête a été diffusée par une autre entité, l'une des valeurs suivantes s'affiche à la place d'un groupe de backend.

  • FRONTEND_5XX : une erreur interne s'est produite avant que le GFE ne puisse sélectionner un backend. Le GFE a renvoyé un code 5XX au client.
  • INVALID_BACKEND : le GFE n'a pas pu trouver un backend opérationnel auquel attribuer la requête. Par conséquent, il a renvoyé une réponse 5XX au demandeur.
  • NO_BACKEND_SELECTED : une erreur ou une autre interruption s'est produite avant qu'un backend puisse être sélectionné ou qu'une redirection d'URL ne se produise.
  • MULTIPLE_BACKENDS : la requête a potentiellement été diffusée par plusieurs backends. Cela peut se produire lorsque Cloud CDN a diffusé la requête partiellement à partir de son cache et a également envoyé une ou plusieurs requêtes de plage d'octets au backend. Utilisez la répartition backend_scope pour visualiser chaque requête de l'équilibreur de charge vers le backend.
backend_target_type Nom du service de backend ayant diffusé la requête du client. Peut être BACKEND_SERVICE, BACKEND_BUCKET ou UNKNOWN si le backend n'a pas été attribué, ou NO_BACKEND_SELECTED si une erreur ou une autre interruption s'est produite avant qu'un backend puisse être sélectionné ou qu'une redirection d'URL ne se produise.
matched_url_path_rule Règle de chemin de mappage d'URL correspondant au préfixe de la requête HTTP(S) (50 caractères maximum).
forwarding_rule_name Nom de la règle de transfert utilisée par le client pour envoyer la requête.
url_map_name

Règle de chemin de mappage d'URL ou règle de routage configurée dans le cadre de la clé de mappage d'URL. En cas d'absence de correspondance, ce champ peut prendre la valeur UNMATCHED ou UNKNOWN.

  • UNMATCHED fait référence à une requête qui ne correspond à aucune règle de chemin d'URL. url_map_name utilise donc la règle de chemin par défaut.
  • UNKNOWN indique une erreur interne.
target_proxy_name Nom de l'objet de proxy HTTP(S) cible référencé par la règle de transfert.
backend_target_name Nom de la cible de backend. La cible peut être un service de backend ou un bucket backend. UNKNOWN est renvoyé si un backend n'a pas été attribué.
backend_name Nom du groupe d'instances backend, du bucket ou du groupe de points de terminaison du réseau. UNKNOWN est renvoyé si le backend n'a pas été attribué, ou NO_BACKEND_SELECTED si une erreur ou une autre interruption s'est produite avant qu'un backend puisse être sélectionné ou qu'une redirection d'URL ne se produise.
backend_scope_type

Type de champ d'application du groupe backend. Peut être GLOBAL, REGION, ZONE, MULTIPLE_BACKENDS ou NO_BACKEND_SELECTED si une erreur ou une autre interruption s'est produite avant qu'un backend puisse être sélectionné ou qu'une redirection d'URL ne se produise, ou d'autres sorties backend_type possibles.

MULTIPLE_BACKENDS est utilisé lorsque la mise en cache par blocs est utilisée. Plusieurs requêtes sont envoyées au même backend pour différents blocs de données afin de prendre en charge une seule requête client.
proxy_continent Continent du GFE HTTP(S) ayant mis fin à la connexion HTTP(S) de l'utilisateur. Exemples : America, Europe, Asia.
protocol Protocole utilisé par le client, l'un des protocoles suivants : HTTP/1.0, HTTP/1.1, HTTP/2.0, QUIC/HTTP/2.0 ou UNKNOWN.
response_code Code de réponse HTTP de la requête.
response_code_class Classe de code de réponse HTTP de la requête: 200, 300, 400, 500 ou 0 pour aucune.
cache_result Résultat du cache pour la diffusion de la requête HTTP par proxy: HIT, MISS, DISABLED, PARTIAL_HIT (pour une requête diffusée en partie depuis le cache et en partie depuis le backend) ou UNKNOWN.
client_country Pays du client ayant émis la requête HTTP (par exemple, United States ou Germany)
load_balancing_scheme Schéma d'équilibrage de charge utilisé. Si l'équilibreur de charge d'application classique est utilisé, la valeur est EXTERNAL. Si un équilibreur de charge d'application externe global est utilisé, la valeur est EXTERNAL_MANAGED.

Étape suivante