Surveiller et déboguer les charges de travail

Auteur de la charge de travail Opérateur de charge 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 résoudre les problèmes liés à une charge de travail Confidential Space, vous pouvez commencer par rediriger STDOUT et STDERR vers Cloud Logging, puis vérifier les codes renvoyés de la charge de travail pour voir où l'échec s'est produit.

• Image Confidential Space de débogage : l' image Confidential Space de débogage permet à la VM Confidential qui exécute la charge de travail de rester opérationnelle une fois la charge de travail terminée et exécute un serveur SSH. Cela vous permet de 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 se comporte comme il le devrait. Lorsque vous êtes prêt à commencer à travailler sur des données de production sensibles, passez à l'image Confidential Space de production.

• Surveillance de l'utilisation de la mémoire : vous pouvez afficher l'utilisation de la mémoire de la charge de travail dans Cloud Logging ou 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 charge de travail VM Confidential, vous pouvez utiliser la sudo ctr task exec -t --exec-id shell tee-container bash commande pour accéder à un shell interactif dans le conteneur afin de diagnostiquer les problèmes liés à la charge de travail.

Journalisation

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

La redirection peut être empêchée par l'auteur de la charge de travail à l'aide de la log_redirect règle de lancement.

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 Confidential Space dispose du 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 Google Cloud console.

   Accéder à Stackdriver Logging

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

3. Filtrez les journaux par les champs de journal suivants s'ils sont disponibles :

   • Type de ressource : instance de VM

   • ID d'instance : ID d'instance de la VM Confidential

   • 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 WIP de collaborateurs de données peuvent ne pas correspondre aux revendications effectuées par la charge de travail Confidential Space, ou la charge de travail elle-même peut avoir rencontré 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, le lanceur peut être configuré pour redémarrer en cas d'échec avec tee-restart-policy=OnFailure.