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

Google Distributed Cloud（GDC）エアギャップ アプライアンスのログ収集を使用すると、ワークフローの運用イベントを集約して、モニタリングとトラブルシューティングを行うことができます。管理 API サーバーのプロジェクト名前空間に LoggingTarget カスタム リソースをデプロイして、サービス コンポーネントからログを pull、インデックス登録、ラベル付けします。

ログ収集を構成したら、Grafana ユーザー インターフェースでログをクエリして表示できます。計測手法の推奨事項については、Kubernetes のロギング ガイドラインをご覧ください。

始める前に

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

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

  • アプリケーション オペレーター: 管理 API サーバーのプロジェクトで LoggingTarget カスタム リソースを管理するために必要な権限を取得するには、プロジェクトの IAM 管理者に、プロジェクトの名前空間で次のいずれかのロールを付与するよう依頼してください。

    • LoggingTarget 作成者: LoggingTarget カスタム リソースを作成します。LoggingTarget 作成者（loggingtarget-creator）ロールをリクエストします。
    • LoggingTarget 編集者: LoggingTarget カスタム リソースを編集または変更します。LoggingTarget 編集者（loggingtarget-editor）ロールをリクエストします。
    • LoggingTarget 閲覧者: LoggingTarget カスタム リソースを表示します。LoggingTarget 閲覧者（loggingtarget-viewer）ロールをリクエストします。

  • プラットフォーム管理者: Management API サーバーの platform-obs Namespace で LoggingTarget カスタム リソースを管理するために必要な権限を取得するには、組織の IAM 管理者に、platform-obs Namespace で次のいずれかのクラスタロールを付与するよう依頼してください。

    • LoggingTarget PA Creator: LoggingTarget カスタム リソースを作成します。LoggingTarget PA Creator（loggingtarget-pa-creator）クラスタロールをリクエストします。
    • LoggingTarget PA 編集者: LoggingTarget カスタム リソースを編集または変更します。LoggingTarget PA 編集者（loggingtarget-pa-editor）クラスタロールをリクエストします。
    • LoggingTarget PA 閲覧者: LoggingTarget カスタム リソースを表示します。LoggingTarget PA 閲覧者（loggingtarget-pa-viewer）クラスタロールをリクエストします。

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

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

サービスからオペレーション ログを収集する手順は次のとおりです。

  1. Management API サーバーで LoggingTarget カスタム リソースを構成し、運用ログを収集するために選択した Pod、プロジェクトの名前空間、その他の設定を指定します。LoggingTarget の内容については、LoggingTarget カスタム リソースを構成するをご覧ください。

  2. Management API サーバーのプロジェクト名前空間に LoggingTarget カスタム リソースをデプロイします。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME

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

    • MANAGEMENT_API_SERVER: ゾーン管理 API サーバーの kubeconfig パス。
    • LOGGING_TARGET_NAME: LoggingTarget カスタム リソースの名前（my-service-logging-target.yaml など）。

    パイプラインは、プロジェクトの追加コンポーネントからログの収集を開始します。

  3. プロジェクトの Grafana インスタンスからログをクエリします。詳細については、ログのクエリと表示をご覧ください。

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

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

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

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

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

  • 認可: ログエントリのアクセスレベル。収集されたログを表示できるユーザーを制御します。

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

サービスからオペレーション ログを収集する手順は次のとおりです。

  1. ログを収集する GDC プロジェクトを決定します。

  2. LoggingTarget 構成で、運用ログを収集する Pod、プロジェクトの名前空間、追加の設定を指定します。

    次の 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 リファレンス ドキュメントをご覧ください。

  3. ターゲット Pod と同じ Namespace 内の Management API サーバーに LoggingTarget 構成を適用します。

    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: プロジェクトの名前空間。
  • LOGGING_TARGET_NAME: LoggingTarget 定義ファイルの名前。