Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Résoudre les problèmes liés aux équilibreurs de charge d'application externes

Ce guide explique comment résoudre les problèmes de configuration des équilibreurs de charge d'application externes. Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes.

Présentation de l'équilibreur de charge d'application externe
Journalisation et surveillance de l'équilibreur de charge d'application global et classique
Journalisation et surveillance de l'équilibreur de charge d'application externe régional

Résoudre les problèmes courants liés à Network Analyzer

Network Analyzer surveille automatiquement la configuration de votre réseau VPC et détecte les configurations non optimales ainsi que les erreurs de configuration. Il identifie les défaillances du réseau, fournit des informations sur l'origine des problèmes et suggère des solutions possibles. Pour en savoir plus sur les différents scénarios de configuration erronée qui sont automatiquement détectés par Network Analyzer, consultez la section Insights sur l'équilibreur de charge dans la documentation de Network Analyzer.

Network Analyzer est disponible dans la console Google Cloud dans le cadre de Network Intelligence Center.

Accéder à l'Analyse du réseau

Incompatibilité des modes d'équilibrage des backends

Lors de la création d'un équilibreur de charge, le message d'erreur suivant peut s'afficher :

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Cette erreur se produit lorsque vous essayez d'utiliser le même backend dans deux équilibreurs de charge différents et que les backends ne disposent pas de modes d'équilibrage compatibles.

Pour en savoir plus, consultez les ressources suivantes :

Résoudre les problèmes de connectivité générale

Erreurs "5XX" inexpliquées

Une erreur "HTTP 5XX" peut être renvoyée par un GFE de première couche, un GFE de deuxième couche ou un backend, selon l'endroit où la condition d'erreur se produit.

Cette section explique comment résoudre les erreurs 5XX qui peuvent se produire à différentes étapes du processus de distribution des requêtes pour les équilibreurs de charge d'application externes basés sur GFE.

Identifier la source des erreurs "5XX" à l'aide de Cloud Logging

Pour les conditions d'erreur causées par un problème de communication entre le proxy de l'équilibreur de charge et ses backends, l'équilibreur de charge génère un code de réponse d'erreur HTTP (5XX) et renvoie ce code de réponse d'erreur au client. Les erreurs HTTP 5XX ne sont pas toutes générées par l'équilibreur de charge. Par exemple, si un backend envoie une réponse HTTP 5XX à l'équilibreur de charge, celui-ci va simplement retransmettre cette réponse à son client.

Pour déterminer si une réponse HTTP 5XX a été relayée depuis un backend ou si elle a été générée par le proxy de l'équilibreur de charge, vérifiez le champ statusDetails dans Cloud Logging.

Si statusDetails est défini sur response_sent_by_backend, l'équilibreur de charge a relayé la réponse 5XX du backend. Résolvez le problème sur vos backends.
Si statusDetails est un autre message d'échec, la réponse 5XX est générée par l'équilibreur de charge.

Les modifications de configuration de l'équilibreur de charge d'application externe global, telles que l'ajout ou la suppression d'un service de backend, peuvent entraîner une brève période pendant laquelle vous êtes confronté à des réponses HTTP 502 avec statusDetails comme failed_to_pick_backend. Ce comportement est normal lors de la propagation des modifications de configuration aux GFE dans le monde entier.

Avant de commencer le dépannage, vérifiez l'état du backend

Avant de résoudre les erreurs 5XX, vérifiez que vos backends sont opérationnels et que les vérifications de l'état réussissent. Si les backends ne sont pas opérationnels, le GFE de deuxième couche ne peut pas leur transférer de requêtes, ce qui peut entraîner des erreurs 5XX même si tout le reste est correctement configuré.

Vérifiez qu'une règle de pare-feu est configurée pour autoriser les vérifications d'état. En l'absence d'une telle règle, les vérifications de l'état échouent et les journaux de l'équilibreur de charge peuvent afficher un champ statusDetails avec la valeur failed_to_pick_backend.
Vérifier que le trafic de vérification de l'état atteint vos VM de backend. Pour ce faire, activez la journalisation des vérifications d'état et recherchez les entrées de journal ayant réussi. Pour les nouveaux équilibreurs de charge, il est possible que vous ne voyiez pas immédiatement d'entrées de journal de vérification de l'état réussies. Cela peut signifier que l'état initial du backend n'est pas encore passé de UNHEALTHY à un autre état. Les entrées de journal de vérification d'état réussies ne s'affichent qu'une fois que le vérificateur d'état a reçu une réponse HTTP 200 OK du backend.

