Surveiller et déboguer les charges de travail

Lorsque vous créez, testez et exécutez une charge de travail, il peut être utile de surveiller sa progression pour déboguer les problèmes. Les outils suivants sont disponibles pour la surveillance et le débogage:

  • Cloud Logging: pour commencer à résoudre les problèmes d'une charge de travail Confidential Space, vous pouvez rediriger STDOUT et STDERR vers Cloud Logging, puis vérifier les codes de retour de la charge de travail pour voir où un échec s'est produit.

  • Image Confidential Space de débogage: l'image Confidential Space de débogage maintient la VM Confidential qui exécute la charge de travail opérationnelle une fois la charge de travail terminée et exécute un serveur SSH. Vous pouvez ainsi vous connecter à distance à la VM pour diagnostiquer les problèmes. Il est utile d'utiliser l'image de débogage jusqu'à ce que vous soyez sûr que votre code fonctionne comme prévu. Lorsque vous devez commencer à travailler sur des données de production sensibles, passez à l'image de production Confidential Space.

  • Surveillance de l'utilisation de la mémoire: vous pouvez consulter l'utilisation de la mémoire de la charge de travail dans Cloud Logging ou dans l'explorateur de métriques. L'auteur de la charge de travail doit l'autoriser et l'opérateur de la charge de travail doit l'activer avant que l'utilisation de la mémoire ne soit suivie.

  • Shell interactif: après avoir utilisé SSH pour vous connecter à votre VM de charge de travail confidentielle, vous pouvez utiliser la commande sudo ctr task exec -t --exec-id shell tee-container bash pour accéder à un shell interactif dans le conteneur afin de diagnostiquer les problèmes de charge de travail.

Journalisation

Comme n'importe quel programme de ligne de commande, la charge de travail STDOUT et STDERR peuvent être affichées dans la console. Il peut également être redirigé vers Cloud Logging par l'opérateur de la charge de travail en définissant la clé de métadonnées tee-container-log-redirect sur true ou cloud_logging dans la VM Confidential Space, et en s'assurant que le compte de service qui exécute la charge de travail dispose du rôle logging.logWriter.

L'auteur de la charge de travail peut empêcher la redirection à l'aide de la règle de lancement log_redirect.

Pour réduire votre profil de risque, consignez la quantité minimale d'informations et n'enregistrez pas d'informations sensibles.

Afficher les journaux Confidential Space

Si le compte de service associé à votre VM de Confidential Space a le rôle logging.logWriter et que vous avez redirigé les journaux vers Cloud Logging, vous pouvez résoudre les erreurs en affichant les journaux de la VM:

  1. Accédez à Logging dans le projet de l'opérateur de charge de travail dans la consoleGoogle Cloud .

    Accéder à Stackdriver Logging

  2. À côté de l'onglet Requête, cliquez sur la période pour définir la période de journalisation que vous souhaitez afficher.

  3. Filtrez les journaux en fonction des champs de journal suivants, s'ils sont disponibles:

    • Type de ressource : instance de VM

    • ID d'instance:ID d'instance de la VM confidentielle.

    • Nom du journal : confidential-space-launcher

  4. Lisez le message d'échec pour identifier le problème. Une ressource n'a peut-être pas été configurée correctement, les conditions d'attribut de vos fournisseurs de travail en cours de vos collaborateurs de données peuvent ne pas correspondre aux revendications effectuées par la charge de travail de Confidential Space, ou la charge de travail elle-même peut avoir généré une erreur.

Codes renvoyés

Les codes renvoyés s'affichent dans la console lors de l'exécution du lanceur et de la charge de travail, et peuvent être redirigés vers Cloud Logging.

Les codes renvoyés sont décrits dans le tableau suivant :

Coder Définition Comportement d'arrêt de la VM
0 La charge de travail a bien été exécutée lors de l'utilisation de l'image de production. La VM s'arrête une fois la charge de travail terminée.
1 La charge de travail ou le lanceur a renvoyé une erreur lors de l'utilisation de l'image de production. La VM s'arrête après avoir renvoyé une erreur.
3 Le lanceur a redémarré après un échec en raison de sa règle tee-restart-policy. La VM est redémarrée.
4 La charge de travail ou le lanceur ont terminé lors de l'utilisation de l'image de débogage, et la VM est maintenant inactive. La VM ne s'arrête pas une fois la charge de travail terminée ou renvoie une erreur. Cela vous permet de déboguer la charge de travail via SSH.

Si une charge de travail échoue, un opérateur de charge de travail ne reçoit que le message workload finished with a non-zero return code, sans autre contexte. Pour une image de production, vous pouvez configurer le lanceur pour qu'il redémarre en cas d'échec avec la règle tee-restart-policy=OnFailure.