Arbeitslasten überwachen und Fehler beheben

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:

  • Cloud Logging: Als ersten Schritt bei der Fehlerbehebung einer Confidential Space-Arbeitslast können Sie STDOUT und STDERR zu Cloud Logging weiterleiten und dann nach Rückgabecodes der Arbeitslast suchen, um festzustellen, wo ein Fehler aufgetreten ist.

  • Das Debug-Confidential Space-Image: Das Debug-Confidential Space-Image sorgt dafür, dass die Confidential VM, auf der die Arbeitslast ausgeführt wird, nach Abschluss der Arbeitslast betriebsbereit bleibt und ein SSH-Server ausgeführt wird. 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.

  • Arbeitsspeichernutzung überwachen: Sie können die Arbeitsspeichernutzung der Arbeitslast in Cloud Logging oder im Metrics Explorer ansehen. Der Autor der Arbeitslast muss dies zulassen und der Arbeitslastoperator muss dies aktivieren, bevor die Speichernutzung erfasst wird.

  • 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.

Logging

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.

Die Weiterleitung kann vom Autor der Arbeitslast mit der Startrichtlinie log_redirect verhindert werden.

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:

  1. Rufen Sie in derGoogle Cloud Console Logging im Projekt des Arbeitslastoperators auf.

    Zu Logging

  2. Klicken Sie neben dem Tab Abfrage auf den Zeitraum, um den Protokollierungszeitraum festzulegen, den Sie sich ansehen möchten.

  3. 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

  4. 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 Datenkooperationspartner 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 so eingestellt werden, dass er bei einem Fehler mit tee-restart-policy=OnFailure neu gestartet wird.