Si les vérifications de l'état échouent, résolvez les problèmes liés à votre application de backend et à vos règles de pare-feu. Si les vérifications de l'état réussissent, mais que vous continuez à voir des erreurs 5XX, vérifiez le champ statusDetails dans Cloud Logging pour identifier la source de l'erreur, comme décrit dans la section suivante.

Résoudre les erreurs en fonction de `statusDetails`

Si les erreurs HTTP 5XX persistent, utilisez le champ statusDetails dans Cloud Logging pour identifier la cause et résoudre le problème en conséquence.

L'équilibreur de charge d'application externe global et l'équilibreur de charge d'application externe régional génèrent des codes d'état HTTP significatifs, tels que HTTP 503 (Service indisponible) et HTTP 504 (Expiration du délai de la passerelle).
L'équilibreur de charge d'application classique utilise toujours le code d'état HTTP 502 "Bad Gateway" pour toutes les erreurs générées par l'équilibreur de charge.

statusDetails	Cause et solution possibles
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Cause : le GFE de deuxième couche n'a pas pu sélectionner de backend opérationnel pour acheminer la requête. Cette erreur peut se produire pour l'une des raisons suivantes : Toutes les régions sont à leur capacité maximale ou au-dessus. L'équilibreur de charge ne trouve aucun backend disponible en fonction du hachage calculé. L'équilibreur de charge ne trouve aucun backend correspondant à la configuration de service. Solution : Vérifiez que vos backends sont opérationnels en suivant les étapes décrites dans Vérifier l'état du backend. Assurez-vous que les vérifications d'état sont correctement configurées avec le bon port, le bon chemin d'accès et le bon protocole. Assurez-vous que les règles de pare-feu de backend autorisent le trafic de vérification de l'état de l'état provenant des vérification de l'état d'état : `35.191.0.0/16`. Si certains de vos groupes d'instances backend sont défectueux, notez que le basculement ou le débordement est limité à un nombre limité de groupes d'instances alternatifs. Si vous observez `failed_to_pick_backend` ou `failed_to_pick_backend_by_hash` alors que vos groupes d'instances sont en bon état, videz les groupes d'instances défectueux en définissant leur capacité sur zéro. Cela force l'équilibreur de charge à transférer le trafic vers les groupes d'instances opérationnels.
`failed_to_connect_to_backend`	Cause : le GFE de deuxième couche n'a pas réussi à établir une connexion avec une instance de backend (SYN-ACK non reçu). Cette erreur peut également être due à une erreur interne du GFE qui l'empêche de se connecter au backend, ou à une panne régionale ou à une perturbation du réseau (par exemple, une coupure de fibre optique) qui empêche les GFE de première couche de communiquer avec les GFE de deuxième couche. Solution : Vérifiez que les règles de pare-feu de vos VM de backend ou de votre réseau VPC autorisent le trafic vers vos backends à partir des plages GFE de deuxième couche : , `35.191.0.0/16` et. Vérifiez que l'application sur vos instances de backend est en cours d'exécution et qu'elle écoute le port configuré dans le service de backend. Vérifiez les métriques d'instance backend (CPU, mémoire, connexions) pour détecter des signes d'épuisement des ressources.
`backend_connection_closed_before_data_sent_to_client`	Cause : la connexion entre le GFE de deuxième couche et le backend a été fermée de manière inattendue avant que la réponse puisse être envoyée au client. Ce problème peut être dû au serveur Web de backend ou à un appareil intermédiaire. Cela peut également se produire lorsque vous utilisez GKE si les pods sont en cours de réduction ou d'arrêt, et que les backends de l'équilibreur de charge sont de type NEG. Solution : Définissez le délai d'expiration du message keepalive HTTP sur le serveur Web de backend (comme Apache ou Nginx) sur une valeur supérieure au délai d'expiration de 600 secondes de l'équilibreur de charge. La valeur recommandée est de 620 secondes. Si vous utilisez GKE, cela se produit lorsque les pods sont en cours de scaling à la baisse ou d'arrêt, et que les backends de l'équilibreur de charge sont des NEG. Pour résoudre ce problème, envisagez d'augmenter `terminationGracePeriodSeconds` dans la configuration de votre pod ou de votre déploiement afin de permettre aux connexions existantes de se fermer correctement. La valeur idéale est la suivante : `T_grace > T_preStop + T_drain + T_buffer` Où : `T_preStop` correspond à la durée de veille du hook `preStop` du conteneur, qui est généralement de 120 secondes pour permettre au point de terminaison d'être supprimé du NEG. `T_drain` correspond au délai avant expiration du drainage de connexion du service de backend, qui est généralement de 60 secondes. `T_buffer` est une marge supplémentaire de 30 à 45 secondes pour permettre au pod de s'éteindre en toute sécurité. Pour les configurations standards, la valeur recommandée est d'au moins 210 secondes (3,5 minutes). Consultez les journaux de l'application backend pour détecter les erreurs susceptibles d'entraîner la fermeture de la connexion. Vérifiez les métriques d'instance backend (CPU, mémoire, connexions) pour détecter des signes d'épuisement des ressources.
`backend_timeout`	Cause : le GFE de deuxième couche a établi une connexion avec le backend, mais celui-ci n'a pas envoyé de réponse dans le délai avant expiration du service de backend configuré. Solution : Si votre application a besoin de plus de temps pour traiter les requêtes, augmentez le délai avant expiration du service de backend. Recherchez les problèmes de performances sur vos instances de backend (CPU, E/S, délais d'application) qui pourraient empêcher une réponse rapide. Si les backends sont surchargés, envisagez de mettre à l'échelle les ressources de backend ou d'optimiser l'application.
`retriable_error`	Cause : cette erreur 503 peut se produire si des outils d'infrastructure en tant que code (comme Terraform) mettent à jour les règles de l'équilibreur de charge de manière à supprimer temporairement les règles du mappage d'URL avant de les ajouter à nouveau, ou en raison de problèmes de configuration ou de réseau Google internes et temporaires lors des déploiements ou des transmissions de configuration. Solution : Si vous utilisez l'automatisation, vérifiez qu'elle effectue des mises à jour sur place plutôt que des mises à jour de type "supprimer, puis créer" pour les règles de mappage d'URL. Si cette erreur s'affiche pendant ou après une modification de la configuration, elle peut être temporaire. Attendez quelques minutes que la configuration se propage à l'échelle mondiale.

