このページは Cloud Translation API によって翻訳されました。

ワークフローからログを収集する

このページでは、Google Distributed Cloud（GDC）エアギャップアプライアンス環境のワークフローからログを収集して、ロギングとデータのオブザーバビリティを容易にするプロセスについて説明します。

ログには、GDC のサービスからオペレーションを管理する際の条件とアクションが記録されます。コンポーネントが生成するログをスクレイピングして、イベントとアクティビティを記録できます。ロギングプラットフォームは、ロギングターゲットを介してワークフローで生成されたプロジェクトレベルのログを収集するカスタム API を提供します。

ログデータの収集を開始するには、Management API サーバーのプロジェクト Namespace に LoggingTarget カスタムリソースをデプロイします。ログコレクタがワークフローからデータを取得すると、ロギングプラットフォームはすべてのログソースからログを集約し、インデックスを追加して、LoggingTarget カスタムリソースの構成に従ってログをラベルに関連付けます。

ログのクエリと表示で説明されているように、Grafana ユーザーインターフェースを使用して収集したログにアクセスします。

データオブザーバビリティのロギングを実装する際のベストプラクティスについては、Kubernetes コミュニティのガイドラインをご覧ください。

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

始める前に

LoggingTarget カスタムリソースを管理するために必要な権限を取得するには、組織の IAM 管理者またはプロジェクトの IAM 管理者に、関連する LoggingTarget ロールのいずれかを付与するよう依頼してください。

必要なアクセスレベルと権限に応じて、組織またはプロジェクトでこのリソースの作成者、編集者、閲覧者のロールを取得できます。詳細については、IAM 権限を準備するをご覧ください。

アプリケーションオペレーター: 管理 API サーバーのプロジェクトで LoggingTarget カスタムリソースを管理するために必要な権限を取得するには、プロジェクトの IAM 管理者に、プロジェクトの Namespace で次のいずれかのロールを付与するよう依頼します。
- LoggingTarget Creator: LoggingTarget カスタムリソースを作成します。LoggingTarget 作成者（loggingtarget-creator）ロールをリクエストします。
- LoggingTarget 編集者: LoggingTarget カスタムリソースを編集または変更します。LoggingTarget 編集者（loggingtarget-editor）ロールをリクエストします。
- LoggingTarget 閲覧者: LoggingTarget カスタムリソースを表示します。LoggingTarget 閲覧者（loggingtarget-viewer）ロールをリクエストします。
プラットフォーム管理者: 管理 API サーバーの platform-obs Namespace で LoggingTarget カスタムリソースを管理するために必要な権限を取得するには、組織の IAM 管理者に、platform-obs Namespace で次のいずれかのクラスタロールを付与するよう依頼してください。
- LoggingTarget PA Creator: LoggingTarget カスタムリソースを作成します。LoggingTarget PA 作成者（loggingtarget-pa-creator）クラスタロールをリクエストします。
- LoggingTarget PA 編集者: LoggingTarget カスタムリソースを編集または変更します。LoggingTarget PA 編集者（loggingtarget-pa-editor）クラスタロールをリクエストします。
- LoggingTarget PA 閲覧者: LoggingTarget カスタムリソースを表示します。LoggingTarget PA 閲覧者（loggingtarget-pa-viewer）クラスタロールをリクエストします。

オペレーションログを収集する

運用ログには、GDC のアプリケーションとサービスで進行中のオペレーションを管理する際の条件、変更、アクションが記録されます。LoggingTarget カスタムリソースを Management API サーバーにデプロイして、プロジェクトレベルで特定のサービスから運用ログを収集するためのシステムロギングパイプラインを構成します。

サービスから運用ログを収集する手順は次のとおりです。

