GKE 用 Cloud Operations への移行

Google Kubernetes Engine(GKE)でのモニタリングとロギングのサポートには 2 つのオプションがあります。

このページでは、これらの 2 つのオプションと、以前の Logging と Monitoring から Cloud Operations for GKE への移行に必要な変更点について説明します。

移行のタイミング

既存の Cloud Monitoring と Cloud Logging の構成は、以前の Logging と Monitoring から Cloud Operations for GKE にいつでも移行できます。ただし、以前の Logging と Monitoring は GKE バージョン 1.20 でサポートされていません。

次の表に、各 GKE リリース バージョンで使用可能なモニタリングとロギングのオプションをまとめます。

GKE バージョン 以前の Logging と Monitoring Cloud Operations for GKE
1.14 使用可能 デフォルト
1.15 使用可能 デフォルト
1.16 使用可能 デフォルト
1.17 使用可能 デフォルト
1.18 使用可能 デフォルト
1.19 使用可能 デフォルト
1.20 利用不可 デフォルト

Legacy Logging と Monitoring の非推奨については、GKE の非推奨に対するレガシー サポートガイドをご覧ください。

GKE 用 Cloud Operations を使用するメリット

Cloud Operations for GKE には、次のような重要な利点があります。

  • インフラストラクチャのモニタリングが改善されます。無料枠で GKE ダッシュボードに表示される指標の数が 17 から 44 に増えます。

  • リソースタイプが増え、Kubernetes リソースをより明確に区別できます。また、指標のフィルタリングやグループ化に使用できるメタデータも増えます。

  • GKE 向け SLO モニタリングによりサービス指向モニタリングがサポートされます。

  • Cloud Logging と Cloud Monitoring 間で整合性のあるリソースモデルを使用できます。

  • 新しい GKE 指標を使用してパフォーマンスを改善できます。

変更内容

GKE 用 Cloud Operations は、以前の Logging / Monitoring とは別のリソースモデルを使用して指標、ログ、メタデータを整理します。GKE 用 Cloud Operations を使用するクラスタの主な変更点は次のとおりです。

  • ナビゲーションの変更: Cloud Monitoring ダッシュボードの名前は GKE です。Cloud Operations for GKE を使用するクラスタがない場合、このダッシュボードは表示されません。

  • モニタリング対象リソースタイプ名の変更: たとえば、Kubernetes ノードは、gce_instance(Compute Engine VM インスタンス)ではなく、k8s_node(Kubernetes ノード)モニタング対象リソースタイプに表示されます。

  • Kubernetes の指標名の変更: Cloud Operations for GKE では、指標タイプの名前は container.googleapis.com/ ではなく kubernetes.io/ という接頭辞で始まります。

  • logEntry メタデータの変更: GKE 用 Cloud Operations ログエントリで、一部の resource.label フィールドと labels フィールドの名前が変更されました。たとえば、resource.labels.namespace_id フィールドの名前は resource.labels.namespace_name に変更されていますが、値は変更されていません。

  • logName の変更: GKE 用 Cloud Operations ログエントリでは、ログ名に stdout または stderr が使用されていますが、以前の Logging と Monitoring ではコンテナ名などのさまざまな名前が使用されています。コンテナ名は、GKE 用 Cloud Operations の resource.labels.container_name でリソースラベルとして引き続き使用できます。

次の表は、上記の変更点をまとめたものです。

変更 (旧)以前の Logging と Monitoring (新)GKE 用 Cloud Operations
ダッシュボード メニュー [ダッシュボード] > [GKE Clusters] [ダッシュボード] > [GKE]
指標の接頭辞 container.googleapis.com kubernetes.io
指標のリソースタイプ gke_container
gce_instance
(なし)
k8s_container
k8s_node
k8s_pod
ログのリソースタイプ container
gke_cluster
gce_instance
gke_nodepool
k8s_container
k8s_cluster
gke_cluster(監査ログのみ)
k8s_node
k8s_pod

リソースタイプの変更

GKE 用 Cloud Operations では、リソースタイプの名前、リソースタイプの表示名、特定のリソースの識別に使用されるラベルの名前が変更されています。次の表は、これらの変更点をまとめたものです。

