Kubernetesオブザーバビリティチュートリアル：メトリック収集と分析編
この記事は、Kubernetesで実行されるアプリケーションをあらゆる側面から監視する方法を解説する“Kubernetesオブザーバビリティチュートリアルシリーズブログ”の第2回です。
- ログのインジェストと分析編
- パフォーマンスとヘルスに関するメトリックの収集編
- Elastic APMを使ったアプリケーションパフォーマンス監視編
今回は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.ymltemplate: 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.ymltemplate: 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://
以下は、アプリケーションレポート画面のサンプルです。
以下は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台しかありませんでした。そのため、表示は以下のようになります。
ホストのインフラストラクチャーメトリック
Dockerインフラとメトリック（表ビュー）
Kubernetesインフラとメトリック
メトリックエクスプローラー
すぐに使えるKibanaのダッシュボード
Metricbeatには多彩な事前構築済みのKibanaダッシュボードがあり、コマンド1つでお使いのクラスターに追加できます。初期設定のまま使うことも、ニーズに応じてダッシュボードをカスタマイズするためのベースとして使うこともできます。以下は、今回のチュートリアル環境で収集したデータをわかりやすく表示するダッシュボードの例です。
ホスト
システム
Docker
Kubernetes
NGINX
MYSQL
まとめ
今回は、アプリケーションとKubernetesのメトリックをMetricbeatで収集する手順を紹介しました。 お使いのシステムやインフラストラクチャーの監視は、今日からはじめることができます。Elastic CloudでElasticsearch Serviceの無料トライルに登録して、あるいはElastic Stackをダウンロードして、ご自身でホストして導入してみましょう。
セットアップを完了したら、アップタイム監視を行ってホストのアベイラビリティを監視したり、Elastic APMを使ってホストで稼働するアプリケーションのインストルメンテーションを行うことができます。新たにメトリックのクラスターを完全統合して、包括的なオブザーバビリティを備えたシステムの確立を目指してみましょう。お困りのことや、ご質問がおありの場合はディスカッションフォーラムをご活用ください。活発なコミュニティが待っています。
次回のテーマは、Elastic APMを使ったアプリケーションパフォーマンス監視です。