Ce document fournit les informations dont vous avez besoin pour comprendre l'utilisation de Cloud Logging et de Cloud Monitoring 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).
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 à l'équilibreur de charge HTTP(S) externe. 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.
Activer la journalisation sur un nouveau service de backend
Console
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page "Équilibrage de charge" - Cliquez sur le nom de votre équilibreur de charge.
- Cliquez sur Modifier ().
- Cliquez sur Configuration du backend.
- Cliquez sur Modifier à côté de votre service de backend.
- Décochez la case Activer la journalisation pour désactiver complètement la journalisation.
- 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.0et1.0(valeur par défaut). Pour réduire le nombre de journaux stockés à 20 %, définissez la valeur sur0.2. - Cliquez sur Mettre à jour.
gcloud
gcloud compute backend-services create BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate=VALUE \ ... other values
Où :
--globalindique que le service de backend est global.--enable-loggingactive la journalisation pour ce service de backend.--logging-sample-rate=<var>VALUE</var>permet de spécifier une valeur entre0.0et1.0, où0.0signifie qu'aucune requête n'est enregistrée et1.0signifie 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 sur0.0équivaut à désactiver la journalisation.
Activer la journalisation sur un service de backend existant
Console
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page "Équilibrage de charge" - Cliquez sur le nom de votre équilibreur de charge.
- Cliquez sur Modifier ().
- Cliquez sur Configuration du backend.
- Cliquez sur Modifier à côté de votre service de backend.
- Cliquez sur Activer la journalisation.
- Définissez un taux d'échantillonnage. Vous pouvez définir un tarif de
0.0à1.0(par défaut). - Cliquez sur Mettre à jour.
gcloud
gcloud compute backend-services update BACKEND_SERVICE \
--global \
--enable-logging \
--logging-sample-rate=VALUE
Où :
--globalindique que le service de backend est global.--enable-loggingactive la journalisation pour ce service de backend.--logging-sample-rate=<var>VALUE</var>permet de spécifier une valeur entre0.0et1.0, où0.0signifie qu'aucune requête n'est enregistrée et1.0signifie 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 sur0.0équivaut à désactiver la journalisation.
Désactiver ou modifier la journalisation sur un service de backend existant
Console
- Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
Accéder à la page "Équilibrage de charge" - Cliquez sur le nom de votre équilibreur de charge.
- Cliquez sur Modifier .
- Cliquez sur Configuration du backend.
- Cliquez sur edit à côté de votre service de backend.
- Décochez la case Activer la journalisation pour désactiver complètement la journalisation.
- Si vous laissez la journalisation activée, vous pouvez définir un autre taux d'échantillonnage. Vous pouvez définir une valeur de
0.0à1.0(valeur par défaut). Pour réduire le nombre de journaux stockés à 20 %, définissez la valeur sur0.2. - Cliquez sur Mettre à jour.
gcloud
Désactiver complètement la journalisation
gcloud compute backend-services update BACKEND_SERVICE \
--global \
--no-enable-logging
Où :
--globalindique que le service de backend est global.--no-enable-loggingdé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ù :
--globalindique que le service de backend est global.--logging-sample-rate=<var>VALUE</var>permet de spécifier une valeur entre0.0et1.0, où0.0signifie qu'aucune requête n'est enregistrée et1.0signifie 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 sur0.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.
- Pour afficher les journaux d'un seul mappage d'URL, sélectionnez une règle de transfert, puis choisissez 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.
Vous pouvez configurer l'exportation de métriques basées sur les journaux pour les journaux de ressources de l'équilibreur de charge HTTP(S) externe (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 Cloud Monitoring au lieu de sous la ressource https_lb_rule :
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, telles que le niveau de gravité, l'ID de projet, le numéro de projet et l'horodatage.
- Champs de journal HttpRequest Toutefois,
HttpRequest.protocoln'est pas renseigné pour les journaux Cloud Logging d'équilibrage de charge HTTP(S). - Un champ
statusDetailsdansstructPayload. 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. - Les redirections (code d'état de réponse HTTP 302 trouvé) émises par l'équilibreur de charge ne sont pas consignées. Les redirections émises à partir des instances backend sont consignées.
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 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. | Renvoyée à partir du backend : le code de réponse HTTP est défini par le logiciel exécuté sur le backend. |
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_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. |
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 le trafic vers une autre entité. L'autre entité peut être un équilibreur de charge tiers dont le délai avant expiration TCP est inférieur à celui de l'équilibreur de charge HTTP(S) externe, qui est de 10 minutes (600 secondes). L'équilibreur de charge tiers est peut-être en cours d'exécution sur une instance de VM. Vous pouvez essayer de résoudre le 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_response_headers_too_long
|
Les en-têtes de réponse HTTP envoyés par le backend dépassent la limite autorisée. Consultez la section Taille d'en-tête pour l'équilibrage de charge HTTP(S) pour en savoir plus sur les limites. | 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 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. 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. 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 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
|
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 |
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. | 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 |
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. 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 de l'origine personnalisée 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_http2_client_header_format
|
Les en-têtes HTTP/2 d'un client ne sont pas valides. | 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 (entièrement géré) et Cloud 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 |
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_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. | 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 |
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 Cloud Functions) est introuvable. | 404, 502 |
Journalisation pour les listes de blocage et d'autorisation des adresses IP
Les entrées de journal suivantes dans la visionneuse de journaux concernent la journalisation pour la liste de blocage et la liste d'autorisation 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éponseenforced_security_policy: règle de la stratégie de sécurité qui a été appliquéeoutcome(chaîne) :ACCEPT,DENYouUNKNOWN_OUTCOMEconfigured_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,DENYouUNKNOWN_OUTCOMEconfigured_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) externe à l'aide de l'API Cloud 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 Cloud Logging, Cloud Storage, BigQuery ou Pub/Sub. Pour en savoir plus sur l'API Cloud Logging, consultez la page Afficher les journaux.
Monitoring
L'équilibrage de charge HTTP(S) exporte les données de surveillance vers Cloud Monitoring.
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 Cloud Monitoring, vous pouvez créer des tableaux de bord personnalisés, configurer des alertes et interroger les métriques via l'API Cloud Monitoring.
Afficher les tableaux de bord Cloud Monitoring
Accédez à Monitoring dans Google Cloud Console.
Si le volet de navigation Monitoring affiche Services, sélectionnez Services > Équilibreurs de charge cloud. Pour afficher le tableau de bord d'un équilibreur de charge spécifique, localisez celui-ci dans la liste, puis cliquez sur son nom.
Sinon, sélectionnez Tableaux de bord :
Pour afficher la liste des tableaux de bord de vos équilibreurs de charge Google Cloud, sélectionnez le tableau de bord nommé Équilibreurs de charge cloud. Pour afficher le tableau de bord d'un équilibreur de charge spécifique, localisez celui-ci dans la liste, puis cliquez sur son nom.
Pour afficher la liste des tableaux de bord de vos équilibreurs de charge AWS, sélectionnez le tableau de bord nommé Amazon Web Services. Pour afficher le tableau de bord d'un équilibreur de charge spécifique, localisez celui-ci dans la liste, puis cliquez sur son nom.
Le volet de gauche affiche diverses informations concernant l'équilibreur de charge HTTP(S) externe. Le volet de droite présente les graphiques de séries temporelles. Cliquez sur le lien Répartitions pour afficher des répartitions spécifiques.
Définir des règles d'alerte
Vous pouvez créer des règles d'alerte pour surveiller les valeurs des métriques et être informé lorsqu'elles ne respectent pas une condition. Pour créer une règle d'alerte qui surveille une ou plusieurs ressources Règle d'équilibrage de charge HTTP/S Google Cloud, procédez comme suit :
- Dans Google Cloud Console, accédez à Monitoring.
- Dans le volet de navigation "Monitoring", sélectionnez notifications Alertes, puis Créer une règle.
- Cliquez sur Ajouter une condition :
- Les paramètres du volet Cible permettent de spécifier la ressource et la métrique à surveiller. Cliquez sur la zone de texte pour activer un menu, puis sélectionnez la ressource Règle d'équilibrage de charge HTTP/S Google Cloud. Sélectionnez ensuite une métrique dans la liste.
- Les paramètres du volet Configuration de la règle d'alerte déterminent le moment où l'alerte se déclenche. La plupart des champs de ce volet sont renseignés avec des valeurs par défaut. Pour en savoir plus sur les champs du volet, consultez la section Configuration dans la documentation sur les règles d'alerte.
- Cliquez sur Ajouter.
- Pour accéder à la section "Notifications", cliquez sur Suivant.
- Facultatif : Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.
Si un canal de notification que vous souhaitez ajouter n'est pas répertorié, cliquez sur Gérer les canaux de notification. La page Canaux de notification s'affiche dans un nouvel onglet du navigateur. Sur cette page, vous pouvez mettre à jour les canaux de notification configurés. Une fois vos mises à jour effectuées, revenez à l'onglet d'origine, cliquez sur Actualiser autorenew, puis sélectionnez les canaux de notification à ajouter à la règle d'alerte.
- Pour accéder à la section "Documentation", cliquez sur Suivant.
- Cliquez sur Nom et saisissez un nom pour la règle d'alerte.
- Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
- Cliquez sur Enregistrer.
Définir des tableaux de bord personnalisés Cloud Monitoring
Vous pouvez créer des tableaux de bord personnalisés Cloud Monitoring pour les métriques d'équilibrage de charge HTTP(S) :
- Accédez à Monitoring dans Google Cloud Console.
Accéder à Monitoring - Sélectionnez Tableaux de bord > Créer un tableau de bord.
- Cliquez sur Add Chart (Ajouter un graphique).
- Indiquez un titre pour le graphique.
- Sélectionnez des métriques et des filtres. Pour les métriques, le type de ressource est Équilibreur de charge HTTP Cloud.
- Cliquez sur Enregistrer.
Fréquence et conservation des rapports sur les métriques
Les métriques des équilibreurs de charge HTTP(S) 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 pour les équilibreurs de charge HTTP(S) externes
Les métriques suivantes pour les équilibreurs de charge HTTP(S) externes sont consignées dans Cloud Monitoring :
| Métrique | Nom | Description |
|---|---|---|
| Nombre de requêtes | https/request_count |
Nombre de requêtes diffusées par l'équilibreur de charge HTTP(S) 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 HTTP(S) externe |
| Nombre d'octets de réponse | https/response_bytes_count |
Nombre d'octets envoyés en tant que réponses par l'équilibreur de charge HTTP(S) externe aux clients |
| Total des latences | https/total_latencies |
Distribution de la latence. La latence est mesurée entre le moment où le service GFE reçoit le premier octet de la requête et le moment où il reçoit de la part du client demandeur l'accusé de réception du dernier octet de la 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 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 Cloud Monitoring.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 :
|
| DAR d'interface(*) | https/frontend_tcp_rtt |
Distribution du DAR lissé mesurée pour chaque connexion entre le client et le GFE (mesurée par la pile TCP du GFE). |
| 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. |
| Fraction par classe de code de réponse | Fraction du total des réponses de l'équilibreur de charge HTTP(S) 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 HTTP(S) 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 HTTP(S) 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 à l'équilibreur de charge HTTP(S) 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.
Dimensions de filtrage pour les métriques d'équilibreur de charge HTTP(S) externe
Les métriques sont agrégées pour chaque équilibreur de charge HTTP(S) externe. Vous pouvez filtrer les métriques agrégées selon les dimensions suivantes(*) :
| Valeur | 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.
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 Google Cloud du groupe d'instances ayant diffusé la requête du client. (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 Google Cloud du groupe d'instances ayant diffusé la requête du client. (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 GFE HTTP(S) ayant mis fin à la connexion HTTP(S) de l'utilisateur.
Exemples : America, Europe, Asia. |
| INSTANCE GROUP | Nom du groupe d'instances ayant diffusé la requête du client. 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.
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 ayant diffusé la requête du client. |
| MATCHED URL 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 | 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
- Consultez les informations conceptuelles sur l'équilibrage de charge HTTP(S).
- Créez un équilibreur de charge HTTP(S) externe basé sur le contenu et interrégional.
- Ajoutez un bucket backend à un équilibreur de charge basé sur le contenu.
- En savoir plus sur les règles de transfert.
- Approfondissez la configuration des mappages d'URL et consultez les informations conceptuelles sur les mappages d'URL
- Configurez les certificats SSL.
- Créez des règles SSL.