リソースタイプの変更
(旧)以前の Logging と Monitoring のリソースタイプ (新)GKE 用 Cloud Operations のリソースタイプ
表の脚注:
1 モニタリング(のみ)に使用される新しいリソースタイプで、instance_idmetadata.system_labelsnode_name になっています。
2 zone は、このコンテナまたはインスタンスのロケーションを表します。location は、クラスタ マスターノードのロケーションを表します。
3 metadata.system_labels.node_name は、ロギングの k8s_container リソースタイプで使用できません。ログをノード名で検索することはできません。
4 gce_instance リソースタイプは、Kubernetes ノードと Kubernetes 以外の VM インスタンスを表す場合があります。GKE 用 Cloud Operations にアップグレードすると、ノード関連での使用時は新しいリソースタイプ k8s_node を使用するように変更されます。kubeletdockerkube-proxystartupscriptnode-problem-detector という名前のノードレベルのログも使用されます。
5 k8s_podk8s_cluster ノードには、以前の Logging と Monitoring のサポートにないログが含まれている場合があります。
Monitoring のみ:
gke_container (GKE コンテナ)

ラベル:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Logging のみ:
container (GKE コンテナ)

ラベル:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Monitoring と Logging:
k8s_container (Kubernetes コンテナ)

ラベル:
  cluster_name
  container_name
  metadata.system_labels.node_name3
  namespace_name
  pod_name
  project_id
  location2

Logging のみ::
gce_instance (Compute Engine VM インスタンス)4

ラベル:
  cluster_name
  instance_id
  project_id
  zone2
Monitoring と Logging
k8s_node4(Kubernetes ノード)

ラベル:
  cluster_name
  node_name
  project_id
  location2
 
(なし)
Monitoring と Logging:
k8s_pod5(Kubernetes ポッド)

ラベル:
  cluster_name
  namespace_name
  pod_name
  project_id
  location2

Logging のみ
gke_cluster(GKE_cluster)

ラベル:
  cluster_name
  project_id
  location

Monitoring と Logging:
k8s_cluster5(Kubernetes クラスタ)

ラベル:
  cluster_name
  project_id
  location

必要なご対応

ここでは、GKE 用 Cloud Operations でのリソースモデルの変更点と、以前のモニタリングとロギング構成に対する影響について具体的に説明します。

Cloud Operations for GKE にクラスタを移行するには、次の操作を行う必要があります。

  1. Logging と Monitoring の構成を特定する: 以前の Logging / Monitoring と Cloud Operations for GKE の間で変更された値を使用している Logging と Monitoring の構成を特定します。

  2. LoggingMonitoring の構成を更新する: Logging と Monitoring の構成を更新して、Cloud Operations for GKE で行われた変更を反映します。

  3. GKE クラスタ構成を更新する: Cloud Operations for GKE の設定を使用するように GKE クラスタを更新します。

以前の Logging / Monitoring と GKE 用 Cloud Operations の間でリソースモデルと logName が変更されているため、リソースモデルの変更を参照する Logging または Monitoring の構成も更新する必要があります。移行では、以下を含む Logging と Monitoring の構成の更新が必要になる場合があります。

  • カスタム ダッシュボード
  • チャート
  • グループのフィルタ
  • 通知ポリシー
  • ログシンク
  • ログの除外
  • Cloud Logging と Cloud Monitoring のログベースの指標

以前の Logging と Monitoring を使用したクラスタの識別

以前の Logging と Monitoring を使用しているプロジェクト内のクラスタを特定するには、2 つの方法があります。

  1. プロジェクトごとの gcloud コマンドライン ツールの使用

    次の gcloud コマンドを使用して、現在のプロジェクト内のすべてのクラスタに関する loggingServicemonitoringService の値を一覧表示します。

    gcloud container clusters list | tail +2 | while read name loc rest ; do echo $name ; gcloud container clusters describe $name --zone $loc | egrep 'loggingService|monitoringService' ; echo ; done
    

    コマンドからの出力が、次のテキストのように表示されます。

      cluster-1
      loggingService: logging.googleapis.com
      monitoringService: monitoring.googleapis.com
    
      cluster-2
      loggingService: logging.googleapis.com/kubernetes
      monitoringService: monitoring.googleapis.com/kubernetes
    
      cluster-3
      loggingService: logging.googleapis.com/kubernetes
      monitoringService: none
    

    クラスタの出力に loggingService: logging.googleapis.com または monitoringService: monitoring.googleapis.com が含まれている場合、クラスタは以前の Logging と Monitoring を使用しています。

    クラスタの出力に loggingService: logging.googleapis.com/kubernetes または monitoringService:monitoring.googleapis.com/kubernetes が含まれている場合、クラスタは Cloud Operations for GKE を使用しています。

  2. Cloud Monitoring の GKE クラスタ ダッシュボードの使用

    1. Cloud Monitoring GKE クラスタ ダッシュボードをクリックします。
    2. 以前の Logging と Monitoring を実行しているクラスタを確認する Google Cloud プロジェクトを含むワークスペースを選択します。
    3. ダッシュボードでクラスタのリストを表示します。以前の Logging と Monitoring を使用しているクラスタのみがダッシュボードに表示されます。

      たとえば、次のスクリーンショットでは、以前の Logging と Monitoring を使用する 4 つのクラスタがあります。

      以前のソリューションを使用したクラスタの表示。

