Beim Erstellen, Testen und Ausführen einer Arbeitslast kann es hilfreich sein, den Fortschritt zu überwachen, um Probleme zu beheben. Die folgenden Tools stehen für die Überwachung und das Debugging zur Verfügung:
Das Confidential Space-Debug-Image: Das Confidential Space-Debug-Image sorgt dafür, dass die Confidential VM, auf der die Arbeitslast ausgeführt wird, nach Abschluss der Arbeitslast betriebsbereit bleibt, und führt einen SSH-Server aus. So können Sie sich per Remotezugriff in der VM anmelden, um Probleme zu diagnostizieren. Es ist sinnvoll, das Debug-Image zu verwenden, bis Sie sicher sind, dass sich Ihr Code wie erwartet verhält. Wenn Sie mit sensiblen Produktionsdaten arbeiten möchten, wechseln Sie zum Confidential Space-Produktions-Image.
Interaktive Shell: Nachdem Sie über SSH eine Verbindung zu Ihrer Confidential VM für Arbeitslasten hergestellt haben, können Sie mit dem Befehl sudo ctr task exec -t --exec-id shell tee-container bash eine interaktive Shell im Container aufrufen, um Probleme mit der Arbeitslast zu diagnostizieren.
Protokollierung
Wie bei jedem Befehlszeilenprogramm können die Arbeitslasten STDOUT und STDERR in der Konsole angezeigt werden. Sie kann auch zu Cloud Logging weitergeleitet werden, indem der Arbeitslastoperator den Metadatenschlüssel tee-container-log-redirect auf der Confidential Space-VM auf true oder cloud_logging setzt und dafür sorgt, dass das Dienstkonto, das die Arbeitslast ausführt, die Rolle logging.logWriter hat.
Um das Risikoprofil zu minimieren, loggen Sie so wenig wie möglich und loggen Sie keine sensiblen Daten.
Confidential Space-Logs ansehen
Wenn dem Dienstkonto, das an Ihre Confidential Space-VM angehängt ist, die Rolle logging.logWriter zugewiesen wurde und Sie Logs zu Cloud Logging weitergeleitet haben, können Sie Fehler beheben, indem Sie sich die Logs der VM ansehen:
Rufen Sie in derGoogle Cloud Console Logging im Projekt des Arbeitslastoperators auf.
Klicken Sie neben dem Tab Abfrage auf den Zeitraum, um den Protokollierungszeitraum festzulegen, den Sie sich ansehen möchten.
Filtern Sie die Logs nach den folgenden Logfeldern, sofern verfügbar:
Ressourcentyp:VM-Instanz
Instanz-ID:Die Instanz-ID der Confidential VM
Logname: confidential-space-launcher
Lesen Sie die Fehlermeldung, um herauszufinden, was das Problem ist. Möglicherweise wurde eine Ressource nicht richtig eingerichtet, die Attributbedingungen in den WIP-Anbietern Ihrer Datenpartner stimmen nicht mit den Anforderungen der Confidential Space-Arbeitslast überein oder es ist ein Fehler in der Arbeitslast selbst aufgetreten.
Rückgabecodes
Rückgabecodes werden in der Konsole angezeigt, wenn Sie den Launcher und die Arbeitslast ausführen. Sie können zu Cloud Logging umgeleitet werden.
Die Rückgabecodes werden in der folgenden Tabelle beschrieben:
Code
Definition
Verhalten beim Beenden von VMs
0
Die Arbeitslast wurde mit dem Produktionsimage erfolgreich abgeschlossen.
Die VM wird nach Abschluss der Arbeitslast beendet.
1
Die Arbeitslast oder der Launcher hat bei Verwendung des Produktions-Images einen Fehler zurückgegeben.
Die VM wird beendet, nachdem sie einen Fehler zurückgegeben hat.
3
Der Launcher wurde nach einem Fehler aufgrund von tee-restart-policy neu gestartet.
Die VM wird neu gestartet.
4
Die Arbeitslast oder der Launcher wurde beendet, wenn Sie das Debug-Image verwenden, und die VM ist jetzt inaktiv.
Die VM wird nicht beendet, nachdem die Arbeitslast abgeschlossen ist oder einen Fehler zurückgibt. Auf diese Weise können Sie die Arbeitslast über SSH debuggen.
Wenn eine Arbeitslast fehlschlägt, erhält der Arbeitslastoperator nur die Meldung workload finished with a non-zero return code, ohne weiteren Kontext. Bei einem Produktions-Image kann der Launcher mit tee-restart-policy=OnFailure so konfiguriert werden, dass er nach einem Fehler neu gestartet wird.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eCloud Logging can be used to troubleshoot Confidential Space workloads by redirecting \u003ccode\u003eSTDOUT\u003c/code\u003e and \u003ccode\u003eSTDERR\u003c/code\u003e and checking for workload return codes to identify failure points.\u003c/p\u003e\n"],["\u003cp\u003eThe debug Confidential Space image allows for remote SSH access to the VM after workload completion, enabling in-depth diagnosis of issues before switching to the production image.\u003c/p\u003e\n"],["\u003cp\u003eMemory usage monitoring can be enabled for workloads, providing visibility through Cloud Logging or Metrics Explorer, but it requires enablement by both the workload author and operator.\u003c/p\u003e\n"],["\u003cp\u003eWorkload operators can use an interactive shell within the container of a Confidential VM to diagnose issues after connecting via SSH.\u003c/p\u003e\n"],["\u003cp\u003eReturn codes from the workload or launcher, which are displayed in the console and can be redirected to cloud logging, provide crucial information about the success or failure of the workload.\u003c/p\u003e\n"]]],[],null,["# Monitor and debug workloads\n\n[Workload author](/confidential-computing/confidential-space/docs/confidential-space-overview#roles) [Workload operator](/confidential-computing/confidential-space/docs/confidential-space-overview#roles)\n\n*** ** * ** ***\n\nWhen building, testing, and running a workload, it can be useful to monitor its\nprogress to debug issues. The following tools are available to use for\nmonitoring and debugging:\n\n- **Cloud Logging** : As the first step in troubleshooting a Confidential Space\n workload, you can\n [redirect `STDOUT` and `STDERR` to Cloud Logging](/confidential-computing/confidential-space/docs/deploy-workloads#tee-container-log-redirect),\n and then\n [check it for workload return codes](#logging) to see where a failure\n occurred.\n\n- **The debug Confidential Space image** : The\n [debug Confidential Space image](/confidential-computing/confidential-space/docs/confidential-space-images#types_of_images)\n keeps the Confidential VM running the workload operational after the workload has\n completed, and runs an SSH server. This lets you remotely log into the VM to\n diagnose issues. It's useful to use the debug image until you're confident\n that your code is behaving as it should. When it's time to start working on\n sensitive production data, switch to the production Confidential Space\n image.\n\n- **Memory usage monitoring** : You can view the memory usage of the workload in\n [Cloud Logging](/logging) or\n [Metrics Explorer](/monitoring/charts/metrics-explorer).\n The\n [workload author needs to allow it](/confidential-computing/confidential-space/docs/reference/launch-policies#monitoring-memory-allow),\n and the\n [workload operator needs to enable it](/confidential-computing/confidential-space/docs/reference/metadata-variables#tee-memory-monitoring-enable)\n before memory usage is tracked.\n\n- **Interactive shell** : After using SSH to connect to your workload\n Confidential VM, you can use the\n `sudo ctr task exec -t --exec-id shell tee-container bash` command to enter\n an interactive shell inside the container to diagnose workload issues.\n\nLogging\n-------\n\nLike any command line program, the workload `STDOUT` and `STDERR` can be\ndisplayed in the console. It can also be redirected to Cloud Logging by the\nworkload operator setting the\n[`tee-container-log-redirect`](/confidential-computing/confidential-space/docs/deploy-workloads#tee-container-log-redirect)\nmetadata key to `true` or `cloud_logging` on the Confidential Space VM, and\nensuring that the service account running the workload has the\n`logging.logWriter` role.\n\nRedirection can be prevented by the workload author with the\n[`log_redirect` launch policy](/confidential-computing/confidential-space/docs/create-customize-workloads#log-redirect).\n\nTo reduce your risk profile, log the minimum amount of information, and don't\nlog sensitive information.\n\n### View Confidential Space logs\n\nIf the service account attached to your Confidential Space VM has been granted the\n`logging.logWriter` role and you've redirected logs to Cloud Logging, you can\ntroubleshoot errors by viewing the VM's logs:\n\n1. Go to **Logging** in the workload operator's project in the\n Google Cloud console.\n\n [Go to Logging](https://console.cloud.google.com/logs)\n2. Next to the **Query** tab, click the time range to set the logging period\n you want to view.\n\n3. Filter the logs by the following log fields if they're available:\n\n - **Resource type:** VM Instance\n\n - **Instance ID:** The instance ID of the Confidential VM\n\n - **Log name:** confidential-space-launcher\n\n4. Read the failure message to find out what the problem is. A resource might\n not have been set up properly, the attribute conditions in your data\n collaborators' WIP providers might not match the claims made by the\n Confidential Space workload, or the workload itself might have had an error.\n\nReturn codes\n------------\n\nReturn codes are displayed in the console when running the\n[launcher](/docs/security/confidential-space#attestation-process)\nand workload, and can be redirected to Cloud Logging.\n\nThe return codes are described in the following table:\n\nIf a workload fails, a workload operator only receives the message\n`workload finished with a non-zero return code`, without further context. For a\nproduction image, the launcher can be set to restart on failure with\n[`tee-restart-policy=OnFailure`](/confidential-computing/confidential-space/docs/deploy-workloads#tee-restart-policy)."]]
