本文の内容は、2021年2月16日にMateo Burilloが投稿したブログ(https://sysdig.com/blog/kubernetes-monitoring-prometheus/)を元に日本語に翻訳・再構成した内容となっております。
Prometheusによる監視は、DockerやKubernetesの監視として急速に利用されるようになってきています。このガイドでは、PrometheusでKubernetes監視を実装する方法を説明します。Prometheusサーバーとメトリクスエクスポーターのデプロイ、kub-state-metricsのセットアップ、それらのメトリクスのプルと収集、Alertmanagerを使ったアラートの設定、Grafanaを使ったダッシュボードの設定を学びます。これらを手動で行う方法だけでなく、Prometheusオペレータのような自動化されたデプロイ/インストール方法のいくつかを活用して行う方法も取り上げます。
このガイドでは：
- Prometheusとそのコアコンセプトの紹介
- Prometheusと他の監視ソリューションとの比較
- Prometheusのインストール方法
- Kubernetesサービスの監視
- Prometheusエクスポーター
- Kubernetesクラスターの監視
- Kubernetes内部サービス
- Kubernetesノード
- Kube Stateメトリクス
- Kubernetesコントロールプレーン
この記事を読まれた後は、Kubernetesの監視をより深く掘り下げる準備ができているでしょう。私たちのブログでの追加の読み物は、Kubernetesの内部でPrometheusスタックの追加コンポーネントを設定したり（Alertmanager、プッシュゲートウェイ、grafana、外部ストレージ）、Custom ResourceDefinitionsでPrometheusオペレーターを設定したり（PrometheusのKubernetesデプロイを自動化するために）、スケールさせる場合にPrometheusを使用する上での課題に備えたりするのに役立ちます。
Prometheusを使用して#Kubernetesクラスターを監視し、Kubernetesクラスターコンポーネント、デプロイされたマイクロサービス、アラート、ダッシュボードをカバーするフルスタックを構築します。 Click to tweet
PrometheusをKubernetesの監視に使う理由
2つの技術シフトが起こり、新しい監視フレームワークの必要性が生まれました。
- DevOps文化: DevOpsが登場する前は、監視はホスト、ネットワーク、サービスで構成されていました。現在では、開発者はCI/CDパイプラインへの関与が増え、多くの操作やデバッグを自分で行うことができるようになったため、インフラストラクチャーの有機的な一部としてアプリやビジネス関連のメトリクスを簡単に統合する能力を必要としています。監視は民主化され、よりアクセスしやすくなり、スタックの追加レイヤーをカバーする必要がありました。
- コンテナとKubernetes: コンテナベースのインフラストラクチャーは、ロギング、デバッグ、高可用性などの方法を根本的に変えており、監視も例外ではありません。膨大な数の揮発性のあるソフトウェアエンティティ、サービス、仮想ネットワークアドレス、公開されたメトリクスが突然現れたり消えたりするようになりました。従来の監視ツールは、これに対応するように設計されていません。
なぜ Prometheus がコンテナ環境に適したツールなのか？これら4つの特徴により、PrometheusはKubernetes監視のデファクトスタンダードとなりました。
- 多次元データモデル: このモデルは、Kubernetesがラベルを使用してインフラストラクチャーのメタデータをどのように整理するかに似た、キーと値のペアに基づいています。これにより、柔軟で正確な時系列データが可能になり、Prometheusのクエリ言語を強力にサポートします。
- アクセス可能なフォーマットとプロトコル: Prometheusメトリクスを公開することは、非常に簡単な作業です。メトリクスは、人間が読みやすく、わかりやすいフォーマットで、標準的なHTTPトランスポートを使用して公開されます。メトリクスが正しく公開されているかどうかは、Web ブラウザを使用して確認できます:
- サービスディスカバリー: Prometheusサーバは、アプリケーションやサービスがデータを放出することを気にする必要がないように、定期的にターゲットをスクレイピングする役割を担っています（メトリクスはプッシュされるのではなくプルされます）。これらのPrometheusサーバーは、スクレイピングターゲットを自動検出するためのいくつかの方法を持っています。中には、コンテナのメタデータをフィルタリングして一致させるように設定できるものもあり、エフェメラルなKubernetesのワークロードに最適です。
- モジュール式で可用性の高いコンポーネント: メトリクスの収集、アラート、グラフィカルな可視化などは、異なるコンポーザブルなサービスによって実行されます。これらのサービスはすべて冗長性とシャーディングをサポートするように設計されています。
Prometheusと他のKubernetes監視ツールとの比較
Prometheusは2016年中にバージョン1.0をリリースしているので、かなり最近の技術です。Prometheusが最初に登場した時には、豊富な試行錯誤された監視ツールが利用可能でした。では、Prometheusは、これらの他のベテランのモニタリング・プロジェクトと比べてどうでしょうか？
キー値 vsドット区切りディメンジョン: StatsD/Graphiteのようないくつかのエンジンは、ディメンションを表現するために明示的なドット区切りフォーマットを使用しており、効果的にラベルごとに新しいメトリクスを生成しています。
この方法は、高次元のデータ（メトリクスごとに多くの異なるラベルを含む）を公開しようとすると、煩雑になることがあります。また、柔軟性のあるクエリベースの集計も難しくなります。
10台のサーバがあり、エラーコードでグループ化したい場合を想像してみてください。キー値を使用すると、フラット・メトリクスを {http_code=”500″} で単純にグループ化できます。ドット区切りのディメンションを使用すると、式を使用して集約する必要がある独立したメトリクスが多数存在することになります。
イベントロギング vs. メトリクスレコーディング: InfluxDB / Kapacitor は Prometheus スタックに近いです。これらはラベルベースの次元性と同じデータ圧縮アルゴリズムを使用しています。しかし、Influxはナノ秒の時間分解能と、異なるイベントログをマージする機能のため、イベントロギングにはより適しています。Prometheusの方がメトリクス収集に適しており、それらを検査するためのより強力なクエリ言語を持っています。
ブラックボックス対ホワイトボックス監視: 以前に述べたように、Nagios/Icinga/Sensuのようなツールは、ホスト/ネットワーク/サービスの監視や古典的なsysadminタスクに適しています。例えば、Nagiosはホストベースです。マイクロサービスの状態について内部的な詳細を取得したい場合(別名ホワイトボックス監視)、Prometheusはより適切なツールです。
マイクロサービスとKubernetesモニタリングの課題
Kubernetes クラスターの監視には、信頼性の高い監視/アラート/グラフ化アーキテクチャーをデプロイするために解決しなければならない独自の課題があります。
コンテナの監視: 可視性
コンテナは軽量で、ほとんどが不変のブラックボックスであるため、監視に課題があります。
Kubernetes API と kube-state-metrics (これはネイティブに prometheus のメトリクスを使用しています) は、デプロイメントにおける望ましい/実行中のレプリカの数、unschedulableノードなど、Kubernetes の内部データを公開することで、この問題の一部を解決します。
Prometheusがマイクロサービスに適しているのは、メトリクスのポートを公開するだけで、あまり複雑にしたり、追加のサービスを実行したりする必要がないからです。多くの場合、サービス自体はすでに HTTP インターフェースを提示しており、開発者は /metrics のような追加パスを追加するだけです。
場合によっては、サービスが Prometheus のメトリクスを提供する準備ができておらず、それをサポートするためにコードを変更することができないこともあります。その場合は、サービスにバンドルされている Prometheus エクスポーターを、多くの場合、同じポッドのサイドカーコンテナとしてデプロイする必要があります。
動的監視: 変化と揮発性のあるインフラストラクチャー
前述したように、いつでもレポートを開始したり停止したりできるエフェメラルエンティティは、古典的でより静的なモニタリングシステムでは問題です。
Prometheus には、これに対処するためのいくつかの自動検出メカニズムがあります。このガイドに最も関連するものは以下の通りです。
Consul: サービスのディスカバリーと設定のためのツール。Consulは分散されており、利用可能性が高く、非常にスケーラブルです。
Kubernetes: KubernetesのSD構成では、KubernetesのREST APIからスクレイプターゲットを取得することができ、常にクラスターの状態と同期した状態を保つことができます。
Prometheus オペレータ: おなじみのKubernetesのラベルクエリーに基づいて監視対象のコンフィグレーションを自動的に生成する。このデプロイメントオプションについては後ほど取り上げます。
インフラストラクチャーの新しいレイヤーを監視する Kubernetesコンポーネント
Kubernetesを使用すると、物理ホストやサービスポートのような概念はあまり関係なくなります。マイクロサービスのパフォーマンス（複数のノードに分散した異なるポッドを使用）、ネームスペース、デプロイメントのバージョンなど、さまざまなグループ分けに基づいて監視を整理する必要があります。
PrometheusのラベルベースのデータモデルとPromQLを併用すれば、これらの新しいスコープに簡単に適応できます。
Prometheusを使ったKubernetesモニタリング：アーキテクチャーの概要
詳細は後ほど説明します。この図は、Kubernetesクラスターにデプロイしたい基本的なエンティティをカバーしています。
- Prometheus サーバーは、可能な限り多くのターゲット自動検出を必要とします。これを実現するためのオプションがいくつかあります：
- Prometheus Kubernetes SD (サービスディスカバリー)
- Prometheusオペレーターとそのカスタムリソース定義
- Consul SD
- Azure SD for Azure VM
- GCPインスタンス用のGCE SD
- AWS VM用のEC2 SD
- File SD
- アプリケーションのメトリクスとは別に、Kubernetesのサービス、ノード、オーケストレーションの状態に関連するメトリクスをPrometheusに収集させたいと考えています。
- 古典的なホスト関連のメトリクスのためのノードエクスポーター: cpu、mem、ネットワークなど。
- オーケストレーションとクラスターレベルのメトリクスのための Kube-state-metrics: デプロイメント、ポッドメトリクス、リソース予約など。
- Kubernetesコントロールプレーンのメトリクス：kubelet、etcd、dns、スケジューラなど。
- PrometheusはPromQLを使ってアラートをトリガーするルールを設定できます。 alertmanagerはアラートの通知、グループ化、抑制などの管理を担当します。
- AlertManagerコンポーネントは、アラート通知を配信するためのレシーバーとゲートウェイを設定します。
- Grafanaは、任意の数のPrometheusサーバーからメトリクスを引っ張ってきて、パネルやダッシュボードを表示することができます。
Prometheusのインストール方法
Prometheus をホストや Kubernetes クラスターにインストールするには、さまざまな方法があります。
- ホスト上で実行される単一のバイナリとして、学習、テスト、開発目的には適していますが、コンテナ化されたデプロイメントには適していません。
- Dockerコンテナとして、順番に、いくつかのオーケストレーションオプションを持っています。生のDockerコンテナ、Kubernetesデプロイメント/ステートフルセット、Helm Kubernetesパッケージマネージャ、Kubernetesオペレーターなど。
まずは、より自動化された手動のアプローチから始めてみましょう。
シングル→Dockerコンテナ→Helmチャート→Prometheusオペレーター
Prometheusのバイナリをホストに直接ダウンロードして実行することができます。
prometheus-2.21.0.linux-amd64$ ./prometheus ./prometheus level=info ts=2020-09-25T10:04:24.911Z caller=main.go:310 msg="No time or size retention was set so using the default time retention" duration=15d […] level=info ts=2020-09-25T10:04:24.916Z caller=main.go:673 msg="Server is ready to receive web requests."
これは、Prometheus の Web インターフェース (デフォルトではポート 9090) の第一印象を得るのに良いかもしれません。
より良いオプションは、コンテナ内にPrometheusサーバをデプロイすることです。
docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheusこのDockerコンテナをConfigMapから設定をマウントしたり、サービスを公開したり、複数のレプリカをデプロイしたりする適切なKubernetesデプロイオブジェクトに簡単に適応させることができることに注意してください。KubernetesにPrometheusをインストールする最も簡単な方法は、Helmを使用することです。
Prometheusコミュニティは、Prometheusとエコシステムを形成するさまざまなアプリケーションのインストールと設定を本当に簡単にするHelmチャートを管理しています。
Helmを使ってKubernetesクラスターにPrometheusをインストールするには、以下のコマンドを実行するだけです。
Prometheusのチャートリポジトリをhelmの設定に追加します：
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo add stable https://kubernetes-charts.storage.googleapis.com/ helm repo update
Prometheusをインストール：
# Helm 3 helm install [RELEASE_NAME] prometheus-community/prometheus # Helm 2 helm install --name [RELEASE_NAME] prometheus-community/prometheus
数秒後、クラスター内にPrometheusのポッドが見えるはずです。
NAME READY STATUS RESTARTS AGE prometheus-kube-state-metrics-66cc6888bd-x9llw 1/1 Running 0 93d prometheus-node-exporter-h2qx5 1/1 Running 0 10d prometheus-node-exporter-k6jvh 1/1 Running 0 10d prometheus-node-exporter-thtsr 1/1 Running 0 10d prometheus-server-0 2/2 Running 0 90m
ボーナスポイント: Helm chartはPrometheusと一緒にnode-exporter、kube-state-metrics、alertmanagerをデプロイしているので、すぐにノードやクラスターの状態の監視を始めることができます。
より高度で自動化されたオプションとして、Prometheus オペレーターを使用することができます。これはメタデプロイメント、つまり他のデプロイメントを管理し、高レベルのサービス仕様に従って設定や更新を行うデプロイメントと考えることができます。
PrometheusでKubernetesサービスを監視する方法
PrometheusのメトリクスはHTTP(S)を介してサービスによって公開され、他の類似のモニタリングソリューションと比較して、このアプローチにはいくつかの利点があります。
- サービスエージェントをインストールする必要がなく、ウェブポートを公開するだけです。Prometheusサーバーは定期的にスクレイプ（プル）するので、メトリクスのプッシュやリモートエンドポイントの設定を心配する必要がありません。
- いくつかのマイクロサービスはすでに通常の機能に HTTP を使用しており、その内部の Web サーバーを再利用して /metrics のようなフォルダを追加するだけです。
- メトリクスのフォーマット自体は人間が読みやすく、把握しやすいものです。あなたがマイクロサービスのコードのメンテナであれば、それほど複雑さや学習を必要とせずにメトリクスの公開を始めることができます。
Prometheusのメトリクスをゼロから公開するように設計されているサービスもあります（Kubernetesのkubelet、TraefikのWebプロキシ、Istioのマイクロサービスメッシュなど）。その他のサービスはネイティブには統合されていませんが、エクスポーターを使って簡単に適応させることができます。エクスポーターとは、サービスの統計情報を収集し、それをPrometheusのメトリクスに “変換 “してスクレイピングするサービスのことです。このガイドには両方の例があります。
まず、ベストケースシナリオからスタートしましょう：デプロイしようとしているマイクロサービスは、すでに Prometheus エンドポイントを提供しています。
Traefik はマイクロサービスやコンテナと緊密に統合できるように設計されたリバースプロキシです。Traefik の一般的なユースケースは、Ingress コントローラまたは Entrypoint です。これは、インターネットとクラスター内の特定のマイクロサービスとの間のブリッジです。
Traefik のインストールにはいくつかのオプションがあり、Kubernetes に特化したインストールガイドがあります。Prometheus サポートを使用したシンプルな Traefik デプロイメントをすぐに立ち上げて実行したい場合は、以下のコマンドを使用します。
helm repo add stable https://kubernetes-charts.storage.googleapis.com/ helm install traefik stable/traefik --set metrics.prometheus.enabled=true
Traefikポッドが起動したら、サービスIPを表示させます：
$ kubectl get svc k get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 100.64.0.1 <none> 443/TCP 99d traefik LoadBalancer 100.65.9.227 xxx.eu-west-1.elb.amazonaws.com 443:32164/TCP,80:31829/TCP 72m traefik-prometheus ClusterIP 100.66.30.208 <none> 9100/TCP 72m
Prometheus のメトリクスがサービス traefik-prometheus で公開されているかどうかは、どのコンテナでもシェルから curl を使うだけで確認できます。
$ curl 100.66.30.208:9100/metrics
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 2.4895e-05
go_gc_duration_seconds{quantile="0.25"} 4.4988e-05
...さて、新しいターゲットを prometheus.yml の conf ファイルに追加する必要があります。コマンドで確認してみましょう。
kubectl get cm prometheus-server -o yaml
Prometheusが自動的にスクレイプしていることに気づくでしょう：
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']もう一つ静的エンドポイントを追加してみましょう。
コマンドでファイルを編集します：
kubectl edit cm prometheus-server
そして、この新しいジョブを追加します。
- job_name: 'traefik'
static_configs:
- targets: ['traefik-prometheus:9100]サービスが別のネームスペースにある場合は、FQDN (例: traefik-prometheus.[ネームスペース].svc.cluster.local) を使用する必要があります。
もちろん、これは最低限の設定であり、スクレイプ設定は複数のパラメータをサポートしています。
いくつか挙げると：
- basic_auth と bearer_token : エンドポイントは HTTPS での認証を必要とすることがありますが、これには古典的なログイン/パスワードスキームやリクエストヘッダにベアラートークンを使用します。
- kubernetes_sd_configs または consul_sd_configs : 異なるエンドポイントの自動検出方法。
- scrape_interval、scrape_limit、scrape_timeout: 精度、回復力、システム負荷の間の異なるトレードオフ。
Prometheus Web インターフェースの /targets URL にアクセスすると、Traefik エンドポイント UP が表示されるはずです：
メインの Web インターフェイスを使用して、いくつかの traefik メトリクス (この例では Traefik フロントエンドやバックエンドが設定されていないため、非常に少数です) を見つけて、その値を取得することができます。
既にKubernetes上でのPrometheusの動作例があります。
設定で静的なターゲットを使用することに加えて、PrometheusはKubernetesで本当に興味深いサービスディスカバリーを実装しており、ポッドやサービスにこれらのメタデータをアノテーションするターゲットを追加することができます。
annotations: prometheus.io/port: 9216 prometheus.io/scrape: true
Prometheusを指定してポッドやサービスをスクレイプし、メトリクスを公開しているポートの情報を含める必要があります。
PrometheusエクスポーターでKubernetesサービスを監視する方法
いくつかのサービスやアプリケーションはすでに Prometheus メトリクス形式を採用しており、この目的のためのエンドポイントを提供していますが、Nginx や PostgreSQL のような多くの一般的なサーバアプリケーションは、Prometheus メトリクス / OpenMetrics の普及よりもはるかに古いものです。これらのアプリケーションは通常、独自のメトリクスフォーマットと公開方法を持っているため、それらからメトリクスを一つのペインに取得することを複雑にしています。
Prometheusメトリクスを使用して多くのマイクロサービスやホストにまたがるメトリクスパイプラインを統一しようとしている場合、これは問題になるかもしれません。
Prometheus エクスポーターの救済
このハードルを回避するために、Prometheus コミュニティは、Prometheus エクスポーターの膨大なコレクションを作成し、維持しています。エクスポーターは、サーバネイティブのメトリクス（またはサーバの動作を観察して独自のデータを生成）を収集し、Prometheus のメトリクス形式と HTTP プロトコルのトランスポートを使用して再発行することができる「トランスレータ」または「アダプター」プログラムです。
これらのエクスポーターの小さなバイナリは、監視しているメインサーバのサイドカーと同じポッドにデプロイすることもできますし、独自のポッドに分離することもできますし、別のインフラストラクチャーであっても構いません。
エクスポーターは、Prometheusのメトリクスに変換されたサービスメトリクスを公開しているので、エクスポーターをスクレイピングするだけで済みます。
PromCatでPrometheus エクスポーターのノイズをカットする
インターネット上には何百ものPrometheusエクスポーターがあり、それぞれのエクスポーターは、メトリクスを生成するアプリケーションと同様に異なっています。ほとんどの場合、アプリケーションにアクセスしてメトリクスを生成するためには、認証方法が必要です。これらの認証には、プレーンテキストの url 接続文字列から、証明書やアプリケーション内部の特別な権限を持つ専用のユーザーまで、さまざまな形があります。他のシナリオでは、例えば、ログやファイルを解析するためにアプリケーションと共有ボリュームをマウントする必要があるかもしれません。また、アプリケーションは、エクスポーターがデータを取得してメトリクスを生成できるようにするために、何らかのチューニングや特別な設定が必要になることもあります。
時々、同じアプリケーションに複数のエクスポーターが存在することがあります。これは、提供されている機能が異なっていたり、廃止されたプロジェクトがフォークされていたり、アプリケーションのバージョンが異なっていても、異なるエクスポータで動作していたりすることが原因であることがあります。モニタリングしたいアプリケーション、必要なメトリクス、そしてモニタリングソリューションに最適なアプローチを提供してくれる適切なエクスポーターを正しく識別することが重要です。
Sysdigは、これらのエクスポーターを見つけ、検証し、設定するために必要なメンテナンスの量を減らすために、PromCat.ioというサイトを作成しました。PromCat.ioでは、最適なエクスポータをキュレーションし、詳細な設定例を提供し、それらを使用したいお客様のサポートを提供しています。利用可能なPrometheusエクスポーターと統合の最新リストをチェックしてください。
ハンズオン：Prometheusを使ってKubernetesサービスとしてredisを監視する
ここでは、Kubernetes クラスターで稼働している Redis サーバを監視するために Prometheus エクスポーターを使用する方法を見てみましょう。
我々のデプロイの例を使って、Redis サーバーを含むポッドと一緒に Prometheus の sidecar コンテナをデプロイします：
# まだ、repoを持っていない場合は、repoをクローンします git clone [email protected]:mateobur/prometheus-monitoring-guide.git kubectl create -f prometheus-monitoring-guide/redis_prometheus_exporter.yaml
Redisポッドを表示すると、中に2つのコンテナが入っていることがわかります。
# kubectl get pod redis-546f6c4c9c-lmf6z NAME READY STATUS RESTARTS AGE redis-546f6c4c9c-lmf6z 2/2 Running 0 2m
あとはPrometheusの設定を更新して、前のセクションでやったようにリロードするだけです。
- job_name: 'redis'
static_configs:
- targets: ['redis:9121']Redis サービスのすべてのメトリクスを取得するには：
Prometheusとkube-state-metricsでKubernetesクラスターを監視する
クラスターにデプロイされたサービスを監視するだけでなく、Kubernetesクラスター自体を監視したい場合もあります。考慮すべきクラスター監視の3つの側面は以下の通りです：
- Kubernetesホスト(ノード): cpu、負荷、ディスク、メモリなどの古典的なsysadminのメトリクス。
- オーケストレーションレベルのメトリクス: デプロイメント状態、リソース要求、スケジューリング、APIサーバのレイテンシーなど。
- 内部のkube-systemコンポーネント: スケジューラー、コントローラマネージャー、DNSサービスなどの詳細なサービスメトリクス
Kubernetesの内部監視アーキテクチャは最近いくつかの変更を経験していますが、ここにまとめてみます。詳細については、その設計案を読むことができます。
Prometheusスタック上のKubernetes監視コンポーネント
cAdvisor はオープンソースのコンテナリソース使用量とパフォーマンス分析エージェントです。コンテナ用に作られており、Docker コンテナをネイティブにサポートしています。Kubernetesでは、cAdvisorはKubeletバイナリの一部として動作します。そのため、「ノードローカル」とDockerメトリクスを取得するアグリゲータは、Kubelet Prometheusのエンドポイントを直接スクレイプします。
Kub-state-metricsは、Kubeernetes APIサーバーをリッスンし、デプロイメント、ノード、ポッドなどのオブジェクトの状態に関するメトリクスを生成するシンプルなサービスです。ここで注意したいのは、kube-state-metricsは単なるメトリクスのエンドポイントであるということです。他のエンティティはそれをスクレイピングして長期保存を提供する必要があります (例: Prometheus サーバー)。
Metrics-server は、リソース使用量データのクラスタ全体のアグリゲータです。メトリクスサーバーは最後のデータポイントのみを提示し、長期保存を担当しません。
このように：
- Kub-stateのメトリクスは、デプロイ、ポッド、レプリカの状態など、オーケストレーションのメタデータに焦点を当てています。
- Metrics-serverはリソースメトリクスAPIの実装に注力しています。CPU、ファイルディスクリプタ、メモリ、リクエストレイテンシーなど。
PrometheusでKubernetesノードを監視する
Kubernetes ノードまたはホストを監視する必要があります。
Linuxホストを監視するためのツールはたくさんありますが、それらはKubernetes上で簡単に実行できるように設計されていません。
そこで、コンテナを念頭に置いて作られた Prometheus ノードエクスポーターを使用します：
- これはPrometheusプロジェクト自体がホストしています。
- Prometheus オペレーターの例では、これが自動的にデプロイされます。
- これは DaemonSet としてデプロイすることができ、クラスターにノードを追加したり削除したりすると自動的にスケーリングされます。
最も簡単なインストール方法は Helm を使うことです：
# add repo only needed if it wasn't done before helm repo add prometheus-community https://prometheus-community.github.io/helm-charts # Helm 3 helm install [RELEASE_NAME] prometheus-community/prometheus-node-exporter # Helm 2 helm install --name [RELEASE_NAME] prometheus-community/prometheus-node-exporter
チャートをインストールして稼働させると、スクレイピングが必要なサービスを表示することができます。
TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE node-exporter-prometheus-node-exporter ClusterIP 10.101.57.207 <none> 9100/TCP 17m
先ほどのようにスクレイプ設定を追加したら(PrometheusをHelmと一緒にインストールした場合は、アウトオブボックスなので何も設定する必要はありません)、ノードメトリクスの収集と表示を開始します。
Prometheus での kube-state-metrics の監視
kube-state-metrics をデプロイして監視するには、いくつかのステップを踏むだけです。
ここでも、以下のコマンドを使って直接デプロイすることも、Helmチャートを使ってデプロイすることもできます。Prometheus を Helm でインストールした場合、kube-state-metrics はすでにインストールされているので、このステップは省略できます。
git clone https://github.com/kubernetes/kube-state-metrics.git kubectl apply -f examples/standard ... # kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 13h kube-state-metrics ClusterIP 10.102.12.190 <none> 8080/TCP,8081/TCP 1h
Prometheusの設定で、そのサービス(ポート8080)をスクレイプする必要があります。今回はFQDNを使うことを忘れないでください：
- job_name: 'kube-state-metrics'
static_configs:
- targets: ['kube-state-metrics.kube-system.svc.cluster.local:8080']PrometheusでKubernetesのコントロールプレーンを監視する
コントロールプレーンはKubernetesの頭脳であり心臓部です。そのすべてのコンポーネントは、クラスターの適切な動作と効率性にとって重要です。Kubernetesのコントロールプレーンを監視することは、ノードや内部で実行されているアプリケーションの状態を監視するのと同じくらい重要です。コントロールプレーンに問題があると、すべてのアプリケーションに影響を与え、潜在的な停止を引き起こす可能性があるため、さらに重要になる可能性があります。
Prometheusを使用して内部パフォーマンスメトリクスを公開できるKubernetesコンポーネントがいくつかあります。詳細な手順や、推奨されるメトリクスやアラートについては、これらの他の記事をチェックしてください。
これらのプロセスを監視することは、2 つの特殊性を持つ他の Prometheus エンドポイントを監視するのと非常に似ています。
- これらのプロセスがリッスンするネットワークインターフェース、および http スキームとセキュリティ (HTTP, HTTPS, RBAC) は、デプロイメント方法と構成テンプレートに依存します。多くの場合、これらのサービスはホスティングノードの localhost でしか listen していないため、Prometheus ポッドからのアクセスが困難です。
- これらのコンポーネントにはポッドを指すKubernetesサービスがない場合もありますが、常に作成することができます。
デプロイ方法や構成によっては、Kubernetes サービスがローカルホストのみでリッスンしている場合があります。
次の例を簡単かつ集中的にするために、Minikubeを使用します。Minikubeを使用すると、ローカルのシングルノードKubernetes仮想マシンを数分でスポーンすることができます。
これはホスティングされたクラスター、GKE、AWSなどでも同様に動作しますが、設定を変更してサービスを再起動するか、追加のネットワークルートを提供するかのいずれかでサービスポートに到達する必要があります。
Minikubeをインストールするには、いくつかのコマンドを実行するだけです。まず、バイナリをインストールしてから、すべてのインタフェースで kube-scheduler サービスを公開するクラスターを作成します。
minikube start --memory=4096 --bootstrapper=kubeadm --extra-config=kubelet.authentication-token-webhook=true --extra-config=kubelet.authorization-mode=Webhook --extra-config=scheduler.address=0.0.0.0 --extra-config=controller-manager.address=0.0.0.0
あとは、kube-schedulerポッドを指すサービスを作成します：
kind: Service
apiVersion: v1
metadata:
name: scheduler-service
namespace: kube-system
spec:
selector:
component: kube-scheduler
ports:
- name: scheduler
protocol: TCP
port: 10251
targetPort: 10251これで、エンドポイントである scheduler-service.kub-system.svc.cluster.local:10251 をスクレイプすることができるようになります。
Prometheusのスケール
Prometheusを使った監視は、最初は簡単です。あっという間に複数のサービスのメトリクスやアラートを取得できます。しかし、何百ものマイクロサービスが内部で稼働し、異なる開発チームが同時にデプロイしている複数のクラスターを管理しなければならない場合に問題が発生します。
グローバルな可視性、高可用性、アクセス制御（RBAC）、セキュリティは、Prometheusに追加のコンポーネントを追加する必要がある要件であり、監視スタックははるかに複雑になります。
大規模でPrometheusを使用するには独自の課題があり、CortexやThanosのようなオープンソースのツールが多数存在し、ギャップを埋めて新機能を追加しています。
また、Sysdigのように、Prometheusを中心に構築されたエンタープライズソリューションを提供するベンダーのエコシステムもあります。
次は何をするのか？
ここまで、基本的なPrometheusのインストールと設定について説明してきました。しかし、これからは可視化とアラートを備えた完全な監視スタックの構築を始める時です。
一般的にPrometheusサービスと一緒にデプロイされる追加コンポーネントについて学び続けることをお勧めします。PromQL 言語を使用してメトリクスを集約し、アラートを発行し、可視化ダッシュボードを生成することを開始します。
私たちのブログでさらに読み進めていくと、Custom ResourceDefinitionsでPrometheusオペレータを設定し（PrometheusのためのKubernetesデプロイを自動化するため）、大規模でPrometheusを使用する課題に備えることができます。
また、これらの知識をPDF形式でまとめたKubernetesモニタリングガイドも興味深いものです。
このPromQLとPromCatの統合をすべて試してみたいと思いませんか？Sysdig MonitorはPrometheusと完全に互換性があり、セットアップは数分で完了します。