Cette page décrit les stratégies de dépannage courantes pour les erreurs Cloud Run. Personalized Service Health publie tous les incidents Cloud Run qui proviennent de l'infrastructure Cloud de Confiance by S3NS sous-jacente pour identifier les interruptions de service Cloud de Confiance by S3NS qui affectent vos projets. Vous devez également envisager de configurer des alertes pour les événements Personalized Service Health. Pour en savoir plus sur les incidents affectant tous les services Cloud de Confiance by S3NS , consultez le tableau de bord Cloud de Confiance by S3NS Service Health.
Consultez les sections suivantes du guide de dépannage Cloud Run pour résoudre les problèmes liés à votre ressource Cloud Run :
Stratégies de dépannage Cloud Run
Les sections suivantes expliquent comment appliquer des stratégies de dépannage générales pour résoudre votre erreur. Si vous continuez à rencontrer des erreurs même après avoir suivi les étapes du guide de dépannage, consultez Étapes suivantes.
Générer des journaux de qualité à l'aide de Cloud Logging
Il est plus facile de résoudre les problèmes liés à votre ressource Cloud Run si vous disposez de bons journaux de débogage. Vous devez écrire les journaux de manière à corréler vos journaux de conteneur avec un journal de requête.
Grâce aux journaux corrélés, vous pouvez identifier la requête qui nécessite une analyse plus approfondie, trouver la trace de la requête et analyser la cause première du problème. Pour en savoir plus sur l'écriture de journaux, consultez Écrire des journaux de conteneur.
Examiner les instances à l'aide de l'explorateur de journaux
Chaque journal de requête dans Cloud Run contient un champ instanceId qui identifie une instance gérant votre requête. En fonction de la valeur de simultanéité que vous spécifiez, une seule instance peut gérer plusieurs requêtes en même temps.
Lorsque plusieurs instances émettent des journaux en même temps, vous devez filtrer vos instances pour identifier les requêtes séquentielles qui ont entraîné le plantage d'une instance.
Filtrer une instance vous permet de déboguer des problèmes de performances spécifiques liés aux démarrages à froid ou à l'augmentation de la latence. Ces problèmes peuvent également être liés à des variables déclarées dans un champ d'application global, lorsque la valeur est réutilisée dans des requêtes simultanées ultérieures. Par exemple, lorsque vous créez un objet global de pool de connexions unique pour l'instance, puis que vous l'utilisez dans plusieurs requêtes.
Pour filtrer une instance spécifique dans l'explorateur de journaux, procédez comme suit :
Dans la console Cloud de Confiance , accédez à la page Explorateur de journaux.
Sélectionnez un projet Cloud de Confiance by S3NS existant en haut de la page ou créez-en un.
Sélectionnez la ressource Révision dans Cloud Run pour un service ou Job Cloud Run pour un job.
Développez une entrée de journal pour filtrer les résultats par instance spécifique.
Cliquez sur la valeur de l'ID d'instance, puis sélectionnez Afficher les entrées correspondantes.
Lorsque vous examinez des instances, vous pouvez utiliser Gemini Cloud Assist Investigations pour obtenir des insights supplémentaires sur vos journaux. Pour en savoir plus sur les différentes façons de lancer une investigation à l'aide de l'explorateur de journaux, consultez Résoudre les problèmes à l'aide des investigations Gemini Cloud Assist dans la documentation Gemini.
Résoudre les latences de requête inattendues
Si vous rencontrez des problèmes de latence, procédez comme suit :
Vérifiez si la latence affecte toutes les requêtes envoyées à votre ressource Cloud Run ou seulement un petit pourcentage. Cloud Run est automatiquement intégré à Cloud Monitoring. Cela ne nécessite aucune installation ni aucune configuration.
Pour afficher les métriques de latence des requêtes individuelles, procédez comme suit :
Dans la console Cloud de Confiance , accédez à la page Cloud Run :
Sélectionnez un service ou un job dans les listes disponibles dans le panneau de navigation de gauche.
Cliquez sur l'onglet MÉTRIQUES pour afficher le tableau de bord Latences des requêtes.
Pour afficher les métriques de latence dans Cloud Monitoring, sélectionnez Cloud Run Revision > Request_latencies > Request latency dans la liste Métriques.
Pour obtenir la liste complète des métriques Cloud Run disponibles et des informations plus détaillées, consultez Cloud de Confiance by S3NS métriques dans Cloud Monitoring.
Identifiez la requête à latence élevée pour comprendre la source de la latence. Vous pouvez utiliser Cloud Trace ou Cloud Logging pour comprendre la durée d'une requête spécifique.
Pour identifier les requêtes à forte latence à l'aide de Cloud Logging, appliquez le filtre
traceSampled=trueafin de corréler les journaux dans Cloud Logging avec les traces dans Cloud Trace. Pour en savoir plus, consultez Intégrer à Cloud Logging.Parfois, des dépendances telles que des requêtes adressées à d'autres services peuvent entraîner des problèmes de latence. Pour identifier ces requêtes, vous devez disposer d'une journalisation explicite les ciblant. Si vous ne générez pas de tels journaux, cela peut apparaître comme un problème de latence provenant d'un service Cloud Run.
De plus, vous devez envisager d'évaluer les pics de latence dans le contexte de la période choisie. L'importance d'un pic est relative. Un pic important dans une petite fenêtre peut être négligeable dans une fenêtre plus grande, et inversement. Par conséquent, la période a un impact significatif sur l'interprétation des données de latence.
Essayez d'augmenter le nombre d'instances minimales pour réduire la latence des requêtes entrantes et éviter les démarrages à froid. Vous devez également envisager de modifier votre code source et d'ajuster les paramètres de scaling pour limiter le nombre de connexions à un service de backend.
Pour en savoir plus, consultez Optimiser les performances.
Résoudre les problèmes de connectivité
Si votre service Cloud Run rencontre des problèmes de connectivité, envisagez d'utiliser les stratégies et outils suivants pour diagnostiquer le problème :
Side-car PCAP : pour une analyse plus approfondie au niveau du réseau, déployez un side-car PCAP à côté de votre service Cloud Run. Ce conteneur side-car effectue une capture de paquets à l'aide de
tcpdumpdans le même espace de noms réseau. Le side-car est dissocié du conteneur d'entrée principal et ne nécessite aucune modification pour effectuer une capture de paquets. Les sidecars utilisent également leurs propres ressources, ce qui empêchetcpdumpd'entrer en concurrence avec les ressources que vous allouez au service principal.Tests de connectivité et intelligence réseau pour les révisions Cloud Run et les fonctions Cloud Run : effectuez des vérifications automatisées sur le chemin réseau entre votre ressource Cloud Run et un point de terminaison. Cela vous aide à identifier les erreurs de configuration qui peuvent bloquer le trafic vers ou depuis votre ressource Cloud Run lorsque vous vous connectez à une instance de VM, à une adresse IP ou à un service géré par Google.
Examinez les journaux de votre ressource Cloud Run : les journaux affichent des messages d'erreur concernant les problèmes de connexion, tels que les échecs, les délais avant expiration ou les connexions refusées. Ces journaux révèlent souvent si le problème de connexion est lié à votre application ou au réseau.
Étapes suivantes
Si vous ne trouvez pas de solution à votre problème dans la documentation Cloud Run, suivez ces étapes :
- Ouvrez une demande d'assistance en contactant Cloud Customer Care.
- Obtenez de l'aide de la communauté en posant des questions sur Stack Overflow ou en recherchant des problèmes similaires à l'aide du tag
google-cloud-run. - Signalez des bugs ou demandez des fonctionnalités à l'aide de l'outil public de suivi des problèmes.