Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Journalisation et surveillance du plan de contrôle

Ce document explique comment utiliser Cloud Logging et Cloud Monitoring pour afficher les journaux et les métriques du plan de contrôle de Cloud Service Mesh.

L'utilisation d'un maillage de services vous permet d'observer le trafic vers et depuis des services. Vous disposez ainsi de données enrichies pour la surveillance et le débogage, sans modifications du code dans le service lui-même. Les entrées de journal peuvent fournir des informations importantes pour résoudre votre problème de maillage de services, y compris des enregistrements de connexions et de déconnexions réussies, des rapports d'erreurs pour les clients mal configurés et des alertes en cas de conflits de ressources de l'API.

Cas d'utilisation

Voici trois cas d'utilisation concernant la journalisation et la surveillance du plan de contrôle :

Cloud Logging pour le plan de contrôle Cloud Service Mesh : vous pouvez stocker, rechercher, analyser et définir des alertes sur toutes vos données et événements de journalisation Cloud Service Mesh en toute sécurité à l'aide de l'ensemble des fonctionnalités intégrées de Logging. Cloud Service Mesh exporte les journaux vers Logging lorsqu'un client Envoy ou gRPC se connecte ou se déconnecte, et lorsqu'il détecte des problèmes de configuration.
Cloud Monitoring pour le plan de contrôle Cloud Service Mesh: Cloud Service Mesh exporte une métrique clé indiquant le nombre de clients. connecté au plan de contrôle Cloud Service Mesh à Monitoring. Vous pouvez configurer un tableau de bord dans Monitoring et visualiser cette métrique en temps réel afin de surveiller l'état du maillage lorsque les clients se connectent et se déconnectent. Cela vous permet également de configurer un SLO pour votre maillage.
Résolvez les problèmes immédiatement: Cloud Service Mesh exporte la télémétrie vers Logging et Monitoring par défaut. Aucune configuration supplémentaire n'est nécessaire pour configurer la journalisation et la surveillance. Vous pouvez ainsi résoudre les problèmes à tout moment, y compris lors de la configuration initiale du maillage.

Voir les journaux

Pour afficher les journaux Cloud Service Mesh, utilisez la Explorateur de journaux : La section suivante présente un exemple de requête permettant d'afficher les journaux Cloud Service Mesh, mais vous pouvez utiliser le lien précédent pour créer votre propre requête.

Dans Google Cloud Console, accédez à la page Explorateur de journaux.

Accéder à l'explorateur de journaux
Dans la liste Ressource,
- Si vous utilisez les API de routage de service, sélectionnez Gateway Scope ou Mesh.
- Si vous utilisez les anciennes API, sélectionnez GCE Network.
Dans la liste Nom du journal, sélectionnez trafficdirector.googleapis.com/events.
Cliquez sur Exécuter la requête.

Champs d'entrées de journal Cloud Service Mesh

Champ	Description
`node_id`	ID du nœud xDS-client, tel que fourni par le client xDS.
`client_type`	Type de client xDS connecté à Cloud Service Mesh. Valeurs possibles : `ENVOY` `GRPC-JAVA` `GRPC-C++` `GRPC-PYTHON` `GRPC-GO` `UNKNOWN`
`node_ip`	Adresse IP du nœud, telle que fournie par le client.
`api_version`	Version de l'API xDS utilisée par les clients xDS pour se connecter à Cloud Service Mesh. Les valeurs possibles sont `V2` et `V3`.
`description`	Description textuelle de l'événement avec des détails supplémentaires.

Exemple d'entrées de journal