モニタリング リソースの移行

コントロール プレーン バージョンが 1.15 以降の GKE クラスタで以前の Logging と Monitoring を使用している場合、クラスタの指標は以前の Monitoring と Cloud Operations for GKE の両方のリソースモデルで利用できます。つまり、クラスタを Cloud Operations for GKE に移行する前に、クラスタは新しいデータモデルを使用して指標の作成を開始します(追加費用はかかりません)。

2021 年 1 月以降、新しいリソースモデルの指標を参照するようにカスタム ダッシュボードとアラートが自動更新されます。独自の Cloud Monitoring 構成(カスタム ダッシュボード、アラート、グループ内のグラフ)を移行する場合は、新しいリソースモデルを反映するために各構成を更新する必要があります。

また、Terraform または他の Deployment Manager で構成を維持し、自動的に変更を同期させる場合にも、構成を移行する必要があります。

古いデータモデルの構成を特定する

Cloud Operations for GKE への移行の一環として更新する必要がある Cloud Monitoring の構成を確認するには、Kubernetes 移行ステータス ダッシュボードを表示します。

  1. Cloud Console で、[Monitoring] に移動します。

    [Monitoring] に移動

  2. Monitoring のナビゲーション パネルで [設定] をクリックし、[Kubernetes Migration Status] タブを選択します。

次のサンプル ダッシュボードは、1 つのアラート ポリシーを更新する必要があることを示しています。

移行ダッシュボードの表示

Cloud Monitoring の構成の更新

クラスタが GKE バージョン 1.15 以降を使用していて、以前の Monitoring を使用している場合は、両方のデータモデルに公開されます。この場合、構成を移行する方法が 2 つあります。

  • 構成のクローンを作成し、クローンを更新します。この方法では、既存のダッシュボード、アラート ポリシー、グループのコピーを作成し、そのコピーを新しいリソースモデルに移行します。これにより、古いデータモデルと新しいデータモデルを同時に使用して、クラスタで引き続き Monitoring を使用できます。たとえば、この方法では 2 つのダッシュボードがあり、元のダッシュボードでは元のリソースモデルを引き続き使用し、コピーしたダッシュボードでは新しいリソースモデルを使用します。

  • 影響を受ける構成を適切にアップグレードします。このオプションでは、Cloud Monitoring の新しいデータモデルにすぐに切り替えられます。

以降のセクションでは、ダッシュボードアラート ポリシーグループの構成を移行する手順について説明します。

選択するオプションを決定する際に考慮する考慮事項の 1 つは、どれくらいの量のモニタリング履歴を利用可能にするかです。現在、Cloud Monitoring はクラスタの 6 週間の履歴データを提供します。データモデルへの二重書き込みを開始する GKE クラスタのアップグレード後も、古いデータモデルにはクラスタの過去の指標が引き続き存在します。一方、新しいデータモデルには、アップグレード時から始まる指標のみが含まれます。

履歴データが不要な場合は、適用している構成をいつでも新しいデータモデルにアップグレードできます。過去のデータが重要な場合は、構成のクローンを作成し、新しいリソースモデル タイプを使用するようにクローンを更新します。

または、クラスタが両方のデータモデルに二重書き込みを開始してから 6 週間待つこともできます。6 週間が経過すると、両方のデータモデルに同じ履歴データが含まれるので、適用されている構成を更新して新しいデータモデルに切り替えることが可能です。

ダッシュボードの更新

ダッシュボードを表示するには:

  1. Cloud Console から、[Monitoring] に移動します。

    [Monitoring] に移動

  2. [ダッシュボード] を選択します。

ダッシュボードのクローンを作成してそのクローンを更新するには、次の手順を行います。

  1. クローンを作成するダッシュボードを見つけます。

  2. [ダッシュボードのコピー]()をクリックし、クローンを作成するダッシュボードの名前を入力します。

  3. 必要に応じて、新しいダッシュボードの構成を更新します。

ダッシュボードでチャートの定義を更新する手順は次のとおりです。

  1. 編集するグラフの [その他のグラフ オプション](⋮)をクリックします。

  2. [編集] を選択して [チャートの編集] パネルを開きます。

  3. リソースタイプと指標の名前を変更して、新しいデータモデルに変換します。必要に応じて [フィルタ] フィールドや [グループ条件] フィールドを更新することもできます。

アラート ポリシーの更新

アラート ポリシーを表示するには、次の手順を行います。

  1. Cloud Console から、[Monitoring] に移動します。

    [Monitoring] に移動

  2. [アラート] を選択します。

