2020年7月7日

Kubernetesオブザーバビリティチュートリアル：メトリック収集と分析編

この記事は、Kubernetesで実行されるアプリケーションをあらゆる側面から監視する方法を解説する“Kubernetesオブザーバビリティチュートリアルシリーズブログ”の第2回です。

今回はElasticオブザーバビリティを使い、KibanaのMetricsアプリでコンテナーメトリックをインジェスト、および分析します。

Kubernetesからメトリックを収集する

“移動する標的”であるKubernetesのログと同様、Kubernetesのメトリック収集にも課題があります。以下にその理由を挙げています。

Kubernetesは異なるホスト上でコンポーネントを実行するため、CPUやメモリ、ディスク使用量、ディスクとネットワークのI/Oなど、複数のメトリック収集によりそれらのホストを監視する必要がある。
一種のミニ仮想環境であるKubernetesコンテナーも、独自に一連のメトリックを生成する。
アプリケーションサーバーとデータベースは共にKubernetes podとして実行されるが、各テクノロジーはそれぞれ独自の方法で関連するメトリックをレポーティングする。

いくつものテクノロジーを使ってKubernetesでメトリックを収集する組織は少なくありません。しかしそれでは、Kubernetesデプロイの監視タスクが一層複雑なものとなってしまいます。その状況を打開するソリューションこそ、Elasticオブザーバビリティです。1つのツールだけを使ってログ、メトリック、APMデータを組み合わせ、一元的な可視性と分析を確立できます。

Metricbeatを使ったK8sメトリック収集

Filebeatと同様に、MetricbeatはKubernetesクラスターで稼働するpodのさまざまなメトリックと、Kubernetesクラスター自体のメトリックの収集を1つでこなせるコンポーネントです。Metricbeatモジュールを使えば、多様なソースからくるメトリックをすばやく簡単に収集し、ECS互換のイベントとしてElasticsearchにシッピングできます。ECS互換であることにより、ログやアップタイムデータ、APMデータとすぐに相関付けることが可能です。Metricbeatは、次の2つの方法でKubernetesに即時にデプロイできます。

Kubernetesのメトリックを収集する単体のpodとしてデプロイし、そのpodがkube-state-metricsを使用してクラスターレベルのメトリックを収集する。
DaemonSetがKubernetesホストごとに単体のインスタンスとしてMetricbeatをデプロイし、そのホストにデプロイされたpodのメトリックを収集する。Metricbeatはkubelet APIとインタラクトしてそのホストで稼働するコンポーネントを取得するほか、自動検知などさまざまなメソッドを使用してコンポーネントに問い合わせ、テクノロジー固有のメトリックを収集する。

はじめるまえに：このチュートリアル記事は、セットアップ済みのKubernetes環境が用意されていることを前提としています。以降のアクティビティを実行できるように、デモ用アプリケーションを入れたシングルノードのMinikube環境をセットアップする手順を解説したブログ記事もありますので、併せてご活用ください。

ホスト、Docker、Kubernetesのメトリックを収集する

YAML config $HOME/k8s-o11y-workshop/metricbeat/metricbeat.ymlに定義されている通り、各DaemonSetインスタンスはホスト、Docker、Kubernetesのメトリックを収集します。

システム（ホスト）メトリックの設定

system.yml: |-
  - module: system
    period:10s
    metricsets:
      - cpu
      - load
      - memory
      - network
      - process
      - process_summary
      - core
      - diskio
      # - socket
    processes: ['.*']
    process.include_top_n:
      by_cpu:5      # include top 5 processes by CPU
      by_memory:5   # include top 5 processes by memory
  - module: system
    period:1m
    metricsets:
      - filesystem
      - fsstat
    processors:
    - drop_event.when.regexp:
        system.filesystem.mount_point: '^/(sys|cgroup|proc|dev|etc|host|lib)($|/)'

Dockerメトリックの設定

docker.yml: |-
  - module: docker
    metricsets:
      - "container"
      - "cpu"
      - "diskio"
      - "event"
      - "healthcheck"
      - "info"
      # - "image"
      - "memory"
      - "network"
    hosts: ["unix:///var/run/docker.sock"]
    period:10s
    enabled: true

