ロギングとモニタリングの構成

GKE on Bare Metal には、クラウドベースのマネージド サービス、オープンソース ツール、サードパーティの商用ソリューションとの検証済みの互換性など、複数のクラスタ ロギングとモニタリング オプションがあります。このページでは、これらのオプションについて説明し、環境に適したソリューションを選択するための基本的なガイダンスを示します。

GKE on Bare Metal のオプション

GKE on Bare Metal には、ロギングとモニタリングのオプションが複数用意されています。

  • Cloud Logging と Cloud Monitoring。ベアメタル システム コンポーネントでデフォルトで有効になっています。
  • Prometheus と Grafana は Cloud Marketplace から入手できます。
  • サードパーティ ソリューションによる検証済みの構成。

Cloud Logging と Cloud Monitoring

Google Cloud Observability　は、Google Cloud の組み込みのオブザーバビリティ ソリューションです。フルマネージドのロギング ソリューション、指標の収集、モニタリング、ダッシュボード、アラートが提供されます。Cloud Monitoring は、クラウドベースの GKE クラスタと同様の方法で、GKE on Bare Metal クラスタをモニタリングします。

エージェントは、ロギングとモニタリングの範囲、収集する指標のレベルを変更するように構成できます。

  • ロギングとモニタリングのスコープは、システム コンポーネントのみ（デフォルト）、またはシステム コンポーネントとアプリケーションに設定できます。
  • 収集された指標のレベルは、最適化された指標のセット（デフォルト）または完全な指標に対して構成できます。

詳細については、このドキュメントの GKE on Bare Metal 用 Stackdriver エージェントの構成をご覧ください。

Logging と Monitoring は、簡単に構成でき、強力な、たった一つのクラウドベースのオブザーバビリティ ソリューションを提供します。GKE on Bare Metal でのみワークロードを実行する場合、または GKE と GKE on Bare Metal でワークロードを実行する場合には、Logging と Monitoring の使用を強くおすすめします。GKE on Bare Metal と標準のオンプレミス インフラストラクチャで実行されるコンポーネントがあるアプリケーションの場合は、アプリケーションのエンドツーエンドのビューのために、その他のソリューションも検討できます。

Prometheus と Grafana

Prometheus と Grafana は、Cloud Marketplace で入手可能な人気の高いオープンソース モニタリング サービスです。

  • Prometheus は、アプリケーションとシステムの指標を収集します。

  • Alertmanager は、複数の異なるアラート メカニズムを使用してアラートの送信を行います。

  • Grafana はダッシュボード ツールです。

Prometheus と Grafana は、それぞれの管理クラスタとユーザー クラスタで有効にできます。これらのプロダクトの使用経験があるアプリケーション チームには、Prometheus と Grafana をおすすめします。これらのプロダクトは、クラスタ内でアプリケーション指標を保持する運用チームや、ネットワーク接続が失われた場合のトラブルシューティングにもおすすめします。

サードパーティのソリューション

Google は、サードパーティのロギングおよびモニタリング ソリューション プロバイダと協力して、GKE on Bare Metal とサードパーティの製品がうまく連動するように支援しています。Datadog、Elastic、Splunk などの製品があります。今後もサードパーティの製品が検証され、追加される予定です。

GKE on Bare Metal でサードパーティのソリューションを使用する場合は、次のソリューション ガイドをご覧ください。

GKE on Bare Metal のロギングとモニタリングの仕組み

Cloud Logging と Cloud Monitoring は、新しい管理クラスタまたはユーザー クラスタの作成時に、各クラスタにインストールされ、起動されます。

Stackdriver エージェントには、クラスタごとに次のコンポーネントが含まれています。

  • Stackdriver Operator（stackdriver-operator-*）。クラスタにデプロイされた他のすべての Stackdriver エージェントのライフサイクルを管理します。

  • Stackdriver のカスタム リソース。 GKE on Bare Metal インストール プロセスで自動的に作成されるリソース。

  • GKE Metrics Agent（gke-metrics-agent-*）。各ノードから Cloud Monitoring に指標をスクレイピングする OpenTelemetry Collector ベースの DaemonSet。クラスタに関するより多くの指標を提供するために、node-exporter DaemonSet と kube-state-metrics デプロイメントも含まれています。

  • Stackdriver Log Forwarder（stackdriver-log-forwarder-*）。各マシンから Cloud Logging にログを転送する Fluent Bit DeamonSet。Log Forwarder は、ログエントリをノードにローカルでバッファリングして、最大 4 時間再送信します。バッファがいっぱいになるか、Log Forwarder が Cloud Logging API に 4 時間以上アクセスできない場合、ログは削除されます。

  • Anthos メタデータ エージェント（stackdriver-metadata-agent-）。Pod、Deployment、ノードなどの Kubernetes リソースのメタデータを Ops API の構成モニタリングに送信する Deployment。このデータを使用して、デプロイ名、ノード名、Kubernetes サービス名などでクエリを実行できるようにすることで、指標クエリが強化されます。

Stackdriver によってインストールされたエージェントは、次のコマンドを実行して確認できます。