アラート ポリシーのクローンを作成して更新するには、次の手順を行います。

  1. [Policies] テーブルからクローンを作成するポリシーを選択します。

  2. [Copy] をクリックして、アラート ポリシーのコピー作成フローを開始します。

  3. 古いデータモデルの参照条件を編集して、リソースタイプと指標名を更新します。

    フローの最後のステップで、クローンしたポリシーの名前を入力できます。

適用されているアラート ポリシーを編集するには、次の手順を行います。

  1. [Policies] の表から、編集するポリシーを選択します。

  2. [Edit] をクリックしてポリシーを更新します。

  3. 古いデータモデルの参照条件を更新します。

グループの更新

Google Cloud Console ではグループのクローンを作成できないため、グループを複製するには、同じフィルタを使用して新しいグループを作成する必要があります。

グループ フィルタを使用すると、複数の方法で古いデータモデルを参照できます。

  • リソースタイプ - グループはフィルタ resource.type="gke_container" を定義することがあります。gke_container タイプは複数のタイプの GKE エンティティを参照できるため、実際に一致するリソースのタイプ(k8s_containerk8s_podk8s_node)にフィルタを更新する必要があります。複数のタイプを照合する場合は、OR 演算子で組み合わせた複数の句を使用したフィルタを定義します。

  • ラベル cloud_account - グループがフィルタ resource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>" を定義することがあります。個別のサポート終了の一環として、cloud_account メタデータ フィールドは使用できなくなりました。resource.labels.project_id ラベルの使用を検討してください。

  • ラベル region - グループがフィルタ resource.metadata.region="<var>REGION_NAME</<var>" を定義することがあります。新しいデータモデルでは、region メタデータ フィールドは使用できません。地理的位置に基づいて GKE エンティティを照合する場合は、resource.labels.location ラベルの使用を検討してください。

データモデル間の指標のマッピング

このセクションでは、古いデータモデルの指標を新しいデータモデルの指標にマッピングする方法について説明します。以下の表のように、古いデータモデルは 17 の指標を公開していました。一部の指標が複数の GKE エンティティ タイプに対応していたため、指標の変換に 17 を超えるマッピングが存在します。

指標をマッピングする場合は、次の点に留意してください。

  • 古い指標の接頭辞は container.googleapis.com/ です。新しい指標の接頭辞は kubernetes.io/ です。

  • 古いデータモデルでは、唯一のリソースタイプは gke_container です。リソースラベルの定義方法によっては、このリソースタイプは GKE ノードに対応する GKE コンテナ、Pod、システム デーモン、マシンを指す場合があります。

  • Monitoring API に対するクエリでは、次の表にない pod_idcontainer_name の組み合わせを使用できます。このようなクエリで返されるデータは未定義です。これらの未定義状態からマッピングは提供されません。

    GKE エンティティ タイプ フィルタ
    コンテナ pod_id != '' and container_name != ''
    pod_id は空の文字列ではなく、container_name は空の文字列ではありません。)
    Pod pod_id != '' and container_name == ''
    pod_id は空の文字列ではなく、container_name は空の文字列です。)
    システム デーモン pod_id == '' and container_name != 'machine'
    pod_id は空の文字列、container_namedocker-daemonkubeletspods のいずれかです。)
    マシン pod_id == '' and container_name == 'machine'
    pod_id は空の文字列、container_name は文字列 machine です。)

以下の表に、次の 3 つのマッピング タイプを示します。

  • 古いデータモデルと新しいデータモデルの直接マッピング。

  • 構成が必要なマッピング。

  • 新しいモデルに直接対応するものがない、古い指標のマッピング。

直接マッピング

次の指標は、古いデータモデルと新しいデータモデルの間で直接変換されます。