Kubernetesメトリックの設定

kubelet APIとの通信により、ホストにデプロイされたpodのメトリックも収集します。

kubernetes.yml: |-
  - module: kubernetes
    metricsets:
      - node
      - system
      - pod
      - container
      - volume
    period:10s
    host: ${NODE_NAME}
    hosts: ["localhost:10255"]
  - module: kubernetes
    metricsets:
      - proxy
    period:10s
    host: ${NODE_NAME}
    hosts: ["localhost:10249"]

Metricbeatモジュールとメトリックセットの背後にあるデータについて詳しくは、Metricbeatドキュメントに記載されています。

Kubernetesのステータスメトリックとイベントを収集する

Kubernetesのメトリックを収集するためにデプロイされるインスタンスは1つです。このインスタンスはkube-state-metrics APIと統合されており、Kubernetesが管理するオブジェクトのステータスの変化を監視します。以下は、configでstate_metrics収集を定義しているセクションです。$HOME/k8s-o11y-workshop/Metricbeat/Metricbeat.yml：

kubernetes.yml: |-
  - module: kubernetes
    metricsets:
      - state_node
      - state_deployment
      - state_replicaset
      - state_pod
      - state_container
      # Uncomment this to get k8s events:
      - event
    period:10s
    host: ${NODE_NAME}
    hosts: ["kube-state-metrics:8080"]

podの注釈を使ったMetricbeatの自動検知

Metricbeat DaemonSetのデプロイには、podで実行されるコンポーネントを自動検知し、固有のMetricbeatモジュールを適用してテクノロジー固有のメトリックを収集する機能があります。自動検知を有効化する方法の1つに、podの注釈を使用して適用すべきモジュールと、その他のモジュール固有の設定を示すやり方があります。Metricbeat configの以下のセクションが、Kubernetesベースの自動検知を有効化します。$HOME/k8s-o11y-workshop/metricbeat/metricbeat.yml：

metricbeat.autodiscover:
  providers:
   - type: kubernetes
     host: ${NODE_NAME}
     hints.enabled: true

このチュートリアルの事例で、ヒントベースの自動検知を活用しているコンポーネントは2つあります。

NGINX定義$HOME/k8s-o11y-workshop/nginx/nginx.yml

template:
  metadata:
    labels:
      app: nginx
    annotations:
      co.elastic.metrics/module: nginx
      co.elastic.metrics/hosts: '${data.host}:${data.port}'

MySQL定義$HOME/k8s-o11y-workshop/mysql/mysql.yml

template:
  metadata:
    labels:
      app: mysql
    annotations:
      co.elastic.metrics/module: mysql
      co.elastic.metrics/hosts: 'root:petclinic@tcp(${data.host}:${data.port})/'

ヒントベースの自動検知について詳しくは、Metricbeatドキュメントをご覧ください。

Prometheusスタイルでアプリケーションのメトリックを収集する

今回サンプルとして入れたSpring Boot petclinicアプリケーションは、アプリケーション固有のメトリックをすべてPrometheusによりスクレイピング可能な形式でエクスポーズします。http://:30080/metrics/Prometheusでこのアプリケーションのhttpエンドポイントに移動し、生の形式でメトリックがどのようにレポーティングされているか確認できます。しかしこのチュートリアルでは、Elasticコンポーネントだけを使用してすべてのオブザーバビリティニーズを満たすというポリシーを実現するべく、Metricbeatを使ってこれらのメトリックを収集します。

以下は、アプリケーションレポート画面のサンプルです。

Prometheusメトリック

以下はpetclinic YAML configのヒントの設定のうち、MetricbeatにPrometheusモジュールを使用してアプリケーション固有のメトリックを収集するよう指示している部分です。$HOME/k8s-o11y-workshop/petclinic/petclinic.yml：

template:
  metadata:
    labels:
      app: petclinic
    annotations:
      co.elastic.metrics/module: prometheus
      co.elastic.metrics/hosts: '${data.host}:${data.port}'
      co.elastic.metrics/metrics_path: '/metrics/prometheus'
      co.elastic.metrics/period:1m

