Vous consultez la documentation d'Anthos Service Mesh 1.7. Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Résoudre les problèmes d'observabilité et de télémétrie dans Anthos Service Mesh

Cette section explique les problèmes couramment rencontrés dans Anthos Service Mesh et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Dans la télémétrie d'Anthos Service Mesh, les proxys Envoy appellent régulièrement les API de la suite des opérations Google Cloud pour générer des rapports de données de télémétrie. Le type d'appel d'API détermine sa fréquence :

  • Journalisation : environ toutes les 10 secondes
  • Métriques : environ toutes les minutes
  • Périphéries (vue Topologie/API Context) : rapports incrémentiels environ toutes les minutes, avec des rapports complets toutes les 10 minutes environ
  • Traces : déterminée par la fréquence d'échantillonnage que vous configurez (généralement une requête sur 100)

Les tableaux de bord de télémétrie collectent des données issues de Confluence et de la suite des opérations Google Cloud pour afficher les différents tableaux de bord axés sur les services.

Service manquant dans le tableau de bord des services

Le tableau de bord n'affiche que les services HTTP(S)/gRPC. Si votre service doit figurer dans la liste, vérifiez que la télémétrie d'Anthos Service Mesh l'identifie en tant que service HTTP.

Si votre service est toujours manquant, vérifiez qu'une configuration de service Kubernetes {: class="external"} existe dans votre cluster.

Consultez la liste de tous les services Kubernetes :

kubectl get services --all-namespaces

Consultez la liste des services Kubernetes dans un espace de noms spécifique :

kubectl get services -n YOUR_NAMESPACE

Métriques manquantes ou incorrectes pour les services

S'il y a des métriques manquantes ou incorrectes pour les services dans le tableau de bord, consultez les sections suivantes pour connaître les résolutions potentielles.

Vérifier que les proxys side-car existent et ont été injectés correctement

Il est possible que l'espace de noms n'ait pas de libellé pour l'injection automatique ou que l'injection manuelle ait échoué. Vérifiez que les pods de l'espace de noms comportent au moins deux conteneurs et que l'un d'entre eux est le conteneur istio-proxy :

kubectl -n YOUR_NAMESPACE get pods

Vérifier que la configuration de la télémétrie existe

Utilisez EnvoyFilters dans l'espace de noms istio-system pour configurer la télémétrie. Sans cette configuration, Anthos Service Mesh ne fournira aucune donnée à la suite des opérations Google Cloud.

Vérifiez que la configuration de la suite des opérations Google Cloud (et la configuration de l'échange de métadonnées) existe :

kubectl -n istio-system get envoyfilter

Le résultat attendu ressemble à ce qui suit :

NAME                        AGE
metadata-exchange-1.4       13d
metadata-exchange-1.5       13d
stackdriver-filter-1.4      13d
stackdriver-filter-1.5      13d
...

Pour confirmer que le filtre de la suite des opérations Google Cloud est correctement configuré, récupérez un vidage de configuration à partir de chaque proxy et recherchez la présence du filtre de la suite des opérations Google Cloud :

kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump

Dans le résultat de la commande précédente, recherchez le filtre de la suite des opérations Google Cloud, qui se présente comme suit :

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Vérifier qu'Anthos Service Mesh identifie un service HTTP

Les métriques n'apparaissent pas dans l'interface utilisateur si le port du service Kubernetes n'est pas nommé avec un préfixe http. Vérifiez que le service dispose des noms appropriés pour ses ports.

Vérifier que l'API Cloud Monitoring est activée pour le projet

Vérifiez que l'API Cloud Monitoring est activée dans le tableau de bord "API et services" de Google Cloud Console, ce qui est la valeur par défaut.

Vérifier qu'aucune erreur n'est signalée à l'API Cloud Monitoring

Dans le tableau de bord "API et services" de Google Cloud Console, ouvrez le graphique "Trafic par code de réponse".

Si des messages d'erreur s'affichent, un examen plus approfondi peut être nécessaire. Par exemple, recherchez un grand nombre de messages d'erreur 429, ce qui indique un problème potentiel de quota. Consultez la section suivante pour connaître les étapes de dépannage.

Vérifier le quota correct pour l'API Cloud Monitoring

Dans Google Cloud Console, ouvrez le menu IAM & Admin et vérifiez qu'il existe une option Quotas. Vous pouvez accéder à cette page directement à l'aide de l'URL :

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

Cette page présente l'ensemble complet des quotas du projet, où vous pouvez rechercher Cloud Monitoring API.

Vérifier qu'aucun journal d'erreurs n'apparaît dans les proxys Envoy

Examinez les journaux du proxy en question pour rechercher les instances de message d'erreur :

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Vous pouvez toutefois ignorer les messages d'avertissement suivants, qui sont normaux :

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

Données de télémétrie absentes ou incorrectes pour les services

Par défaut, Cloud Monitoring et Cloud Logging sont activés dans votre projet sur le cloud lorsque vous installez Anthos Service Mesh. Pour signaler des données de télémétrie, chaque proxy side-car injecté dans vos pods de service appelle l'API Cloud Monitoring et l'API Cloud Logging. Après le déploiement des charges de travail, l'affichage des données de télémétrie dans Cloud Console prend une à deux minutes environ pour apparaître. Anthos Service Mesh met à jour automatiquement les tableaux de bord du service :

  • Pour les métriques, les proxys side-car appellent l'API Cloud Monitoring toutes les minutes environ.
  • Pour mettre à jour le graphique Topologie, les proxys side-car envoient des rapports incrémentiels toutes les minutes environ et des rapports complets toutes les dix minutes environ.
  • Pour la journalisation, les proxys side-car appellent l'API Cloud Logging toutes les dix secondes environ.
  • Pour le traçage, vous devez activer Cloud Trace. Les traces sont enregistrées en fonction de la fréquence d'échantillonnage que vous avez configurée (généralement une requête sur 100).

Les métriques ne sont affichées que pour les services HTTP sur la page Métriques d'Anthos Service Mesh. Si vous ne voyez aucune métrique, vérifiez que tous les pods de l'espace de noms des services de votre application ont des proxys side-car injectés :

kubectl get pod -n YOUR_NAMESPACE --all

Dans le résultat, notez que la colonne READY affiche deux conteneurs pour chacune de vos charges de travail : le conteneur principal et le conteneur du proxy side-car.