古い指標名 古い GKE エンティティ タイプ 新しい指標名 新しい GKE リソースタイプ
container/accelerator/
duty_cycle
コンテナ container/accelerator/
duty_cycle
k8s_container
container/accelerator/
memory_total
コンテナ container/accelerator/
memory_total
k8s_container
container/accelerator/
memory_used
コンテナ container/accelerator/
memory_used
k8s_container
container/accelerator/
request
コンテナ container/accelerator/
request
k8s_container
container/cpu/
reserved_cores
コンテナ container/cpu/
limit_cores
k8s_container リソースが pod の場合のマッピングについては、構成が必要なマッピングをご覧ください。
container/cpu/
usage_time
コンテナ container/cpu/
core_usage_time
k8s_container リソースが pod の場合のマッピングについては、構成が必要なマッピングをご覧ください。
container/cpu/
usage_time
システム デーモン node_daemon/cpu/
core_usage_time
k8s_node 古いデータモデルでは、
gke_container.container_namedocker-daemonkubeletspods のいずれかです。これらのフィルタ値は、新しいデータモデルのフィールド metric.component の値と一致します。
container/cpu/
utilization
コンテナ container/cpu/
limit_utilization
k8s_container
container/disk/
bytes_total
Pod pod/volume/
total_bytes
k8s_pod gke_container.device_name(Volume:config-volume)は、先頭に付加された Volume: を削除して、k8s_pod.volume_name(config-volume)に変換しています。
container/disk/bytes_used Pod pod/volume/
used_bytes
k8s_pod gke_container.device_name(Volume:config-volume)は、先頭に付加された Volume: を削除して、k8s_pod.volume_name(config-volume)に変換しています。
container/memory/
bytes_total
コンテナ container/memory/
limit_bytes
k8s_container
container/memory/
bytes_used
コンテナ container/memory/
used_bytes
k8s_container
container/memory/
bytes_used
システム デーモン node_daemon/memory/
used_bytes
k8s_node 古いデータモデルでは、
gke_container.container_namedocker-daemonkubeletspods のいずれかです。これらのフィルタ値は、新しいデータモデルのフィールド metric.component の値と一致します。
container/disk/
inodes_free
マシン node/ephemeral_storage/
inodes_free
k8s_node 古いデータモデルには、instance_id という乱数の ID があります。新しいデータモデルには、人が読める形式の名前 node_name があります。
container/disk/
inodes_total
マシン node/ephemeral_storage/
inodes_total
k8s_node 古いデータモデルには、instance_id という乱数の ID があります。新しいデータモデルには、人が読める形式の名前 node_name があります。
container/pid_limit マシン node/pid_limit k8s_node 古いデータモデルには、instance_id という乱数の ID があります。新しいデータモデルには、人が読める形式の名前 node_name があります。
container/pid_used マシン node/pid_used k8s_node 古いデータモデルには、instance_id という乱数の ID があります。新しいデータモデルには、人が読める形式の名前 node_name があります。
構成が必要なマッピング

次の指標は、いくつかの基本的な操作を使用して古いデータモデルから新しいデータモデルに変換します。

古い指標名 古い GKE エンティティ タイプ 新しい指標名 新しい GKE リソースタイプ
container/cpu/
reserved_cores
Pod SUM container/cpu/limit_cores
GROUP BY pod_name
k8s_container 古いデータモデルには、pod_id(UUID)があります。新しいデータモデルには、人が読める形式の名前 pod_name があります。
container/cpu/
usage_time
Pod SUM container/cpu/core_usage_time
GROUP BY pod_name
k8s_container 古いデータモデルには、pod_id(UUID)があります。新しいデータモデルには、人が読める形式の名前 pod_name があります。
container/disk/
bytes_total
コンテナ node/ephemeral_storage/
total_bytes
k8s_container gke_container.device_name は、/ または logs のいずれかです。これらの各値は新しい値と同じです。
container/disk/
bytes_used
コンテナ container/ephemeral_storage/
used_bytes
k8s_container gke_container.device_name は、/ または logs のいずれかです。新しい値を取得するため、これら 2 つの値は合算する必要があります。新しいデータモデルでは、/logs の値は別々に取得できません。
container/memory/
bytes_total
Pod SUM container/memory/limit_bytes
GROUP BY pod_name
k8s_container 古いデータモデルには、pod_id(UUID)があります。新しいデータモデルには、人が読める形式の名前 pod_name があります。
container/memory/
bytes_used
Pod SUM container/memory/used_bytes
GROUP BY pod_name
k8s_container 古いデータモデルには、pod_id(UUID)があります。新しいデータモデルには、人が読める形式の名前 pod_name があります。
新しいモデルに同等のものを含まないマッピング

次の指標には、新しいデータモデルに相当するものがありません。

Pod の CPU 使用率
古いデータモデルでは、各コンテナの CPU 上限に基づいたこの指標は、Pod 内のすべてのコンテナにわたる CPU 使用率の加重平均です。
新しいデータモデルでは、この値は存在せず、各コンテナの上限と使用率に基づいてクライアント側で計算する必要があります。
稼働率
古いデータモデルでは、この指標はコンテナが使用可能な時間の単位(単位: ms/s)を表す累積の指標です。常に使用可能なコンテナの場合、値は~1000ms/s です。
新しいデータモデルでは、この指標は、システムの各部分が問題なく中断された時間を報告する時間単位のゲージ指標です。

リソース グループの変更

