Journalisation et surveillance de l'équilibrage de charge HTTP(S)

Ce document fournit les informations dont vous avez besoin pour comprendre la journalisation et la surveillance Stackdriver pour l'équilibrage de charge HTTP(S).

Logging

Vous pouvez activer, désactiver et afficher les journaux d'un service de backend d'équilibrage de charge HTTP(S).

Par défaut, un équilibreur de charge HTTP(S) journalise toutes les requêtes dans Stackdriver Logging. Vous pouvez modifier les paramètres du service de backend pour désactiver complètement la journalisation ou définir l'équilibreur de charge de manière à ne journaliser qu'une fraction aléatoire des requêtes, et ainsi réaliser des économies en matière d'espace et de coûts de stockage.

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

Console

  1. Dans la console Google Cloud Platform, 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 l'icône Modifier (en forme de crayon) en regard de votre service de backend.
  6. Cliquez sur Configurations avancées (affinité de session, délai avant expiration du drainage de connexion).
  7. Décochez la case Activer la journalisation pour désactiver complètement la journalisation.
  8. Si vous laissez la journalisation activée, vous pouvez définir un autre taux d'échantillonnage. Vous pouvez définir une valeur comprise entre 0.0 et 1.0 (valeur par défaut). Pour réduire le nombre de journaux stockés à 20 %, définissez la valeur sur 0.2.
  9. Cliquez sur Mettre à jour.

gcloud

Désactiver complètement la journalisation

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --no-enable-logging

où :

  • --no-enable-logging désactive la journalisation pour ce service de backend.

Modifier le taux d'échantillonnage des journaux

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --logging-sample-rate=[VALUE]

où :

  • --logging-sample-rate permet de spécifier une valeur comprise entre 0.0 et 1.0, où 0.0 signifie qu'aucun paquet n'est journalisé et 1.0 signifie que 100 % des paquets sont journalisés.

Activer la journalisation sur un service de backend existant

Console

  1. Dans la console Google Cloud Platform, 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 l'icône "Modifier" (en forme de crayon) en regard de votre service de backend.
  6. Cliquez sur Configurations avancées (affinité de session, délai avant expiration du drainage de connexion).
  7. Cliquez sur Activer la journalisation.
  8. Définissez un taux d'échantillonnage. Vous pouvez définir une valeur comprise entre 0.0 et 1.0 (valeur par défaut).
  9. Cliquez sur Mettre à jour.

gcloud

gcloud beta compute backend-services update [BACKEND_SERVICE] \
 --enable-logging \
 --logging-sample-rate=[VALUE]

où :

  • --enable-logging active la journalisation pour ce service de backend.
  • --logging-sample-rate permet de spécifier une valeur comprise entre 0.0 et 1.0, où 0.0 signifie qu'aucun paquet n'est journalisé et 1.0 signifie que 100 % des paquets sont journalisés. Utile seulement avec le 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 afficher les journaux, accédez à la page Visionneuse de journaux.

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

  • Pour afficher tous les journaux, dans le premier menu déroulant, 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 dans la liste.
  • Pour afficher les journaux d'un seul mappage d'URL utilisé par une règle de transfert, sélectionnez une règle de transfert, puis choisissez le mappage d'URL qui vous intéresse.

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.

Vous pouvez configurer l'exportation de métriques basées sur les journaux Stackdriver pour les journaux de ressources de l'équilibreur de charge HTTP(S) cloud (resource.type=http_load_balancer). Les métriques créées sont basées sur la ressource "Règle d'équilibrage de charge HTTP Google Cloud (métriques basées sur les journaux)" (l7_lb_rule), disponible dans les tableaux de bord Stackdriver Monitoring, plutôt que sur la ressource https_lb_rule :

Accéder à Monitoring

Contenu consigné

Les entrées de journal d'équilibrage de charge HTTP(S) contiennent des informations utiles pour surveiller et déboguer votre trafic HTTP(S). Il s'agit des types d'informations suivants :

  • Informations générales figurant dans la plupart des journaux GCP, telles que la gravité, l'ID et le numéro de projet ou l'horodatage
  • Champs de journal HttpRequest. Toutefois, HttpRequest.protocol et HttpRequest.latency ne sont pas renseignés pour les journaux Stackdriver d'équilibrage de charge HTTP(S).
  • Un champ statusDetails dans structPayload. Ce champ contient une chaîne qui explique la raison pour laquelle l'équilibreur de charge a renvoyé l'état HTTP. Les tableaux ci-dessous contiennent des explications supplémentaires sur ces chaînes de journal.

