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

ワークロード作成者 ワークロード オペレーター

---

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

• 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 に移動

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 での失敗時にランチャーが再起動するように設定できます。