Résoudre des problèmes d'observabilité

Cette page explique comment résoudre les problèmes sur les pages Anthos Service Mesh de la console Google Cloud.

Un service spécifique est manquant dans la liste des services

Si un service ne figure pas dans la liste, vérifiez qu'une configuration de service Kubernetes existe dans votre cluster.

Pour obtenir la liste de tous les services Kubernetes :

 kubectl get services --all-namespaces

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

kubectl get services -n YOUR_NAMESPACE

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 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 la console Google Cloud 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 les éléments suivants :

Vérification que les proxys side-car ont été injectés

Vérifiez que tous les pods de l'espace de noms des services de votre application ont bien reçu des proxys side-car :

kubectl get pod -n YOUR_NAMESPACE --all

Dans l'exemple de résultat suivant de la commande précédente, la colonne READY indique qu'il existe deux conteneurs pour chacune des charges de travail : le conteneur principal et le conteneur du proxy side-car.

NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...

Si vous ne voyez pas deux conteneurs, vérifiez si votre espace de noms comporte le libellé istio-injection=enabled, ce qui indique que l'injection side-car automatique est activée :

  kubectl get ns --show-labels

Exemple de résultat :

NAME              STATUS   AGE   LABELS
default           Active   35m   istio-injection=enabled
istio-system      Active   34m   istio-injection=disabled,istio-operator-managed=Reconcile

Si vous ne voyez pas le libellé istio-injection=enabled, exécutez la commande suivante pour activer l'injection side-car automatique :
```
kubectl label namespace YOUR_NAMESPACE istio-injection=enabled --overwrite
```
Si vous voyez le libellé istio-injection=enabled et que vous avez installé Anthos Service Mesh sur un cluster Google Kubernetes Engine existant comportant des charges de travail, vous devez redémarrer tous les pods en cours d'exécution pour que le proxy side-car soit injecté ou mis à jour avec la version actuelle d'Anthos Service Mesh. Pour en savoir plus, consultez la section Mettre à jour des side-cars pour les pods existants.

Vérification des noms des ports du service Kubernetes

Vérifiez les noms de port du service Kubernetes pour vérifier qu'Anthos Service Mesh considère le service comme un service HTTP. Pour être inclus dans Anthos Service Mesh, les ports de service doivent être nommés et le nom doit inclure le protocole du port, par exemple :

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

Le nom du port de service peut inclure un suffixe dans la syntaxe suivante : name: protocol[-suffix], où les crochets indiquent un suffixe facultatif qui doit commencer par un tiret, par exemple :

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

Pour que les métriques soient affichées dans la console Google Cloud, les ports de service doivent être nommés avec l'un des protocoles suivants: http, http2 ou grpc. Les ports de service nommés avec le protocole https sont traités comme tcp, et les métriques ne sont pas affichées pour ces services.

Vérification que les API requises sont activées

Anthos Service Mesh nécessite plusieurs API pour la création de rapports et l'affichage de la télémétrie. Vous pouvez voir quelles API sont activées pour votre projet à l'aide de la commande gcloud services list ou simplement activer toutes les API requises pour vous assurer que vous les obtenez.

Définissez le projet par défaut pour la Google Cloud CLI :
```
gcloud config set project YOUR_PROJECT_ID
```

Activez toutes les API requises :

gcloud services enable \
   container.googleapis.com \
   compute.googleapis.com \
   monitoring.googleapis.com \
   logging.googleapis.com \
   meshca.googleapis.com \
   meshtelemetry.googleapis.com \
   meshconfig.googleapis.com \
   iamcredentials.googleapis.com \
   anthos.googleapis.com \
   gkeconnect.googleapis.com \
   gkehub.googleapis.com \
   cloudresourcemanager.googleapis.com

Vérification que le compte de service du plan de données ASM maillé existe

Dans la console Google Cloud, ouvrez la page IAM:

Ouvrir la page IAM
Sélectionnez votre projet.
Dans la liste des membres, recherchez un compte de service nommé Compte de service du plan de données ASM.

Si le compte de service est manquant, créez-le :

curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  https://meshconfig.googleapis.com/v1alpha1/projects/YOUR_PROJECT_ID:initialize

Vérification de l'exécution de vos charges de travail

Dans la console Google Cloud, ouvrez la page Charges de travail GKE:

Ouvrir les charges de travail GKE
Sélectionnez votre projet.
Ajoutez un filtre pour votre cluster. Vérifiez que toutes les charges de travail de votre application et d'Anthos Service Mesh fonctionnent correctement avec l'état indiquant OK. Une charge de travail peut échouer en raison de ressources limitées (processeur, mémoire, etc.). Dans ce cas, vous devez mettre à niveau votre cluster avec davantage de ressources. Pour en savoir plus, consultez la page Redimensionner un cluster.

Vérification que votre application diffuse des requêtes

Vérifiez que votre application diffuse des requêtes. Le nombre de RPS peut être faible, mais il doit recevoir du trafic.

Le graphique de topologie est vide

Si le graphique de topologie n'affiche pas vos services et affiche le message d'erreur No data available to graph. Check your filters and try again, vérifiez les éléments suivants :

Vérification de l'ID de réseau maillé

Vérifiez que le cluster dispose du libellé mesh_id approprié :

Obtenez le numéro de projet, qui est un numéro unique généré automatiquement lors de la création de votre projet.
Assurez-vous que le cluster possède un libellé mesh_id au format suivant : mesh_id: proj-PROJECT_NUMBER.

Corrigez le libellé mesh_id s'il est manquant ou incorrect. Pour en savoir plus, consultez la section Ajouter ou mettre à jour des libellés pour des clusters existants.
Définissez les variables d'environnement suivantes :
- Définissez le nom du cluster :
```
export CLUSTER_NAME=YOUR_CLUSTER_NAME
```
- Définissez le paramètre CLUSTER_LOCATION sur la zone ou la région de votre cluster :
```
export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
```
Redéployez Anthos Service Mesh avec les mêmes options que celles utilisées précédemment.
Toutes les charges de travail exécutées sur votre cluster avant l'installation d'Anthos Service Mesh doivent mettre à jour le proxy side-car de sorte qu'elles disposent de la version actuelle d'Anthos Service Mesh.
```
kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE
```