Messages de réussite HTTP statusDetail

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. 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. 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 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. Renvoyé à partir du backend de VM. Tout code de réponse est possible.

Messages d'échec HTTP statusDetail

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_503_propagated_as_error Le backend a envoyé une réponse indiquant une erreur 503. Ce code d'erreur peut signaler un problème de performances ou de configuration dans le backend. 503
backend_connection_closed_after_partial_response_sent La connexion du backend s'est fermée de manière inattendue après l'envoi d'une réponse partielle au client. Renvoyé à partir du backend de VM. Tout code de réponse est possible. La valeur 0 indique que le backend n'a pas envoyé d'en-têtes de réponse complets.
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. Cela peut se produire si l'équilibreur de charge envoie du trafic à une autre entité, par exemple un équilibreur de charge tiers s'exécutant sur une instance de VM dont le délai avant expiration TCP est inférieur au délai avant expiration de l'équilibreur de charge HTTP(S), qui est de 10 minutes (600 secondes). Vous pouvez essayer de résoudre ce problème en définissant manuellement le délai avant expiration TCP (message keepalive) sur le service cible sur une valeur supérieure à 600 secondes. 502
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
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
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.
backend_timeout Le backend a expiré lors de la génération d'une réponse. 502
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 abandonné l'envoi d'une réponse en raison de plages d'octets incohérentes. 2XX
byte_range_caching_forwarded_backend_response L'équilibreur de charge n'a pas pu fournir une réponse à l'aide de la mise en cache de la plage d'octets, mais a pu envoyer une réponse à partir du backend. Renvoyé à partir du backend. Tout code de réponse est possible.
byte_range_caching_retrieval_abandoned L'utilisateur a annulé une requête de plage d'octets ou une requête de validation lancée par Cloud CDN. Renvoyé à partir du backend. 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 Stackdriver 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 fournir une réponse complète à partir du cache en raison d'une erreur interne. 2XX
cache_lookup_timeout_after_partial_response Le flux de recherche dans le cache 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.
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
client_timed_out L'équilibreur de charge 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
denied_by_security_policy L'équilibreur de charge a refusé cette requête en raison d'un règlement de sécurité Cloud Armor. Configuré dans le règlement 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. 503
failed_to_connect_to_backend L'équilibreur de charge n'a pas pu se connecter au backend. 502
failed_to_pick_backend L'équilibreur de charge n'a pas pu sélectionner un backend opérationnel pour traiter la requête. 502
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
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. 4XX
invalid_http2_client_header_format Les en-têtes HTTP/2 du client ne sont pas valides. 400
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. Cela peut être dû à une erreur de configuration du backend qui a renvoyé la requête à l'équilibreur de charge. 502
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 blocs 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_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
ssl_certificate_chain_verification_failed La validation du certificat SSL présenté par le backend a échoué. 502
unsupported_method Le client a fourni une méthode de requête HTTP non compatible. 400
upgrade_header_rejected La requête HTTP du client contenait l'en-tête Upgrade et a été refusée. 400
uri_too_long L'URI de la requête HTTP dépassait la longueur maximale autorisée. 414
websocket_closed La connexion WebSocket a été fermée.
websocket_handshake_failed Le handshake WebSocket a échoué. Tout code de réponse possible en fonction de la nature de l'échec du handshake.

Journalisation pour la liste d'autorisation/d'interdiction d'adresses IP

Les entrées de journal suivantes dans la visionneuse de journaux concernent la journalisation pour la liste d'autorisation/d'interdiction d'adresses IP HTTP(S) et incluent la structure suivante dans jsonPayload. Les détails de la requête HTTP apparaissent dans le message httpRequest.

  • status_details (chaîne) : description textuelle du code de réponse
  • enforced_security_policy : règle du règlement de sécurité qui a été appliquée
    • outcome (chaîne) : ACCEPT, DENY ou UNKNOWN_OUTCOME
    • configured_action (chaîne) : identique à "outcome"
    • name (chaîne) : nom de la stratégie de sécurité
    • priority (nombre) : priorité de la règle correspondante
  • preview_security_policy : renseigné si la requête a appelé une règle configurée pour l'aperçu (présent seulement lorsqu'une règle d'aperçu est prioritaire sur la règle appliquée)
    • outcome (chaîne) : ACCEPT, DENY ou UNKNOWN_OUTCOME
    • configured_action (chaîne) : identique à "outcome"
    • name (chaîne) : nom de la stratégie de sécurité
    • priority (nombre) : priorité de la règle correspondante

