Beim Erstellen, Testen und Ausführen einer Arbeitslast kann es hilfreich sein, den Fortschritt zu beobachten, um Probleme zu beheben. Die folgenden Tools stehen für Monitoring und Debugging zur Verfügung:
Cloud Logging: Als ersten Schritt bei der Fehlerbehebung für eine Arbeitslast in einem Confidential Space können Sie
STDOUTundSTDERRan Cloud Logging weiterleiten und dann nach Arbeitslastrückgabecodes suchen, um zu sehen, wo ein Fehler aufgetreten ist.Debug-Image für Confidential Space: Das Debug-Image für Confidential Space hält die Confidential VM, auf der die Arbeitslast ausgeführt wird, nach Abschluss der Arbeitslast in Betrieb und führt einen SSH-Server aus. So können Sie sich per Fernzugriff in der VM anmelden, um Probleme zu diagnostizieren. Sie sollten das Debug-Image verwenden, bis Sie sicher sind, dass Ihr Code wie vorgesehen funktioniert. Wenn Sie mit sensiblen Produktionsdaten arbeiten möchten, wechseln Sie zum Produktions-Image für Confidential Space.
Überwachung der Arbeitsspeichernutzung: Sie können die Arbeitsspeichernutzung der Arbeitslast in Cloud Logging oder im Metrics Explorer aufrufen. Die Ersteller der Arbeitslast müssen sie zulassen und der Betreiber der Arbeitslast muss sie aktivieren, bevor die Speichernutzung erfasst wird.
Interaktive Shell: Nachdem Sie über SSH eine Verbindung zu Ihrer vertraulichen VM für die Arbeitslast hergestellt haben, können Sie mit dem Befehl
sudo ctr task exec -t --exec-id shell tee-container basheine interaktive Shell im Container aufrufen, um Probleme mit der Arbeitslast zu diagnostizieren.
Logging
Wie jedes Befehlszeilenprogramm können die Arbeitslasten STDOUT und STDERR in der Konsole angezeigt werden. Sie können auch zu Cloud Logging weitergeleitet werden, indem der Arbeitslastbearbeiter den Metadatenschlüssel tee-container-log-redirect auf der Confidential Space-VM auf true oder cloud_logging festlegt und dafür sorgt, dass das Dienstkonto, das die Arbeitslast ausführt, die Rolle logging.logWriter hat.
Der Autor der Arbeitslast kann die Weiterleitung mit der log_redirect-Richtlinie für den Start verhindern.
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 an Cloud Logging weitergeleitet haben, können Sie Fehler beheben, indem Sie sich die Logs der VM ansehen:
Rufen Sie in derGoogle Cloud Console im Projekt des Arbeitslastbearbeiters Logging auf.
Klicken Sie neben dem Tab Abfrage auf den Zeitraum, um den gewünschten Protokollierungszeitraum festzulegen.
Filtern Sie die Protokolle nach den folgenden Protokollfeldern, sofern verfügbar:
Ressourcentyp:VM-Instanz
Instanz-ID:Die Instanz-ID der Confidential VM
Logname: confidential-space-launcher
Lesen Sie die Fehlermeldung, um das Problem zu ermitteln. Möglicherweise wurde eine Ressource nicht richtig eingerichtet, die Attributbedingungen in den WIP-Anbietern Ihrer Mitbearbeiter stimmen nicht mit den Anforderungen der Confidential Space-Arbeitslast überein oder es gab einen Fehler bei der Arbeitslast selbst.
Rückgabecodes
Rückgabecodes werden in der Konsole angezeigt, wenn der Launcher und die Arbeitslast ausgeführt werden. Sie können an Cloud Logging weitergeleitet werden.
Die Rückgabecodes werden in der folgenden Tabelle beschrieben:
| Code | Definition | Verhalten beim Beenden einer VM |
|---|---|---|
| 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 ein Fehler zurückgegeben wurde. |
| 3 | Der Launcher wurde nach einem Fehler aufgrund seiner 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 ihre Arbeitslast über SSH debuggen. |
Wenn eine Arbeitslast fehlschlägt, erhält der Arbeitslastbearbeiter nur die Nachricht workload finished with a non-zero return code ohne weiteren Kontext. Bei einem Produktions-Image kann der Launcher so eingestellt werden, dass er bei einem Fehler mit tee-restart-policy=OnFailure neu gestartet wird.