Google Kubernetes Engine（GKE）でのモニタリングとロギングのサポートには 2 つのオプションがあります。
以前の Logging と Monitoring: ドキュメントについては、以前の Monitoring と以前の Logging のページをご覧ください。
Cloud Operations for GKE: ドキュメントについては、Cloud Operations for GKE をご覧ください。
このページでは、これらの 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_id は metadata.system_labels の node_name になっています。2 zone は、このコンテナまたはインスタンスのロケーションを表します。location は、クラスタ マスターノードのロケーションを表します。
3 metadata.system_labels.node_name は、ロギングの k8s_container リソースタイプで使用できません。ログをノード名で検索することはできません。
4 gce_instance リソースタイプは、Kubernetes ノードと Kubernetes 以外の VM インスタンスを表す場合があります。GKE 用 Cloud Operations にアップグレードすると、ノード関連での使用時は新しいリソースタイプ k8s_node を使用するように変更されます。kubelet、docker、kube-proxy、startupscript、node-problem-detector という名前のノードレベルのログも使用されます。5 k8s_pod と k8s_cluster ノードには、以前の Logging と Monitoring のサポートにないログが含まれている場合があります。 |
||||
Monitoring のみ:
gke_container
（GKE コンテナ）ラベル:
container
（GKE コンテナ）
ラベル:
|
Monitoring と Logging:
k8s_container
（Kubernetes コンテナ）
ラベル:
|
|||
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 ポッド）
ラベル:
|
|||
Logging のみ
gke_cluster（GKE_cluster）
ラベル:
|
Monitoring と Logging:
k8s_cluster5（Kubernetes クラスタ）
ラベル:
|
|||
必要なご対応
ここでは、GKE 用 Cloud Operations でのリソースモデルの変更点と、以前のモニタリングとロギング構成に対する影響について具体的に説明します。
Cloud Operations for GKE にクラスタを移行するには、次の操作を行う必要があります。
Logging と Monitoring の構成を特定する: 以前の Logging / Monitoring と Cloud Operations for GKE の間で変更された値を使用している Logging と Monitoring の構成を特定します。
Logging と Monitoring の構成を更新する: Logging と Monitoring の構成を更新して、Cloud Operations for GKE で行われた変更を反映します。
GKE クラスタ構成を更新する: Cloud Operations for GKE の設定を使用するように GKE クラスタを更新します。
以前の Logging / Monitoring と GKE 用 Cloud Operations の間でリソースモデルと logName が変更されているため、リソースモデルの変更を参照する Logging または Monitoring の構成も更新する必要があります。移行では、以下を含む Logging と Monitoring の構成の更新が必要になる場合があります。
- カスタム ダッシュボード
- チャート
- グループのフィルタ
- 通知ポリシー
- ログシンク
- ログの除外
- Cloud Logging と Cloud Monitoring のログベースの指標
以前の Logging と Monitoring を使用したクラスタの識別
プロジェクト内のどのクラスタで引き続き以前の Logging と Monitoring を使用しているかを確認するには、Cloud Monitoring の GKE クラスタ ダッシュボードを使用します。
Cloud Monitoring GKE クラスタ ダッシュボードをクリックします。
選択した「指標のスコープ」に、以前の Logging と Monitoring を実行しているクラスタについて確認する Google Cloud プロジェクトが含まれていることを確かめます。
ダッシュボードでクラスタのリストを表示します。以前の 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 移行ステータス ダッシュボードを表示します。
-
Google Cloud コンソールで [Monitoring] を選択するか、次のボタンをクリックします。
Monitoring のナビゲーション パネルで [設定] をクリックし、[Kubernetes Migration Status] タブを選択します。
次のサンプル ダッシュボードは、1 つのアラート ポリシーを更新する必要があることを示しています。
Cloud Monitoring の構成の更新
クラスタが GKE バージョン 1.15 以降を使用していて、以前の Monitoring を使用している場合は、両方のデータモデルに公開されます。この場合、構成を移行する方法が 2 つあります。
構成のクローンを作成し、クローンを更新します。この方法では、既存のダッシュボード、アラート ポリシー、グループのコピーを作成し、そのコピーを新しいリソースモデルに移行します。これにより、古いデータモデルと新しいデータモデルを同時に使用して、クラスタで引き続き Monitoring を使用できます。たとえば、この方法では 2 つのダッシュボードがあり、元のダッシュボードでは元のリソースモデルを引き続き使用し、コピーしたダッシュボードでは新しいリソースモデルを使用します。
影響を受ける構成を適切にアップグレードします。このオプションでは、Cloud Monitoring の新しいデータモデルにすぐに切り替えられます。
以降のセクションでは、ダッシュボード、アラート ポリシー、グループの構成を移行する手順について説明します。
選択するオプションを決定する際に考慮する考慮事項の 1 つは、どれくらいの量のモニタリング履歴を利用可能にするかです。現在、Cloud Monitoring はクラスタの 6 週間の履歴データを提供します。データモデルへの二重書き込みを開始する GKE クラスタのアップグレード後も、古いデータモデルにはクラスタの過去の指標が引き続き存在します。一方、新しいデータモデルには、アップグレード時から始まる指標のみが含まれます。
履歴データが不要な場合は、適用している構成をいつでも新しいデータモデルにアップグレードできます。過去のデータが重要な場合は、構成のクローンを作成し、新しいリソースモデル タイプを使用するようにクローンを更新します。
または、クラスタが両方のデータモデルに二重書き込みを開始してから 6 週間待つこともできます。6 週間が経過すると、両方のデータモデルに同じ履歴データが含まれるので、適用されている構成を更新して新しいデータモデルに切り替えることが可能です。
ダッシュボードの更新
ダッシュボードを表示するには:
-
Google Cloud コンソールで [Monitoring] を選択し、
[ダッシュボード] を選択するか、次のボタンをクリックします。
ダッシュボードのクローンを作成してそのクローンを更新するには、次の操作を行います。
クローンを作成するダッシュボードを見つけます。
[ダッシュボードのコピー]（）をクリックし、クローンを作成するダッシュボードの名前を入力します。
必要に応じて、新しいダッシュボードの構成を更新します。
ダッシュボードでチャートの定義を更新する手順は次のとおりです。
編集するグラフの [その他のグラフ オプション]（⋮）をクリックします。
[編集] を選択して [チャートの編集] パネルを開きます。
リソースタイプと指標の名前を変更して、新しいデータモデルに変換します。必要に応じて [フィルタ] フィールドや [グループ条件] フィールドを更新することもできます。
アラート ポリシーの更新
アラート ポリシーを表示するには、次の操作を行います。
-
Google Cloud コンソールで [Monitoring] を選択し、notifications[アラート] を選択するか、次のボタンをクリックします。
アラート ポリシーのクローンを作成して更新するには、次の操作を行います。
[Policies] テーブルからクローンを作成するポリシーを選択します。
[Copy] をクリックして、アラート ポリシーのコピー作成フローを開始します。
古いデータモデルの参照条件を編集して、リソースタイプと指標名を更新します。
フローの最後のステップで、クローンしたポリシーの名前を入力できます。
適用されているアラート ポリシーを編集するには、次の手順を行います。
[Policies] の表から、編集するポリシーを選択します。
[Edit] をクリックしてポリシーを更新します。
古いデータモデルの参照条件を更新します。
グループの更新
Google Cloud Console ではグループのクローンを作成できないため、グループを複製するには、同じフィルタを使用して新しいグループを作成する必要があります。
グループ フィルタを使用すると、複数の方法で古いデータモデルを参照できます。
リソースタイプ - グループはフィルタ
resource.type="gke_container"を定義することがあります。gke_containerタイプは複数のタイプの GKE エンティティを参照できるため、実際に一致するリソースのタイプ（k8s_container、k8s_pod、k8s_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_idとcontainer_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_nameはdocker-daemon、kubelets、podsのいずれかです。）マシン 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_name は docker-daemon、kubelets、pods のいずれかです。これらのフィルタ値は、新しいデータモデルのフィールド 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_name は docker-daemon、kubelets、pods のいずれかです。これらのフィルタ値は、新しいデータモデルのフィールド 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:
container.googleapis.com/namespace_name:
container.googleapis.com/pod_name:
container.googleapis.com/stream:
|
ログエントリのメタデータlabelsラベル（例） k8s-pod/app:
k8s-pod/pod-template-hash:
|
|||
ログの例:
コンテナ リソースタイプの変更:
赤い太字のテキストは、以前の 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 CLI コマンドを使用すると、ログベースの指標を見つけることができます。
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 CLI コマンドを使用すると、ログベースの指標を更新できます。
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\"'
また、ログベースの指標は、Google Cloud コンソールでも更新できます。
ログのエクスポート
ログをエクスポートし、エクスポートで上記のリソースタイプの変更の表にある以前の Logging と Monitoring のリソースタイプを使用する場合は、対応する Cloud Operations for GKE のリソースタイプを使用するようにエクスポートを変更します。Cloud Operations for GKE のログエントリでは、ログ名で stdout または stderr が使用されますが、以前の Logging と Monitoring ではコンテナ名が使用されます。
ログ名の変更に関しては、次に挙げる 2 つの重要な考慮事項があります。
- エクスポート先のファイルの場所とテーブルに関する変更 - Cloud Operations for GKE のログ名の値には、コンテナ名ではなく
stdoutまたはstderrが含まれます。コンテナ名がリソースラベルとして使用される場合があります。Cloud Storage エクスポートでのログ名の処理を行う、または BigQuery テーブルに対するクエリを行うには、stdoutとstderrのログ名を使用する変更する必要があります。 - logName 値 - ログ名の値は、Cloud Storage にエクスポートされたファイル構造と BigQuery のテーブル構造を決定するために使用されます。Cloud Storage のファイルと BigQuery テーブルの使用量は、Cloud Storage のフォルダ構造と BigQuery のテーブル構造を考慮して調整する必要があります。
次の Google Cloud CLI コマンドを使用すると、影響を受ける 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 CLI コマンドを使用して更新できます。
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\"'
また、ログベースの指標は、Google Cloud コンソールでも更新できます。
ログの除外
ログを除外し、除外フィルタで上記のリソースタイプの変更の表にある以前の 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 クラスタのロギングとモニタリングの構成を更新する手順は次のとおりです。
コンソール
-
Google Cloud コンソールで [Kubernetes Engine] を選択し、[クラスタ] を選択するか、次のボタンをクリックします。
Cloud Operations for GKE を使用するには、更新するクラスタをクリックします。
[Cloud Operations for GKE] というラベルが付された行で、編集アイコンをクリックします。
表示されたダイアログ ボックスで、[Cloud Operations for GKE を有効にする] が選択されていることを確認します。
このダイアログ ボックス内のプルダウン メニューで、収集するログと指標を選択します。Cloud Operations for GKE のデフォルト（推奨）設定は、[システムとワークロードのロギングとモニタリング] です。このプルダウン メニューで [以前の Logging と Monitoring] 以外の値を選択すると、以前の Logging と Monitoring ではなく Cloud Operations for GKE を使用するようにクラスタが更新されます。
[変更を保存] をクリックします。
gcloud
次のコマンドを実行します。
gcloud container clusters update [CLUSTER_NAME] \ --zone=[ZONE] \ --project=[PROJECT_ID] \ --logging=SYSTEM,WORKLOAD \ --monitoring=SYSTEM
次のステップ
- ユーザー システムの観察で新しい Cloud Operations for GKE ダッシュボードを確認する。
- GKE ログの表示でログの表示方法を確認する。