Vous pouvez interagir avec les journaux de l'équilibreur de charge HTTP(S) à l'aide de l'API Stackdriver Logging. Celle-ci permet de filtrer de façon interactive les journaux pour lesquels des champs spécifiques sont définis, et d'exporter les journaux correspondants vers la console Stackdriver, Google Cloud Storage, BigQuery ou Cloud Pub/Sub. Pour plus d'informations sur l'API Stackdriver Logging, consultez la page Afficher les journaux.

Monitoring

L'équilibrage de charge HTTP(S) exporte les données de surveillance vers Stackdriver.

Les métriques de surveillance peuvent être utilisées aux fins 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

En plus des tableaux de bord prédéfinis dans Stackdriver, vous pouvez créer des tableaux de bord personnalisés, configurer des alertes et interroger les métriques via l'API Stackdriver Monitoring.

Afficher les tableaux de bord Stackdriver Monitoring

  1. Accédez à Monitoring dans la console Google Cloud Platform.
    Accéder à Monitoring
  2. Sélectionnez Ressources > Équilibreurs de charge Google Cloud.
  3. Cliquez sur le nom de votre équilibreur de charge.

Dans le volet de gauche, vous pouvez voir diverses informations concernant cet équilibreur de charge HTTP(S). Le volet de droite présente les graphiques de séries temporelles. Cliquez sur le lien Breakdowns (Répartitions) pour afficher des répartitions spécifiques.

Définir des alertes Stackdriver

Vous pouvez définir des alertes Stackdriver pour diverses métriques d'équilibrage de charge HTTP(S) :

  1. Accédez à Monitoring dans la console Google Cloud Platform.
    Accéder à Monitoring
  2. Sélectionnez Alertes > Créer une règle.
  3. Cliquez sur Add Condition (Ajouter une condition), puis sélectionnez un type de condition.
  4. Sélectionnez des métriques et des filtres. Pour les métriques, le type de ressource est Équilibreur de charge HTTP(S).
  5. Cliquez sur Enregistrer la condition.
  6. Saisissez le nom d'une règle, puis cliquez sur Save Policy (Enregistrer la règle).

Définir des tableaux de bord Stackdriver personnalisés

Vous pouvez créer des tableaux de bord Stackdriver personnalisés pour les métriques d'équilibrage de charge HTTP(S) :

  1. Accédez à Monitoring dans la console Google Cloud Platform.
    Accéder à Monitoring
  2. Sélectionnez Tableaux de bord > Créer un tableau de bord.
  3. Cliquez sur Add Chart (Ajouter un graphique).
  4. Indiquez un titre pour le graphique.
  5. Sélectionnez des métriques et des filtres. Pour les métriques, le type de ressource est Équilibreur de charge HTTP(S).
  6. Cliquez sur Enregistrer.

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

Les métriques des équilibreurs de charge HTTP(S) sont exportées vers Stackdriver 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 pour les équilibreurs de charge HTTP(S)

Les métriques suivantes pour les équilibreurs de charge HTTP(S) sont consignées dans Stackdriver :

Métrique Description
Nombre de requêtes Nombre de requêtes diffusées par l'équilibreur de charge HTTP(S).
Nombre d'octets de requête Nombre d'octets envoyés en tant que requêtes par les utilisateurs à l'équilibreur de charge HTTP(S).
Nombre d'octets de réponse Nombre d'octets envoyés en tant que réponses aux utilisateurs depuis l'équilibreur de charge HTTP(S).
Total des latences Distribution de la latence mesurée entre le moment où le proxy de l'équilibreur de charge reçoit le premier octet de la requête et le moment où le proxy reçoit un accusé de réception du client demandeur sur le dernier octet de réponse. Le total des latences est mesuré par requête/réponse. Par conséquent, les pauses entre les requêtes sur la même connexion à l'aide de l'en-tête "Connection: keep-alive" n'ont pas d'incidence sur la mesure. Celle-ci est généralement réduite au 95e centile dans les vues Stackdriver.
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 éléments suivants :
  • 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
  • et ainsi de suite...
