* Stackdriver Logging に移動し、resource.labels.project_id=* を選択します。正しくありません。
ログエントリは、30 日間（デフォルト構成）の保持期間と呼ばれる限られた期間、Stackdriver Logging に保持されます。その後、エントリは削除されます。ログエントリをより長く保存するには、ログシンクを構成してログエントリを Stackdriver Logging の外部にエクスポートする必要があります。
参照: https://cloud.google.com/blog/products/gcp/best-practices-for-working-with-google-cloud-audit-logging
* Stackdriver から読み取り、ログを BigQuery に保存するように Cloud Scheduler ジョブを構成します。テーブルの有効期限を 60 日に設定します。正しくありません。
これは機能しますが、Google がまったく同じことを行い、そのまま使用できる機能 (シンクのエクスポート) を提供している場合、Cloud Scheduler ジョブを使用して Stackdriver から読み取り、ログを BigQuery に保存するのは意味がありません。参照: https:/ /cloud.google.com/logging/docs/export/configure_export_v2
* シンク先を Cloud Storage とする Stackdriver Logging エクスポートを作成します。60 日後にオブジェクトを削除するライフサイクル ルールを作成します。正しくありません。
ログ クエリとエクスポート先を含む 1 つ以上のシンクを作成することで、ログをエクスポートできます。
エクスポートされたログ エントリのサポートされている宛先は、Cloud Storage、BigQuery、Pub/Sub です。参照: https://cloud.google.com/logging/docs/export/configure_export_v2 シンクは、ログ エントリが保存されている正確なリソースからのログ エントリのエクスポートに限定されます。シンクが作成されました: Google Cloud プロジェクト、組織、フォルダ、請求先アカウント。組織のすべてのプロジェクトからのエクスポートが簡単になる場合は、Google Cloud 組織のすべてのプロジェクト、フォルダ、請求先アカウントからログエントリをエクスポートできる集約シンクを作成できます。参照: https://cloud.google .com/logging/docs/export/aggregated_sinks いずれにしても、データは Cloud Storage にありますが、Cloud Storage からログ情報をクエリするのは、BigQuery データセットから情報をクエリするよりも困難です。このため、Cloud Storage よりも Big Query を選択する必要があります。
* BigQuery データセットへのシンク宛先を使用して Stackdriver Logging エクスポートを作成します。テーブルの有効期限を 60 日に設定します。が正しい答えです。
ログ クエリとエクスポート先を含む 1 つ以上のシンクを作成することで、ログをエクスポートできます。
エクスポートされたログ エントリのサポートされている宛先は、Cloud Storage、BigQuery、Pub/Sub です。参照: https://cloud.google.com/logging/docs/export/configure_export_v2 シンクは、ログ エントリが保存されている正確なリソースからのログ エントリのエクスポートに限定されます。シンクが作成されました: Google Cloud プロジェクト、組織、フォルダ、請求先アカウント。組織のすべてのプロジェクトからのエクスポートが簡単になる場合は、Google Cloud 組織のすべてのプロジェクト、フォルダ、請求先アカウントからログエントリをエクスポートできる集約シンクを作成できます。参照: https://cloud.google .com/logging/docs/export/aggregated_sinks いずれにせよ、BigQuery データセットにデータが保存されました。Big Query データセットから情報をクエリすることは、Cloud Storage バケットのコンテンツを分析するよりも簡単かつ迅速です。私たちの要件はログの内容を迅速に分析することであるため、Cloud Storage よりも Big Query を優先する必要があります。
また、データセット内に新しく作成されたテーブルのデフォルトのテーブル有効期限を設定することで、ストレージ コストを制御し、ストレージ使用量を最適化することができます。データセットの作成時にプロパティを設定すると、データセット内に作成されたテーブルは有効期限が過ぎると削除されます。データセットの作成後にプロパティを設定すると、有効期限後に新しいテーブルのみが削除されます。たとえば、デフォルトのテーブルの有効期限を 7 日に設定すると、古いデータは 1 週間後に自動的に削除されます。参照: https:// Cloud.google.com/bigquery/docs/best-practices-storage

「Cloud Spanner to Cloud Storage Text テンプレートは、Cloud Spanner テーブルからデータを読み取り、オプションで提供する JavaScript ユーザー定義関数 (UDF) を介してデータを変換し、CSV テキスト ファイルとして Cloud Storage に書き込むバッチ パイプラインです。 。」
https://cloud.google.com/dataflow/docs/guides/templates/provided-batch#cloudspannertogcstext
「Cloud Spanner の Dataflow コネクタを使用すると、Dataflow パイプラインで Cloud Spanner との間でデータを読み書きできるようになります。」
https://cloud.google.com/spanner/docs/dataflow-connector
https://cloud.google.com/bigquery/external-data-sources

参照：
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app

開発プロジェクト用と運用プロジェクト用の 2 つの構成を作成できます。これを行うには、「gcloud config Configurations create」コマンドを実行します。https://cloud.google.com/sdk/gcloud/reference/config/configurations/create カスタム スクリプトで、これらの構成を一度に 1 つずつロードし、 gcloud compute instances list を実行して、プロジェクト内の Google Compute Engine インスタンスを一覧表示できます。これは gcloud 構成でアクティブになります。参照: https://cloud.google.com/sdk/gcloud/reference/compute/instances/list この情報を取得したら、CSV としてエクスポートしたり、Cloud Storage にエクスポートしたりするなど、適切な形式で適切なターゲットにエクスポートできます。 /BigQuery/SQL など