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

Cette section décrit les problèmes courants liés à Cloud Service Mesh et explique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.

Dans la télémétrie Cloud Service Mesh, les proxys Envoy appellent régulièrement les API Google Cloud Observability pour signaler les 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
• Edges (API Context/Vue de la topologie): rapports incrémentiels toutes les 1 minute environ, avec des rapports complets toutes les 10 minutes environ.
• Traces: déterminées par la fréquence d'échantillonnage que vous configurez (généralement une requête sur 100).

Important :La télémétrie complète peut être retardée d'une à deux minutes lors du démarrage des clusters.

Les tableaux de bord de télémétrie collectent des données de Confluence et de l'observabilité Google Cloud pour afficher les différents tableaux de bord axés sur les services.

Vérifier qu'il existe au maximum une configuration d'API de télémétrie d'Istio

Cette section ne s'applique qu'au plan de contrôle Cloud Service Mesh géré.

Remarque :Cloud Service Mesh avec un plan de contrôle Cloud Service Mesh géré n'est compatible qu'avec une configuration d'API de télémétrie à l'échelle du cluster, plus précisément, une seule RS d'API de télémétrie Istio dans l'espace de noms racine. Ne déployez pas plusieurs RS de l'API de télémétrie d'Istio dans un cluster. Si vous déployez plusieurs RS d'API de télémétrie d'Istio dans un cluster, seule la première prend effet. Si vous disposez déjà d'une RS d'API de télémétrie Istio existante, pour conserver vos paramètres de personnalisation précédents dans votre RS de télémétrie existante, vous devez les inclure dans votre nouvelle RS pour l'API de télémétrie Istio.

Pour répertorier les configurations de l'API de télémétrie, exécutez la commande suivante. Vérifiez qu'il existe au maximum une configuration d'API de télémétrie d'Istio.

kubectl -n istio-system get telemetry

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 Cloud Service Mesh l'identifie en tant que service HTTP.

Si votre service est toujours manquant, vérifiez qu'une configuration de service Kubernetes 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 des services, consultez les sections suivantes pour connaître les solutions potentielles.

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

Remarque :Vous devez avoir accès au cluster pour résoudre les problèmes de métriques manquantes ou incorrectes.

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 disposent d'au moins deux conteneurs et que l'un de ces conteneurs est le conteneur istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

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

Pour vérifier que le filtre d'observabilité Google Cloud est configuré, rassemblez un fichier de vidage de configuration à partir de chaque proxy et recherchez la présence du filtre d'observabilité Google Cloud:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

Dans le résultat de la commande précédente, recherchez le filtre d'observabilité 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 que Cloud Service Mesh identifie un service HTTP

Les métriques ne s'affichent pas dans l'interface utilisateur si le port de service du service Kubernetes n'est pas nommé http ou n'est pas nommé http-. Vérifiez que le service possède les noms corrects 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 la console Google Cloud, ouvrez l'URL du graphique "Trafic par code de réponse" :

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

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 la console Google Cloud, ouvrez le menu IAM & Admin et vérifiez qu'il existe l'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

Vérifier que metric.mesh_uid est correctement défini

Ouvrez l'explorateur de métriques et exécutez la requête MQL suivante:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

Vérifiez que tous les services attendus génèrent des rapports sur les métriques et que leur metric.mesh_uid est au format proj-<Cloud Service Mesh fleet project number>.

Remarque :Pour les maillages multiprojets, le numéro de projet doit correspondre au projet du parc et non au projet hôte.

Si metric.mesh_uid a une autre valeur, le tableau de bord Cloud Service Mesh n'affiche pas les métriques. metric.mesh_uid est défini lorsque Cloud Service Mesh est installé sur le cluster. Examinez votre méthode d'installation pour voir s'il est possible de la définir sur la valeur attendue.

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

Par défaut, Cloud Monitoring et Cloud Logging sont activés dans votre projet Google Cloud lorsque vous installez Cloud 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 la console Google Cloud prend une à deux minutes environ pour apparaître. Cloud Service Mesh maintient automatiquement les tableaux de bord de service à jour:

• 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" de Cloud Service Mesh. Si vous ne voyez aucune métrique, vérifiez que des proxys side-car sont injectés dans tous les pods de l'espace de noms pour les services de votre application:

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.

De plus, le tableau de bord des services n'affiche que les métriques du serveur. Par conséquent, les données de télémétrie peuvent ne pas s'afficher si le client ne fait pas partie du maillage ou s'il est configuré pour ne transmettre que les métriques client (telles que les passerelles d'entrée).