DAR d'interface(*) Distribution du délai aller-retour (RTT, Round-Trip Time) lissé mesurée pour chaque connexion entre le client et le proxy (mesurée par la pile TCP du proxy). Généralement réduite au 95e centile dans les vues Stackdriver.
Latences de backend(*) 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. Généralement réduite au 95e centile dans les vues Stackdriver.
Fraction par classe de code de réponse Fraction du total des réponses de l'équilibreur de charge HTTP(S) figurant dans chaque classe de code de réponse (2XX, 4XX, etc.). Dans Stackdriver, 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 définir des alertes pour cette métrique via l'API.
Nombre de requêtes des backends Nombre de requêtes envoyées par l'équilibreur de charge HTTP(S) aux backends.
Nombre d'octets de requête des backends Nombre d'octets envoyés en tant que requêtes par l'équilibreur de charge HTTP(S) aux backends.
Nombre d'octets de réponse des backends Nombre d'octets envoyés en tant que réponses par les backends à l'équilibreur de charge HTTP(S).

(*) 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 proxy 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.

Dimensions de filtrage pour les métriques d'équilibreur de charge HTTP(S)

Les métriques sont agrégées pour chaque équilibreur de charge HTTP(S). Vous pouvez filtrer les métriques agrégées selon les dimensions suivantes(*) :

Propriété Description
BACKEND SCOPE Champ d'application (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 proxy ne puisse sélectionner un backend. Le proxy a renvoyé un code 5XX au client.
  • INVALID_BACKEND : le proxy 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 ne puisse être sélectionné.
  • INVALID_BACKEND : le proxy n'a pas pu trouver de backend opérationnel valide. Par conséquent, il a renvoyé un code 5XX au demandeur.
  • SERVED_FROM_BACKEND_BUCKET : la requête a été traitée par un bucket backend, et non par un groupe d'instances de service de backend.
  • SERVED_FROM_CACHE : la requête a été traitée par un cache proxy. Par conséquent, aucun backend n'a été attribué.
  • MULTIPLE_BACKENDS : la requête a été diffusée par plusieurs backends.

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 ZONE Si le groupe d'instances était zonal, il s'agit de la zone GCP du groupe d'instances qui a diffusé la requête de l'utilisateur. (Exemples : us-central1-a, europe-west1-b, asia-east1-c)

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 REGION Si le groupe d'instances était régional, il s'agit de la région GCP du groupe d'instances qui a diffusé la requête de l'utilisateur. (Exemples : us-central1, europe-west1, asia-east1)

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).
PROXY CONTINENT Continent du proxy HTTP(S) qui a mis fin à la connexion HTTP(S) de l'utilisateur. (Exemples : America, Europe, Asia)
INSTANCE GROUP Nom du groupe d'instances qui a diffusé la requête de l'utilisateur.

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 d'un groupe d'instances.
  • FRONTEND_5XX : une erreur interne s'est produite avant que le proxy ne puisse sélectionner un backend. Le proxy a renvoyé un code 5XX au client.
  • INVALID_BACKEND : le proxy 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 ne puisse être sélectionné.
  • INVALID_BACKEND : le proxy n'a pas pu trouver de backend opérationnel valide. Par conséquent, il a renvoyé un code 5XX au demandeur.
  • SERVED_FROM_BACKEND_BUCKET : la requête a été traitée par un bucket backend, et non par un groupe d'instances de service de backend.
  • SERVED_FROM_CACHE : la requête a été traitée par un cache proxy. Par conséquent, aucun backend n'a été attribué.
  • MULTIPLE_BACKENDS : la requête a été diffusée par plusieurs backends.

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 SERVICE Nom du service de backend qui a diffusé la requête de l'utilisateur.
MATCHED URL RULE Règle de chemin de mappage d'URL correspondant au préfixe de la requête HTTP(S) de l'utilisateur (50 caractères maximum).
FORWARDING RULE Nom de la règle de transfert utilisée par le client pour envoyer la requête.

(*) Actuellement, la métrique "Fraction par classe de code de réponse" n'est disponible que pour l'équilibreur de charge entier, sans autre répartition possible.

Étape suivante