ワークロードをモニタリングしてデバッグする

ワークロードの構築、テスト、実行時に、進捗状況をモニタリングして問題をデバッグすると便利です。モニタリングとデバッグには、次のツールを使用できます。

  • Cloud Logging: Confidential Space ワークロードのトラブルシューティングの最初のステップとして、STDOUT と STDERR を Cloud Logging にリダイレクトし、ワークロードの戻りコードを確認して、障害が発生した場所を確認できます。

  • デバッグ用 Confidential Space イメージ: デバッグ用 Confidential Space イメージは、ワークロードの完了後にワークロードを実行している Confidential VM を維持し、SSH サーバーを実行します。これにより、VM にリモートでログインして問題を診断できます。コードが想定どおりに動作することを確認するまで、デバッグ用イメージを使用すると便利です。機密性の高い本番環境データの処理を開始するときは、本番環境の Confidential Space イメージに切り替えます。

  • メモリ使用量のモニタリング: ワークロードのメモリ使用量は、Cloud Logging または Metrics Explorer で確認できます。メモリ使用量をトラッキングするには、ワークロード作成者が許可し、ワークロード オペレーターが有効にする必要があります。

  • インタラクティブ シェル: SSH を使用してワークロードの Confidential VM に接続したら、sudo ctr task exec -t --exec-id shell tee-container bash コマンドを使用してコンテナ内のインタラクティブ シェルに移動し、ワークロードの問題を診断できます。

ロギング

他のコマンドライン プログラムと同様に、ワークロード STDOUT と STDERR はコンソールに表示できます。また、ワークロード オペレーターが Confidential Space VM で tee-container-log-redirect メタデータキーを true または cloud_logging に設定し、ワークロードを実行しているサービス アカウントに logging.logWriter ロールがあることを確認することで、Cloud Logging にリダイレクトすることもできます。

ワークロード作成者は、log_redirect 起動ポリシーを使用してリダイレクトを防ぐことができます。

リスク プロファイルを減らすには、最小限の情報を記録し、機密情報は記録しないでください。

Confidential Space のログを表示する

Confidential Space VM に接続されているサービス アカウントに logging.logWriter ロールが付与され、ログが Cloud Logging にリダイレクトされている場合は、VM のログを表示してエラーのトラブルシューティングを行うことができます。

  1. Google Cloud コンソールで、ワークロード オペレーターのプロジェクトの [Logging] に移動します。

    Logging に移動

  2. [クエリ] タブの横にある期間をクリックして、表示するロギング期間を設定します。

  3. 利用可能な場合は、次のログフィールドでログをフィルタします。

    • リソースタイプ: VM インスタンス

    • インスタンス ID: Confidential VM のインスタンス ID

    • ログ名: confidential-space-launcher

  4. エラー メッセージを読んで、問題の原因を特定します。リソースが正しく設定されていないか、データ コラボレーターの WIP プロバイダの属性条件が Confidential Space ワークロードによるクレームと一致していないか、ワークロード自体にエラーがある可能性があります。

戻りコード

戻りコードは、ランチャーとワークロードの実行時にコンソールに表示され、Cloud Logging にリダイレクトできます。

戻りコードは次の表のとおりです。

コード 定義 VM の停止動作
0 本番環境イメージを使用した場合、ワークロードは正常に完了しました。 ワークロードが完了すると、VM が停止します。
1 本番環境イメージの使用時に、ワークロードまたはランチャーからエラーが返されました。 VM はエラーを返した後に停止します。
3 ランチャーは、tee-restart-policy が原因での失敗の後、再起動しました。 VM が再起動されました。
4 デバッグイメージを使用しているときに、ワークロードまたはランチャーの実行が完了し、VM がアイドル状態になりました。 ワークロードの完了後またはエラーの返却後に VM が停止しません。これは、SSH 経由でワークロードをデバッグできるようにするためです。

ワークロードが失敗した場合、ワークロード オペレータは、追加のコンテキストなしで workload finished with a non-zero return code メッセージのみを受信します。本番環境のイメージでは、tee-restart-policy=OnFailure での失敗時にランチャーが再起動するように設定できます。