独自のリソース グループを定義し、上記のリソースタイプの変更の表にある以前の Logging と Monitoring のいずれかのリソースタイプを使用する場合は、これらのタイプを対応する Cloud Operations for GKE のリソースタイプに変更します。リソース グループにカスタムグラフが含まれている場合は、これらも変更する必要があります。

ロギング リソースの移行

ロギング リソースを移行するには、次のセクションで説明する手順を行います。

ログエントリの内容の変更

GKE 用 Cloud Operations に更新すると、ログエントリの特定の情報が別の名前のフィールドに移動することがあります。これは、ログベースの指標、ログシンク、ログ除外で使用されるログクエリで発生することがあります。

次のログエントリの変更の表に、新しいフィールドとラベルを示します。概要は次のとおりです。

  • フィルタの logName フィールドを確認します。GKE 用 Cloud Operations のログエントリでは、ログ名に stdout または stderr が使用されていますが、以前の Logging と Monitoring では、コンテナ名など、さまざまな名前が使用されます。コンテナ名がリソースラベルとして使用される場合があります。
  • ログエントリの labels フィールドを確認してください。このフィールドに、metadata ログエントリ フィールドに含まれていた情報が含まれる可能性があります。
  • ログエントリの resource.labels フィールドを確認してください。新しいリソースタイプには追加のラベル値があります。
ログエントリの変更
(旧)以前の Logging と Monitoring のログエントリ (新)GKE 用 Cloud Operations のログエントリ
表の脚注:
1 リソースラベルは、特定のクラスタやノードなど、指標を生成する特定のリソースを表します。
2 labels フィールドは、GKE 用 Cloud Operations で新しいログエントリに表示されますが、以前の Logging と Monitoring のログエントリに表示される場合があります。GKE 用 Cloud Operations では、移行前の metadata ログエントリ フィールドの情報を保存するために、このエントリを使用しています。
ログエントリ リソース
resource.labels(リソースラベル1
ログエントリ リソース
resource.labels(リソースラベル1
ログエントリのメタデータ
labels(ログエントリのラベル2

ラベル(例)
  compute.googleapis.com/resource_name:
    "fluentd-gcp-v3.2.0-d4d9p"

  container.googleapis.com/namespace_name:
    "kube-system"

  container.googleapis.com/pod_name:
    "fluentd-gcp-scaler-8b674f786-d4pq2"

  container.googleapis.com/stream:
    "stdout"
ログエントリのメタデータ
labels

ラベル(例)
  k8s-pod/app:
    "currencyservice"

  k8s-pod/pod-template-hash:
    "5a67f17c"

ログの例:

コンテナ リソースタイプの変更:

赤い太字のテキストは、以前の Logging / Monitoring と GKE 用 Cloud Operations のリソースモデルの違いを示しています。

リソースモデル ログの例:
以前の Logging と Monitoring

{
  "insertId": "fji4tsf1a8o5h",
  "jsonPayload": {
    "pid": 1,
    "name": "currencyservice-server",
    "v": 1,
    "message": "conversion request successful",
    "hostname": "currencyservice-6995d74b95-zjkmj"
  },
  "resource": {
    "type": "container",
    "labels": {
      "project_id": "my-test-project",
      "cluster_name": "my-test-cluster",
      "pod_id": "currencyservice-6995d74b95-zjkmj",
      "zone": "us-central1-c",
      "container_name": "server",
      "namespace_id": "default",
      "instance_id": "1234567890"
    }
  },
  "timestamp": "2020-10-02T19:02:47.575434759Z",
  "severity": "INFO",
  "labels": {
    "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk",
    "container.googleapis.com/stream": "stdout",
    "container.googleapis.com/namespace_name": "default"
  },
  "logName": "projects/my-test-project/logs/server",
  "receiveTimestamp": "2020-10-02T19:02:50.972304596Z"
}
GKE 用 Cloud Operations

{
  "insertId": "mye361s5zfcl55amj",
  "jsonPayload": {
    "v": 1,
    "name": "currencyservice-server",
    "pid": 1,
    "hostname": "currencyservice-5b69f47d-wg4zl",
    "message": "conversion request successful"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "container_name": "server",
      "project_id": "my-test-project",
      "pod_name": "currencyservice-5b69f47d-wg4zl",
      "namespace_name": "onlineboutique",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"

    }
  },
  "timestamp": "2020-10-02T18:41:55.359669767Z",
  "severity": "INFO",
  "labels": {
    "k8s-pod/app": "currencyservice",
    "k8s-pod/pod-template-hash": "5b69f47d",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk"
  },
  "logName": "projects/my-test-project/logs/stdout",
  "receiveTimestamp": "2020-10-02T18:41:57.930654427Z"
}

クラスタ リソースタイプの変更:

赤い太字のテキストは、以前の Logging / Monitoring と GKE 用 Cloud Operations のリソースモデルの違いを示しています。

リソースモデル ログの例:
以前の Logging と Monitoring

{
  "insertId": "962szqg9uiyalt",
  "jsonPayload": {
    "type": "Normal",
    "involvedObject": {
      "apiVersion": "policy/v1beta1",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "resourceVersion": "50968",
      "kind": "PodDisruptionBudget",
      "namespace": "knative-serving",
      "name": "activator-pdb"
    },
    "apiVersion": "v1",
    "reason": "NoPods",
    "source": {
      "component": "controllermanager"
    },
    "message": "No matching pods found",
    "kind": "Event",
    "metadata": {
      "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe",
      "namespace": "knative-serving",
      "name": "activator-pdb.163a42fcb707c1fe",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "creationTimestamp": "2020-10-02T19:17:50Z",
      "resourceVersion": "1917"
    }
  },
  "resource": {
    "type": "gke_cluster",
    "labels": {
      "project_id": "my-test-project",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"
    }
  },
  "timestamp": "2020-10-02T21:33:20Z",
  "severity": "INFO",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:33:25.510671123Z"
}
GKE 用 Cloud Operations

{
  "insertId": "1qzipokg6ydoesp",
  "jsonPayload": {
    "involvedObject": {
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "name": "istio-telemetry",
      "apiVersion": "autoscaling/v2beta2",
      "resourceVersion": "90505937",
      "kind": "HorizontalPodAutoscaler",
      "namespace": "istio-system"
    },
    "source": {
      "component": "horizontal-pod-autoscaler"
    },
    "kind": "Event",
    "type": "Warning",
    "message": "missing request for cpu",
    "metadata": {
      "resourceVersion": "3071416",
      "creationTimestamp": "2020-08-22T14:18:59Z",
      "name": "istio-telemetry.162d9ce2894d6642",
      "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642",
      "namespace": "istio-system",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456"
    },
    "apiVersion": "v1",
    "reason": "FailedGetResourceMetric"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-test-project"
      "location": "us-central1-a",
      "cluster_name": "my-prod-cluster1",
    }
  },
  "timestamp": "2020-10-02T21:39:07Z",
  "severity": "WARNING",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:39:12.182820672Z"
}
   

ノード リソースタイプの変更:

赤い太字のテキストは、以前の Logging / Monitoring と GKE 用 Cloud Operations のリソースモデルの違いを示しています。

リソースモデル ログの例:
以前の Logging と Monitoring

{
  "insertId": "16qdegyg9t3n2u5",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
    [...]
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_GID": "0",
    "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042",
    "_SYSTEMD_UNIT": "kubelet.service",
    "_EXE": "/home/kubernetes/bin/kubelet"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "1234567890",
      "zone": "us-central1-a",
      "project_id": "my-test-project"
    }
  },
  "timestamp": "2020-10-02T21:43:14.390150Z",
  "labels": {
    "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr"
  },
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.433270911Z"
}
   