Résoudre les erreurs HTTP `408`

Avec le trafic HTTP, la durée maximale pour que le client termine d'envoyer sa requête est égale au délai avant expiration du service de backend. Si des réponses HTTP 408 avec jsonPayload.statusDetail client_timed_out apparaissent, cela signifie que la progression était insuffisante lors de l'envoi par proxy de la requête du client ou de la réponse du backend. Si le problème est dû à des clients rencontrant des problèmes de performances, vous pouvez résoudre ce problème en augmentant le délai avant expiration du service de backend.

Le trafic à équilibrage de charge n'a pas l'adresse source du client d'origine

Les adresses IP sources des paquets, telles qu'elles sont perçues par les backends, ne correspondent pas à l'adresse IP externe de l'équilibreur de charge. Les équilibreurs de charge basés sur un proxy, tels que les équilibreurs de charge d'application externes, utilisent deux connexions TCP pour transmettre le trafic du client aux backends :

Connexion 1, du client d'origine vers l'équilibreur de charge (GFE ou sous-réseau proxy réservé)
Connexion 2, de l'équilibreur de charge (GFE ou sous-réseau proxy réservé) vers la VM de backend ou le point de terminaison

Les adresses IP source et de destination de chaque connexion diffèrent en fonction du type d'équilibreur de charge d'application externe que vous utilisez. Pour plus d'informations, consultez la section Adresses IP sources pour les paquets clients.

Obtention d'une erreur d'autorisation lors de la tentative d'affichage d'un objet dans votre bucket Cloud Storage

Pour que des objets Cloud Storage puissent être diffusés via l'équilibrage de charge, ils doivent être accessibles publiquement. Veillez à mettre à jour les autorisations des objets diffusés pour les rendre lisibles publiquement.

L'URL ne diffuse pas l'objet Cloud Storage attendu

L'objet Cloud Storage à diffuser est déterminé en fonction de votre mappage d'URL et de l'URL demandée. Si le chemin de la requête correspond à un bucket backend dans votre mappage d'URL, l'objet Cloud Storage est déterminé en ajoutant le chemin de requête complet au bucket Cloud Storage spécifié par le mappage d'URL.

