ワークロードのビルド、テスト、実行を行う際に、進行状況をモニタリングして問題をデバッグすると便利な場合があります。モニタリングとデバッグには、次のツールを使用できます。
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 のログを表示してエラーをトラブルシューティングできます。
コンソールでワークロード オペレーターのプロジェクトの [Logging] に移動します。Google Cloud
[クエリ] タブの横にある期間をクリックして、表示するロギング期間を設定します。
次のログフィールドがある場合は、ログをフィルタします。
リソースの種類: VM インスタンス
インスタンス ID: Confidential VM のインスタンス ID
ログ名: confidential-space-launcher
エラー メッセージを読んで、問題の内容を確認します。リソースが正しく設定されていない、データ コラボレーターの 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