GKE 用 Cloud Operations

{
  "insertId": "kkbgd6e5tmkpmvjji",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
   [...]
    "_CAP_EFFECTIVE": "3fffffffff",
    "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy",
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_TRANSPORT": "stdout",
    "_GID": "0",
    "MESSAGE": "E1002 21:43:14.870346    1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\""
  },
  "resource": {
    "type": "k8s_node",
    "labels": {
      "cluster_name": "my-prod-cluster-1",
      "location": "us-central1-a",
      "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy"
       "project_id": "my-test-project",
    }
  },
  "timestamp": "2020-10-02T21:43:14.870426Z",
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.788933199Z"
}

ロギング構成の更新

このセクションでは、Cloud Operations for GKE への移行の一環として Cloud Logging の構成に必要な変更について説明します。また、Terraform または他の Deployment Manager で構成を維持し、自動的に変更を同期させる場合にも、構成を移行する必要があります。

ロギングクエリ

Cloud Logging でクエリを使用してログの検索とフィルタリングを行い、上記のリソースタイプの変更の表にある以前の Logging と Monitoring リソースタイプを使用している場合は、これらのタイプを対応する Cloud Operations for GKE のタイプに変更します。

たとえば、以前の Logging と Monitoring では、container リソースタイプを使用してコンテナログのクエリを行います。一方、Cloud Operations for GKE では、リソースタイプ k8s_container を使用してコンテナログのクエリを行います。

  resource.type="k8s_container"

もう 1 つの例として、以前の Logging と Monitoring では、コンテナの名前を使用してコンテナの特定のログ名のクエリを行いますが、Cloud Operations for GKE では stdout ログと stderr ログを使用してコンテナログのクエリを行います。

  resource.type="k8s_container"
  log_name="projects/YOUR_PROJECT_NAME/logs/stdout"
  resource.labels.container_name="CONTAINER_NAME"