Par exemple, si vous mappez /static/* avec gs://[EXAMPLE_BUCKET], la requête envoyée à https://<GCLB IP or Host>/static/path/to/content.jpg essaie de diffuser gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Si cet objet n'existe pas, vous obtenez le message d'erreur suivant à la place de l'objet :


NoSuchKey
The specified key does not exist.

La compression ne fonctionne pas

L'équilibreur de charge d'application externe n'effectue pas lui-même la compression et la décompression des réponses, mais il peut diffuser des réponses générées par votre service de backend qui ont été compressées à l'aide d'outils tels que gzip ou DEFLATE.

Si les réponses diffusées par l'équilibreur de charge ne sont pas compressées alors qu'elles doivent l'être, vérifiez que le logiciel serveur Web exécuté sur les instances est configuré pour compresser les réponses. Par défaut, certains logiciels de serveur Web désactivent automatiquement la compression pour les requêtes comportant l'en-tête Via, qui indique que la requête a été transmise par un proxy. Étant donné qu'il s'agit d'un proxy, l'équilibreur de charge d'application externe ajoute un en-tête Via à chaque requête, comme requis par la spécification HTTP. Pour activer la compression, vous devrez peut-être remplacer la configuration par défaut de votre serveur Web pour lui indiquer de compresser les réponses même si la requête comporte un en-tête Via.

Pour configurer les backends nginx afin de diffuser des réponses compressées mises en proxy via un équilibreur de charge d'application externe, procédez comme suit :

Définissez l'instruction gzip_proxied de manière appropriée (par exemple, sur any) et
Définissez l'instruction gzip_vary sur on.

Pour configurer les backends Apache afin de diffuser des réponses compressées mises en proxy via un équilibreur de charge d'application externe, procédez comme suit :

Utilisez le filtre DEFLATE et
Ajoutez Vary Accept-Encoding à l'en-tête de réponse à l'aide du module mod_headers.

Résoudre les problèmes de backends non opérationnels

Résoudre les problèmes liés à l'utilisation de HTTP/2 avec les backends

Assurez-vous que votre instance backend est opérationnelle et accepte le protocole HTTP/2. Pour ce faire, testez la connectivité à cette instance à l'aide de HTTP/2. Assurez-vous que la VM utilise des suites de chiffrement conformes à la spécification HTTP/2. Par exemple, certaines suites de chiffrement TLS 1.2 ne sont pas autorisées par HTTP/2. Consultez la liste noire des suites de chiffrement TLS 1.2.

Une fois que vous avez vérifié que la VM utilise le protocole HTTP/2, assurez-vous que la configuration de votre pare-feu autorise la passage par le vérificateur d'état et l'équilibreur de charge.

Si la configuration du pare-feu ne présente aucun problème, assurez-vous que l'équilibreur de charge est configuré pour communiquer avec le bon port sur la VM.

Résoudre les problèmes liés à gRPC

Si vous utilisez le streaming gRPC bidirectionnel et que le client se connecte à un équilibreur de charge d'application externe global, le serveur de backend peut se bloquer si un client effectue une fermeture à moitié immédiate (envoie un indicateur END_STREAM immédiatement après la création du flux sans envoyer de données). Cela se produit en raison d'un conflit entre l'optimisation HTTP/2 et les spécifications de cadrage gRPC.

L'équilibreur de charge d'application externe global optimise le trafic HTTP/2 en fusionnant le frame HEADERS et le frame DATA vide (avec END_STREAM) du client en un seul frame HEADERS avec END_STREAM avant de le transférer au backend. Il s'agit d'une optimisation HTTP/2 standard, conformément à la RFC 7540. L'équilibreur de charge fusionne les trames lorsqu'elles arrivent presque simultanément (délai de 0 ms).

Certaines implémentations de serveur gRPC (telles que grpc-go) ne permettent pas de recevoir l'indicateur END_STREAM sur un frame HEADERS, ce qui entraîne une attente indéfinie du backend. La spécification gRPC sur HTTP/2 exige strictement que la fin du flux (EOS) soit indiquée par l'indicateur END_STREAM sur le dernier frame DATA reçu.

Pour éviter ce problème de blocage du serveur backend et de connexion qui reste ouverte jusqu'à ce qu'elle soit fermée de force par le client envoyant un RST_STREAM, vous pouvez appliquer l'une des solutions de contournement suivantes :

Introduisez un petit délai (par exemple, 10 ms ou plus) côté client avant de fermer partiellement le flux. Cela empêche l'équilibreur de charge de fusionner les trames, car la trame HEADERS aurait déjà été transférée.
Assurez-vous que le client envoie au moins un message de données avant de fermer le flux à moitié.
Si possible, passez à un équilibreur de charge d'application externe régional, qui ne fusionne pas le frame HEADERS et un frame DATA vide, et les transfère séparément.

Résoudre les problèmes liés aux NEG Internet et aux backends externes

Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes :

Le trafic n'atteint pas les points de terminaison

Après que vous avez configuré un service, le nouveau point de terminaison devient accessible via l'équilibreur de charge d'application externe lorsque les conditions suivantes sont remplies :

Le point de terminaison est associé au NEG Internet.
Le nom de domaine complet associé peut être correctement résolu par DNS (si vous utilisez le type de point de terminaison FQDN).
Le point de terminaison est accessible sur Internet.

Si le trafic ne peut pas atteindre le point de terminaison, ce qui génère un code d'erreur 502, interrogez l'enregistrement TXT DNS _cloud-eoips.googleusercontent.com à l'aide d'un outil tel que dig ou nslookup. Notez les valeurs CIDR (après ip4:) et vérifiez que ces plages sont autorisées par votre pare-feu ou votre liste de contrôle d'accès (LCA) au cloud.

Après la configuration d'un backend externe, les requêtes adressées au backend externe ont échoué avec une erreur 5xx

Vérifiez Logging.
Vérifiez que le groupe de points de terminaison du réseau est configuré avec la valeur IP:Port ou FQDN:Port correcte pour votre backend externe.
Si vous utilisez le nom de domaine complet, assurez-vous qu'il peut être résolu via le DNS public de Google. Pour ce faire, suivez ces étapes ou utilisez l'interface Web directement.
Si vous n'accédez à l'équilibreur de charge que via son adresse IP externe et que le serveur Web d'origine attend un nom d'hôte, assurez-vous que vous envoyez un en-tête HTTP Host valide à votre backend. Pour ce faire, configurez un en-tête de requête personnalisé.
Si vous communiquez avec un backend via HTTPS ou HTTP2 (tel que défini dans le champ protocol du service de backend) configuré en tant que point de terminaison de backend personnalisé INTERNET_FQDN_PORT, vérifiez que votre origine présente un certificat TLS (SSL) valide et que le nom de domaine complet configuré correspond à un autre nom de l'objet (SAN) dans la liste des SAN des certificats. Un certificat valide est défini comme un certificat signé par une autorité de certification publique et qui n'a pas expiré.
Lorsque vous utilisez des points de terminaison de backend externes INTERNET_FQDN_PORT, les certificats autosignés ne sont pas acceptés par l'équilibreur de charges et sont refusés.
Lorsque vous utilisez HTTPS ou HTTP/2 avec des points de terminaison de type INTERNET_IP_PORT, aucune validation de certificat SSL ni aucune vérification SAN n'est effectuée. Cela signifie que vous pouvez utiliser des certificats autosignés. Lorsque vous utilisez SSL, nous vous recommandons d'utiliser des points de terminaison INTERNET_FQDN_PORT pour vous assurer que les SAN et les certificats de serveur peuvent être validés.

Les réponses de mon backend externe ne sont pas mises en cache par Cloud CDN

Vérifiez les points suivants :

Vous avez défini enableCDN sur "true" afin d'activer Cloud CDN pour le service de backend contenant le NEG qui pointe vers votre backend externe.
Les réponses diffusées par votre backend externe respectent les exigences de mise en cache de Cloud CDN. Par exemple, vous envoyez des en-têtes de réponse Cache-Control: public, max-age=3600 depuis l'origine.

Résoudre les problèmes liés aux NEG sans serveur

Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes :

Les requêtes échouent et renvoient une erreur 404

Vérifiez que la ressource sans serveur sous-jacente (telle qu'un service App Engine, un service Cloud Run Functions ou un service Cloud Run) est toujours en cours d'exécution. Si la ressource sans serveur est supprimée, mais que le NEG sans serveur existe toujours, l'équilibreur de charge d'application externe continue à tenter d'acheminer les requêtes vers le service inexistant. Cela génère une réponse 404.

En général, un équilibreur de charge d'application externe ne peut pas détecter si la ressource sans serveur sous-jacente fonctionne comme prévu. Cela signifie que si votre service dans une région renvoie des erreurs, mais que l'infrastructure Cloud Run, fonctions Cloud Run ou App Engine fonctionne normalement dans votre région, votre équilibreur de charge d'application externe ne redirigera pas automatiquement le trafic dans d'autres régions. Veillez à tester soigneusement les nouvelles versions de vos services avant d'y acheminer le trafic de vos utilisateurs.

Gérer les incohérences entre les masques d'URL

Si l'application du masque d'URL configuré à une URL de requête utilisateur ne renvoie pas de nom de service ou si celui-ci n'existe pas, l'équilibreur de charge peut gérer ces incohérences différemment selon la plate-forme informatique sans serveur utilisée.

Cloud Run : en cas d'incohérence de masque d'URL, l'équilibreur de charge renvoie une erreur HTTP 404 (page introuvable).

Fonctions Cloud Run : en cas d'incohérence de masque d'URL, l'équilibreur de charge renvoie une erreur HTTP 404 (page introuvable).

API Gateway : en cas d'incohérence de masque d'URL, l'équilibreur de charge renvoie une erreur HTTP 404 (page introuvable).

App Engine : en cas d'incohérence de masque d'URL, App Engine utilise le fichier de distribution dispatch.yaml et la logique de routage par défaut d'App Engine pour déterminer le service auquel envoyer la requête.

Résoudre les problèmes d'injection de Google tag gateway

La passerelle de la balise Google n'injecte pas correctement les balises ou provoque des erreurs.

Pour résoudre ce problème, utilisez l'explorateur de journaux de la console Google Cloud afin d'analyser les journaux générés par votre équilibreur de charge. Les problèmes de Google tag gateway n'affectent pas le code de réponse HTTP global ni le statusDetails de la requête de page Web. La réponse HTTP sera envoyée sans modification, même si l'injection de la balise Google échoue. Pour identifier les erreurs de passerelle, vérifiez le grpcStatus de l'exécution du plug-in dans la charge utile JSON de votre équilibreur de charge.

Assurez-vous que Cloud Logging est activé sur les services de backend qui diffusent le contenu du site Web pour les domaines où la passerelle de la balise Google est active. Pour configurer ce paramètre dans la console Google Cloud , accédez à Équilibrage de charge > Modifier > Configuration du backend. Pour en savoir plus, consultez Activer la journalisation sur un service de backend existant. Un taux d'échantillonnage de la journalisation supérieur à 0.0 doit être défini pour ce service de backend.

Dans la console Google Cloud , accédez à la page Explorateur de journaux et sélectionnez le projet approprié.

Accéder à l'explorateur de journaux
Ajustez la période pour couvrir celle où vous pensez que des problèmes se sont produits. Pour en savoir plus, consultez Utiliser le sélecteur de période.
Pour afficher les journaux des requêtes traitées par le plug-in d'injection de la passerelle Google Tag, utilisez la requête suivante :
```
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
```
Remplacez PROJECT_ID par l'ID du projet.
Identifiez les erreurs potentielles en examinant le champ jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Il s'agit de l'état de l'extension Google tag gateway elle-même.
- OK : l'extension a terminé son traitement sans erreur gRPC.
- Toute valeur autre que OK (par exemple, INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED) : indique une erreur lors de l'exécution de l'extension Google tag gateway.

Pour trouver les journaux dans lesquels l'extension Google tag gateway a signalé une erreur, utilisez la requête suivante :

resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

Lorsque la requête précédente renvoie des résultats, examinez l'intégralité de l'entrée de journal pour corréler l'état de l'extension avec le résultat de la requête :
- Échec de l'extension Google tag gateway : un grpcStatus autre que OK (en particulier sur l'événement RESPONSE_BODY) signifie qu'une erreur s'est produite lors du processus d'injection de la balise. Le code gRPC spécifique fournit des indices (par exemple, DEADLINE_EXCEEDED indique un délai avant expiration).
- Impact sur la demande de l'utilisateur : si la valeur grpcStatus de l'extension de passerelle Google Tag n'est pas OK, vérifiez les valeurs httpRequest.status et jsonPayload.statusDetails dans la même entrée de journal. Par exemple, un grpcStatus non-OK combiné à httpRequest.status: 500 et jsonPayload.statusDetails: service_extensions_error suggère que l'échec de l'extension de passerelle de la balise Google a entraîné l'affichage d'une erreur de serveur pour l'utilisateur.
- Fréquence du problème : l'analyse des codes temporels et de la fréquence de ces journaux d'erreurs permet de déterminer si les problèmes d'injection de la passerelle de balise Google sont continus, intermittents ou liés à des événements spécifiques.

Si vous rencontrez des problèmes lors de la configuration que la documentation ne peut pas résoudre, contactez l'assistance Google Ads.

Résoudre les problèmes liés aux équilibreurs de charge d'application externes Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.