ロギングとモニタリングを構成する

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

ベアメタル版 Anthos クラスタのオプション

ベアメタル版 Anthos には、ロギングとモニタリングのオプションがいくつかあります。

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

Cloud Logging と Cloud Monitoring

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

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

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

詳細については、このドキュメントの Anthos clusters on bare metal の Stackdriver エージェントの構成をご覧ください。

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

Prometheus と Grafana

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

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

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

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

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

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

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

ベアメタル版 Anthos クラスタでサードパーティのソリューションを使用する場合は、次のソリューション ガイドをご覧ください。

ベアメタル版 Anthos クラスタのロギングとモニタリングの仕組み

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

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

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

  • Stackdriver のカスタム リソース。 ベアメタル版 Anthos クラスタ インストール プロセスで自動的に作成されるリソース。

  • 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 によって収集される指標のリストについては、Anthos clusters on bare metal の指標を表示するをご覧ください。

ベアメタル版 Anthos クラスタ用の Stackdriver エージェントの構成

Anthos clusters 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 のオペレーション スイート（旧 Stackdriver）に報告します。

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

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

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

クラスタを作成すると、Anthos clusters 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.sigs.k8s.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 に報告します。追加の指標が必要な場合は、Anthos clusters 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.sigs.k8s.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 が停止、再起動されることがあります。この場合、kube-system Namespace で metrics-server-config ConfigMap を編集し、cpuPerNode と memoryPerNode の値を変更することで、指標サーバーにより多くのリソースを割り当てることができます。

kubectl edit cm metrics-server-config -n kube-system

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 kube-system

Logging と Monitoring の構成要件

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

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

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

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

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

料金

Anthos システムのログと指標は無料です。

ベアメタル版 Anthos クラスタでは、Anthos システムのログと指標には次のものが含まれます。

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

詳しくは、Google Cloud のオペレーション スイートの料金をご覧ください。

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