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
STDOUTetSTDERRvers Cloud Logging, puis vérifier les codes renvoyés de la charge de travail pour identifier l'emplacement de l'échec.Image Confidential Space de débogage : l'image Confidential Space de débogage maintient la Confidential VM qui exécute la charge de travail 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 devez 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 VM confidentielle de charge de travail, vous pouvez utiliser la commande
sudo ctr task exec -t --exec-id shell tee-container bashpour accéder à un shell interactif à l'intérieur du 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 charge de travail en définissant la clé de métadonnées tee-container-log-redirect 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 rôle logging.logWriter.
L'auteur de la charge de travail peut empêcher la redirection avec 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 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 :
Accédez à Logging dans le projet de l'opérateur de charge de travail dans la consoleGoogle Cloud .
À côté de l'onglet Requête, cliquez sur la période pour définir la période de journalisation que vous souhaitez afficher.
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 Confidential VM.
Nom du journal : confidential-space-launcher
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 pools d'identités de charge de travail 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 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, vous pouvez configurer le lanceur pour qu'il redémarre en cas d'échec avec la règle tee-restart-policy=OnFailure.