ログベースの指標

独自のログベースの指標を定義し、上記の指標名の変更の表またはリソースタイプの変更の表にある以前の Logging と Monitoring の指標タイプまたはリソースタイプを使用している場合は、これらの指標とリソースタイプを対応する Cloud Operations for GKE のタイプに変更します。

次の gcloud ツールコマンドを使用すると、ログベースの指標を見つけることができます。

  gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging metrics list --filter='filter~resource.labels.namespace_id'

  gcloud logging metrics list --filter='filter~resource.labels.pod_id'

  gcloud logging metrics list --filter='filter~resource.labels.zone'

次の gcloud ツールコマンドを使用すると、ログベースの指標を更新できます。

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

また、ログベースの指標は、Cloud Console でも更新できます。

ログのエクスポート

ログをエクスポートし、エクスポートで上記のリソースタイプの変更の表にある以前の Logging と Monitoring のリソースタイプを使用する場合は、対応する Cloud Operations for GKE のリソースタイプを使用するようにエクスポートを変更します。Cloud Operations for GKE のログエントリでは、ログ名で stdout または stderr が使用されますが、以前の Logging と Monitoring ではコンテナ名が使用されます。

ログ名の変更に関しては、次に挙げる 2 つの重要な考慮事項があります。

  1. エクスポート先のファイルの場所とテーブルに関する変更 - Cloud Operations for GKE のログ名の値には、コンテナ名ではなく stdout または stderr が含まれます。コンテナ名がリソースラベルとして使用される場合があります。Cloud Storage エクスポートでのログ名の処理を行う、または BigQuery テーブルに対するクエリを行うには、stdoutstderr のログ名を使用する変更する必要があります。
  2. logName 値 - ログ名の値は、Cloud Storage にエクスポートされたファイル構造と BigQuery のテーブル構造を決定するために使用されます。Cloud Storage のファイルと BigQuery テーブルの使用量は、Cloud Storage のフォルダ構造と BigQuery のテーブル構造を考慮して調整する必要があります。

次の gcloud コマンドライン ツールコマンドを使用すると、影響を受ける Logging シンクを見つけることができます。

  gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging sinks list --filter='filter~resource.labels.namespace_id'

  gcloud logging sinks list --filter='filter~resource.labels.pod_id'

  gcloud logging sinks list --filter='filter~resource.labels.zone'

Logging シンクは、次の gcloud ツールコマンドを使用して更新できます。

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

また、ログベースの指標は、Cloud Console でも更新できます。

ログの除外

ログを除外し、除外フィルタで上記のリソースタイプの変更の表にある以前の Logging と Monitoring のリソースタイプを使用する場合は、対応する Cloud Operations for GKE のリソースタイプを使用するように除外フィルタを変更します。

ログの除外の表示については、除外フィルタの表示のガイドをご覧ください。

ログの保存場所の変更

Cloud Logging では、ログは生成元のリソースタイプで保存されます。これらのタイプは Cloud Operations for GKE で変更されています。ログを検索する場合は、GKE Container などの以前の Logging と Monitoring のタイプではなく、Kubernetes Container などの新しいリソースタイプを使用してください。

クラスタの構成を更新する

Cloud Operations for GKE のデータ形式を使用するために、ロギングモニタリング対象のリソースを移行した後の最後のステップは、GKE クラスタを更新して、Cloud Operations for GKE を使用できるようにすることです。

GKE クラスタのロギングとモニタリングの構成を更新する手順は次のとおりです。

Console

  1. プロジェクトの GKE クラスタのページに移動します。次のボタンで移動します。

    Kubernetes クラスタに移動

  2. Cloud Operations for GKE を使用するには、更新するクラスタをクリックします。

  3. [Cloud Operations for GKE] というラベルが付された行で、編集アイコンをクリックします。

  4. 表示されたダイアログ ボックスで、[Cloud Operations for GKE を有効にする] が選択されていることを確認します。

  5. このダイアログ ボックス内のプルダウン メニューで、収集するログと指標を選択します。Cloud Operations for GKE のデフォルト(推奨)設定は、[システムとワークロードのロギングとモニタリング] です。このプルダウン メニューで [以前の Logging と Monitoring] 以外の値を選択すると、以前の Logging と Monitoring ではなく Cloud Operations for GKE を使用するようにクラスタが更新されます。

  6. [変更を保存] をクリックします。

gcloud

  1. 次のコマンドを実行します。

    gcloud container clusters update [CLUSTER_NAME] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --enable-stackdriver-kubernetes
    

次のステップ