kubectl -n kube-system get pods -l "managed-by=stackdriver"

このコマンドの出力は、次のようになります。

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Cloud Monitoring の指標

Cloud Monitoring によって収集される指標のリストについては、GKE on Bare Metal の指標を表示するをご覧ください。

GKE on Bare Metal 用の Stackdriver エージェントの構成

GKE on Bare Metal にインストールされた Stackdriver エージェントは、クラスタの問題の管理とトラブルシューティングを目的として、システム コンポーネントに関するデータを収集します。以降のセクションでは、Stackdriver の構成と動作モードについて説明します。

システム コンポーネントのみ（デフォルト モード）

Stackdriver エージェントはインストール時に、デフォルトでログと指標を収集するように構成されます。Google 提供のシステム コンポーネントのパフォーマンス詳細（CPU やメモリ使用率など）などのメタデータを収集します。管理クラスタ内のすべてのワークロード、およびユーザー クラスタでは、コンポーネントに kube-system、gke-system、gke-connect、istio-system、config-management-system 名前空間のワークロードが含まれます。

システム コンポーネントとアプリケーション

デフォルト モードでアプリケーションのロギングとモニタリングを有効にするには、アプリケーションのロギングとモニタリングを有効にするの手順に沿って行います。

最適化された指標（デフォルト指標）

デフォルトでは、クラスタで実行される kube-state-metrics Deployment は、最適化された一連の kube 指標を収集して Google Cloud Observability（旧称 Stackdriver）に報告します。

この最適化された一連の指標を収集するために必要なリソースは少ないため、全体的なパフォーマンスとスケーラビリティを向上させることができます。

最適化された指標を無効にする（推奨しません）には、Stackdriver カスタム リソースのデフォルト設定をオーバーライドします。

選択したシステム コンポーネントに Managed Service for Prometheus を使用する

Google Cloud Managed Service for Prometheus は Cloud Monitoring の一部であり、システム コンポーネントのオプションとして利用できます。Prometheus 向けのマネージド サービスのメリットは次のとおりです。

  • アラートや Grafana ダッシュボードを変更することなく、既存の Prometheus ベースのモニタリングを引き続き使用できます。

  • GKE と GKE on Bare Metal の両方を使用する場合、すべてのクラスタで同じ Prometheus Query Language（PromQL）を指標に使用できます。Google Cloud コンソールの Metrics Explorer で、[PromQL] タブを使用することもできます。

Managed Service for Prometheus の有効化と無効化

GKE on Bare Metal では、Prometheus 向けのマネージド サービスがデフォルトで有効になっています。

Managed Service for Prometheus を無効にするには:

  1. stackdriver という Stackdriver オブジェクトを編集のために開きます。

    kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

  2. enableGMPForSystemMetrics フィーチャー ゲートを追加して、false に設定します。

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

  3. 編集セッションを閉じます。

指標データを表示する

enableGMPForSystemMetrics を true に設定すると、以下のコンポーネントの指標は、Cloud Monitoring での保存方法とクエリの方法が異なる形式になります。

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet と cadvisor
  • kube-state-metrics
  • node-exporter

新しい形式では、PromQL または Monitoring Query Language（MQL）を使用して、前述の指標をクエリできます。

PromQL

PromQL クエリの例:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

MQL

MQL を使用するには、モニタリング対象リソースを prometheus_target に設定し、kubernetes.io/anthos の接頭辞を持つ指標名を使用して、指標名に接尾辞として Prometheus タイプを追加します。

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Managed Service for Prometheus を使用した Grafana ダッシュボードの構成

Managed Service for Prometheus の指標データで Grafana を使用するには、Grafana を使用したクエリの手順に沿って、Managed Service for Prometheus のデータをクエリするように Grafana データソースを認証および構成します。

サンプルの Grafana ダッシュボードは、GitHub の anthos-samples リポジトリで提供されています。サンプル ダッシュボードをインストールするには、次の手順を行います。

  1. サンプル JSON ファイルをダウンロードします。

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Grafana データソースを Managed Service for Prometheus と異なる名前で作成している場合は、すべての JSON ファイルの datasource フィールドを変更します。

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    [DATASOURCE_NAME] は、Prometheus frontend サービスを指す Grafana のデータソースの名前に置き換えます。

  3. ブラウザから Grafana UI にアクセスし、[Dashboards] メニューの [+ Import] を選択します。

    Grafana のダッシュボードのインポートに移動する。

  4. JSON ファイルをアップロードするか、ファイルの内容をコピーして貼り付けて、[読み込む] を選択します。ファイルの内容が正常に読み込まれたら、[インポートする] を選択します。必要に応じて、インポートする前にダッシュボードの名前と UID を変更することもできます。

    Grafana でのダッシュボードのインポート。

  5. GKE on Bare Metal とデータソースが正しく構成されていれば、インポートされたダッシュボードは正常に読み込まれます。たとえば、次のスクリーンショットでは、cluster-capacity.json によって構成されたダッシュボードを示します。

    Grafana のクラスタ キャパシティのダッシュボード。

参考情報