Management API サーバーで LoggingTarget カスタムリソースを構成し、オペレーションログの収集対象となる Pod、プロジェクトの Namespace、その他の設定を指定します。LoggingTarget の形式については、LoggingTarget カスタムリソースを構成するをご覧ください。
Management API サーバーのプロジェクト Namespace に LoggingTarget カスタムリソースをデプロイします。
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
```
次のように置き換えます。
- MANAGEMENT_API_SERVER: ゾーンの Management API サーバーの kubeconfig パス。
- LOGGING_TARGET_NAME: LoggingTarget カスタムリソースの名前（my-service-logging-target.yaml など）。
パイプラインは、プロジェクトの追加コンポーネントからログの収集を開始します。
プロジェクトの Grafana インスタンスからログをクエリします。詳細については、ログのクエリと表示をご覧ください。

サービスのさまざまなログレベルに Grafana の組み込みのカラーコーディング機能を使用します。ログレベル値の設定の詳細については、https://grafana.com/docs/grafana/latest/explore/logs-integration/ をご覧ください。

`LoggingTarget` カスタムリソースを構成する

LoggingTarget カスタムリソースは、GDC プロジェクト内の特定のサービスからログを収集するようにロギングパイプラインに指示します。ログを収集するターゲット、ログパーサー、アクセスレベル、その他の設定を指定できます。

このリソースは、次の構成を定義します。

ターゲット: ログを収集する Pod とコンテナを選択するための条件。クラスタ名、Pod 名の接頭辞、コンテナ名の接頭辞を指定できます。
ログアナライザー: ログエントリを解釈し、ログ出力をラベルにマッピングして、関連するフィールドを抽出する事前定義済みのパーサー。
サービス ID: ログエントリにラベルとして適用されるサービス名。識別とフィルタリングを容易にするために使用されます。
認可: ログエントリのアクセスレベル。収集されたログを表示できるユーザーを制御します。

注: デフォルトでは、すべての運用ログエントリはプロジェクト名前空間のテナント ID に保存されます。この動作をオーバーライドするには、LoggingTarget カスタムリソースで logAccessLevel 値を指定します。

LoggingTarget カスタムリソース内でこれらのパラメータを構成することで、サービスからのログの収集と整理を正確に制御できます。

サービスから運用ログを収集する手順は次のとおりです。

ログを収集する GDC プロジェクトを特定します。
LoggingTarget 構成で、運用ログを収集する Pod、プロジェクトの Namespace、追加設定を指定します。

次の YAML ファイルは、my-project-namespace の LoggingTarget 構成の例を示しています。ここで、ログを収集する Pod 名の接頭辞は my-pod-prefix、ログエントリのアクセスレベルはアプリケーションオペレーター（ao）に付与され、サービス名は my-service-name、ログ形式は JSON です。
```
# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: my-project-namespace
  name: my-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name
```
その他のフィールドとオプションについては、LoggingTarget の完全な仕様と API リファレンスドキュメントをご覧ください。
LoggingTarget 構成を、ターゲット Pod と同じ Namespace 内の Management API サーバーに適用します。
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
```
次のように置き換えます。
- KUBECONFIG_PATH: Management API サーバーの kubeconfig ファイルへのパス。
- LOGGING_TARGET_NAME: LoggingTarget 定義ファイルの名前（my-service-logging-target など）。
ロギングパイプラインは、プロジェクトの追加コンポーネントからログの収集を開始します。

収集したログは、Grafana ユーザーインターフェースまたは Log Query API を使用してクエリできます。詳細については、ログのクエリと表示をご覧ください。

Grafana を使用してログをクエリする場合は、サービスのさまざまなログレベルに組み込みの色分け機能を使用できます。ログレベル値の設定の詳細については、https://grafana.com/docs/grafana/latest/explore/logs-integration/ をご覧ください。

`LoggingTarget` の仕様を完了

次の YAML ファイルは、LoggingTarget カスタムリソースの完全な仕様の例を示しています。詳細とフィールドの完全な説明については、API リファレンスドキュメントをご覧ください。

# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods.
  namespace: PROJECT_NAMESPACE
  name: LOGGING_TARGET_NAME
spec:
  # Choose a matching pattern that identifies the pods for this job.
  # Optional.
  # Relationship between different selectors: 'AND'
  selector:
    # The clusters to collect logs from.
    # The default configuration is to collect logs from all clusters.
    # The relationship between different clusters is an 'OR' relationship.
    # Optional
    matchClusters:
    - my-cluster
    - another-cluster

    # The pod name prefixes to collect logs from.
    # The logging platform scrapes all pods with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchPodNames:
      - my-pod-prefix
      - another-pod-prefix

    # The container name prefixes to collect logs from.
    # The logging platform scrapes all containers with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional.
    matchContainerNames:
      - my-container-prefix
      - another-container-prefix

  # Choose the predefined parser for log entries.
  # Use parsers to map the log output to labels and extract fields.
  # Specify the log format.
  # Optional.
  # Options: klog_text, klog_json, klogr, gdch_json, json
  parser: klog_text

  # Specify an access level for log entries.
  # The default value is 'ao'.
  # Optional.
  # Options: ao, pa, io
  logAccessLevel: ao

  # Specify a service name to be applied as a label.
  # For user workloads consider this field as a workload name.
  # Required.
  serviceName: my-service-name

  # The additional static fields to apply to log entries.
  # The field is a key-value pair, where the field name is the key and
  # the field value is the value.
  # Optional.
  additionalFields:
    app: workload2
    key: value

次のように置き換えます。

PROJECT_NAMESPACE: プロジェクトの Namespace。
LOGGING_TARGET_NAME: LoggingTarget 定義ファイルの名前。

ワークフローからログを収集する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

オペレーション ログを収集する

LoggingTarget カスタム リソースを構成する

LoggingTarget の仕様を完了

ワークフローからログを収集する

オペレーションログを収集する

`LoggingTarget` カスタムリソースを構成する

`LoggingTarget` の仕様を完了