Exemple d'entrée de journal	Description
"Cloud Service Mesh n'a trouvé aucune configuration pour le client xDS."	Ce journal est généré lorsque le client xDS est rejeté par Cloud Service Mesh, car aucune configuration n'existe. Cela peut être dû à la configuration incomplète des ressources d'API pertinentes pour Cloud Service Mesh.
"Le client est connecté."	Ce type de message de journal est généré chaque fois qu'un client se connecte avec succès à Cloud Service Mesh.
"Le client a bien été déconnecté."	Ce type de message de journal est généré chaque fois qu'un le client est déconnecté de Cloud Service Mesh.
"La variable de métadonnées TRAFFICDIRECTOR_INTERCEPTION_PORT n'est pas définie. Une configuration de routage pour l'écouteur d'interception existe, mais elle sera ignorée."	Ce type de message de journal est généré lorsque les ressources Cloud Service Mesh sont correctement configurées, mais que la variable `TRAFFICDIRECTOR_INTERCEPTION_PORT` n'est pas définie dans les métadonnées du nœud xDS-client. Vous ne pouvez donc pas ajouter cette configuration au client.
"L'écouteur d'interception est basé sur le port 15001 donné, mais la configuration de routage n'existe pas pour ce port."	Ce type de message de journal est généré lorsque la variable `TRAFFICDIRECTOR_INTERCEPTION_PORT` est définie dans les métadonnées du nœud du client xDS, mais qu'aucune ressource n'a été configurée pour que Cloud Service Mesh génère une réponse xDS complète.
"Échec de l'envoi de la réponse ADS depuis Cloud Service Mesh. La dernière requête de découverte du nœud comportait une version et/ou une version incorrecte."	Ce type de message de journal est généré lorsque Cloud Service Mesh n'a pas pu traiter la réponse xDS correctement en raison d'une communication corrompue du client xDS. Ce message indique une erreur de mise en œuvre dans le client. Nous vous recommandons de vérifier les journaux du client.
"Client envoyant du trafic interrégional vers le service de backend `backend_service_id`. Région source : `source_region` Région(s) de destination : `destination_region1, destination_region2`"	Ce type de message de journal est généré lorsqu'un client signale à Cloud Service Mesh qu'il a envoyé du trafic interrégional depuis une région source vers une ou plusieurs régions de destination.

Afficher les métriques

Cloud Service Mesh exporte trois métriques vers Cloud Monitoring : xDS API Connected Streams (Flux connectés de l'API xDS), Request count (Nombre de requêtes) et Request count by zone (Nombre de requêtes par zone). xDS API Connected Streams indique le nombre de clients connectés à votre plan de contrôle. Request count indique le nombre de requêtes envoyées à un service backend, regroupées par région source, région de destination et état de la requête. Le nombre de requêtes par zone indique le nombre de requêtes envoyées à un service de backend, regroupées par zone source, zone de destination et état de la requête. Pour afficher ces métriques, utilisez l'Explorateur de métriques.

Pour afficher les métriques Cloud Service Mesh, procédez comme suit:

Dans la console Google Cloud, accédez à la page Explorateur de métriques.

Accéder à l'explorateur de métriques
Dans la liste Type de ressource, sélectionnez une ressource.
- Si vous utilisez les API de routage des services, sélectionnez Gateway Scope ou Mesh.
- Si vous utilisez les anciennes API, sélectionnez Network.
Dans la liste Métrique, sélectionnez connected_clients.
Revenez à la liste Type de ressource, puis sélectionnez Compute Engine Backend Service.
Dans la liste Métrique, sélectionnez Request count ou Request count by zone.

Vous pouvez également utiliser une requête pour afficher le nombre de requêtes interrégionales :

Sélectionnez MQL.

Dans le champ, saisissez l'exemple de requête suivant :

fetch gce_backend_service
| metric 'trafficdirector.googleapis.com/xds/server/request_count'
| filter ( ne(metric.source_region, metric.destination_region))
| align rate(1m)
| every 1m
| group_by [metric.source_region, metric.destination_region, resource.backend_service_id],
[value_request_count_aggregate: aggregate(value.request_count)]

Cliquez sur Run query.

Configurer des métriques et des alertes basées sur les journaux

Les étapes suivantes nécessitent la configuration de métriques basées sur les journaux. Pour en savoir plus sur la configuration des métriques basées sur les journaux, consultez la présentation.

Vous pouvez configurer des alertes afin d'être averti lorsque des messages spécifiés par l'utilisateur apparaissent dans vos journaux inclus. Ces alertes peuvent avertir l'opérateur en cas d'événement inattendu. Par exemple, si une modification de la configuration de Cloud Service Mesh entraîne des conflits de ressources d'API, vous pouvez recevoir une alerte sur l'erreur . Pour configurer des alertes sur vos métriques basées sur les journaux, consultez la section Configurer des graphiques et des alertes.