一般論として、MetricbeatはPrometheusサーバー全体で強化、またはリプレースできます。すでにPrometheusサーバーをデプロイしている場合、MetricbeatはPrometheus Federation APIを使ってサーバーからメトリックをエクスポートできます。つまり複数のPrometheusサーバーとKubernetes名前空間およびクラスターにわたる可視性が確立され、PrometheusのメトリックをログやAPM、アップタイムイベントと相関付けることが可能になります。監視アーキテクチャーをシンプル化したい場合は、Metricbeatを使ってPrometheusメトリックを収集し、そのままElasticsearchにシッピングする方法が最適です。

メタデータエンリッチメント

Metricbeatで収集されたすべてのイベントは、以下のプロセッサーでエンリッチされています。$HOME/k8s-o11y-workshop/metricbeat/metricbeat.yml：

processors:
  - add_cloud_metadata:
  - add_host_metadata:
  - add_kubernetes_metadata:
  - add_docker_metadata:

エンリッチによってメトリックをホストやKubernetes pod、Dockerコンテナー、クラウドプロバイダーインフラストラクチャーのメタデータと相関付けたり、アプリケーションパフォーマンス監視データやログなど、パズルのピースとしてオブザーバビリティの全体像を完成させるピースとなる他の要素と相関付けることが可能になります。

Kibanaでメトリックを扱う

今回のチュートリアル通りにMetricbeatを設定すると、Metricsアプリの表示は下の画像のようになります。ぜひあちこちクリックしたり、確認してみてください。そして、Kibanaのどのページを開いても、検索のためのバーがあることにお気づきでしょうか？この検索バーは、干し草の山で1本の針を探す際にビューを絞り込んだり、拡大表示する上で最適な方法です。今回のチュートリアルでは、ホストが1台しかありませんでした。そのため、表示は以下のようになります。

ホストのインフラストラクチャーメトリック

Kibanaに表示されたホストのメトリック

Dockerインフラとメトリック（表ビュー）

データテーブルビューに表示されたホストのメトリック

Kubernetesインフラとメトリック

Kubernetesインフラストラクチャーとメトリック

メトリックエクスプローラー

KibanaのMetrics Explorer

すぐに使えるKibanaのダッシュボード

Metricbeatには多彩な事前構築済みのKibanaダッシュボードがあり、コマンド1つでお使いのクラスターに追加できます。初期設定のまま使うことも、ニーズに応じてダッシュボードをカスタマイズするためのベースとして使うこともできます。以下は、今回のチュートリアル環境で収集したデータをわかりやすく表示するダッシュボードの例です。

ホスト

Kibanaのホストメトリックダッシュボード

システム

Kibanaのシステムメトリックダッシュボード

Docker

KibanaのDockerメトリックダッシュボード

Kubernetes

KibanaのKubernetesメトリックダッシュボード

NGINX

KibanaのNGINXメトリックダッシュボード

MYSQL

KibanaのMYSQLメトリックダッシュボード

まとめ

今回は、アプリケーションとKubernetesのメトリックをMetricbeatで収集する手順を紹介しました。お使いのシステムやインフラストラクチャーの監視は、今日からはじめることができます。Elastic CloudでElasticsearch Serviceの無料トライルに登録して、あるいはElastic Stackをダウンロードして、ご自身でホストして導入してみましょう。

セットアップを完了したら、アップタイム監視を行ってホストのアベイラビリティを監視したり、Elastic APMを使ってホストで稼働するアプリケーションのインストルメンテーションを行うことができます。新たにメトリックのクラスターを完全統合して、包括的なオブザーバビリティを備えたシステムの確立を目指してみましょう。お困りのことや、ご質問がおありの場合はディスカッションフォーラムをご活用ください。活発なコミュニティが待っています。

次回のテーマは、Elastic APMを使ったアプリケーションパフォーマンス監視です。

検索AI企業

生成AI

検索

セキュリティ

オブザーバビリティ

ソリューション別

業界