Managed Service for Prometheus の詳細については、以下をご覧ください。

Stackdriver コンポーネント リソースの構成

クラスタを作成すると、GKE on Bare Metal が Stackdriver カスタム リソースを自動的に作成します。カスタム リソースの仕様を編集して、Stackdriver コンポーネントの CPU リクエストとメモリ リクエストのデフォルト値と上限をオーバーライドできます。また、デフォルトの最適化された指標の設定を個別にオーバーライドすることもできます。

Stackdriver コンポーネントのデフォルトの CPU およびメモリのリクエストと上限をオーバーライドする

Pod 密度が高いクラスタでは、ロギングとモニタリングのオーバーヘッドが増加します。極端な場合、Stackdriver コンポーネントにより、CPU とメモリの使用率が上限に近いことが報告されるか、リソースの上限が原因の再起動が繰り返し発生することがあります。この場合、Stackdriver コンポーネントの CPU とメモリのリクエストおよび制限のデフォルト値をオーバーライドするには、次の手順を行います。

  1. 次のコマンドを実行して、コマンドライン エディタで Stackdriver カスタム リソースを開きます。

    kubectl -n kube-system edit stackdriver stackdriver

  2. Stackdriver カスタム リソースで、spec フィールドの下に resourceAttrOverride セクションを追加します。

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    resourceAttrOverride セクションは、指定したコンポーネントの既存のデフォルトの制限とリクエストをすべてオーバーライドします。次のコンポーネントは、resourceAttrOverride によってサポートされています。

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    サンプル ファイルは次のようになります。

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Stackdriver カスタム リソースに対する変更を保存するには、保存してコマンドライン エディタを終了します。

  4. Pod のヘルスチェックを行います。

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    正常な Pod のレスポンスは次のようになります。

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. コンポーネントの Pod 仕様を確認して、リソースが正しく設定されていることを確認します。

    kubectl -n kube-system describe pod POD_NAME

    POD_NAME は、変更した Pod の名前に置き換えます。例: gke-metrics-agent-4th8r

    レスポンスは次のようになります。

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

最適化された指標を無効にする

デフォルトでは、クラスタで実行される kube-state-metrics Deployment は、最適化された一連の kube 指標を収集して Stackdriver に報告します。追加の指標が必要な場合は、GKE on Bare Metal の指標のリストから代替指標を見つけることをおすすめします。

使用可能な代替措置の例を以下に示します。

無効な指標 代替措置
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

最適化された指標のデフォルト設定を無効にする（おすすめしません）には、次の手順を行います。

  1. コマンドライン エディタで Stackdriver カスタム リソースを開きます。

    kubectl -n kube-system edit stackdriver stackdriver

  2. optimizedMetrics フィールドを false に設定します。

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. 変更を保存してコマンドライン エディタを終了します。

指標サーバー

Metrics Server は、さまざまな自動スケーリング パイプラインに対するコンテナ リソース指標のソースです。Metrics Server は、kubelets から指標を取得し、Kubernetes Metrics API を介して公開します。これらの指標は、HPA と VPA により自動スケーリング開始の判断に使われます。Metrics Server は、アドオンリサイザーを使用してスケーリングされます。

Pod 密度の高さが原因で、ロギングとモニタリングのオーバーヘッドが大きくなりすぎている場合は、リソースの上限により Metrics Server が停止、再起動されることがあります。この場合は、gke-managed-metrics-server 名前空間の metrics-server-config ConfigMap を編集し、cpuPerNode と memoryPerNode の値を変更することで、指標サーバーにより多くのリソースを割り当てることができます。

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

ConfigMap の内容の例:

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

ConfigMap を更新したら、次のコマンドを使用して metrics-server Pod を再作成します。

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Logging と Monitoring の構成要件

GKE on Bare Metal を使用して Cloud Logging と Cloud Monitoring を有効にするための構成要件がいくつかあります。これらの手順は、Google サービスの有効化ページのLogging と Monitoring で使用するサービス アカウントの構成と、次のリストに含まれています。

  1. Cloud Monitoring Workspace は、Google Cloud プロジェクト内に作成する必要があります。これを行うには、Google Cloud コンソールで [Monitoring] をクリックし、ワークフローに従います。

  2. 次の Stackdriver API を有効にする必要があります。

  3. Stackdriver エージェントが使用するサービス アカウントに次の IAM ロールを割り当てる必要があります。

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

料金

Google Kubernetes Engine（GKE）Enterprise エディションのシステムログと指標は無料です。

GKE on Bare Metal クラスタでは、Google Kubernetes Engine（GKE）Enterprise エディションのシステムログと指標には次のものが含まれます。

  • 管理クラスタ内のすべてのコンポーネントのログと指標
  • ユーザー クラスタ内の次の名前空間のコンポーネントのログと指標: kube-system、gke-system、gke-connect、knative-serving、istio-system、monitoring-system、config-management-system、gatekeeper-system、cnrm-system

詳細については、Google Cloud Observability の料金をご覧ください。

Cloud Logging の指標のクレジットについては、販売担当者にお問い合わせください。