Federationの良い使い方、ダメな使い方 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

federationは何の役に立つか?

Prometheusのfederationには様々な使い方があり得る。 監視をスケーラブルかつ信頼性があるようにするために、どのようにfederationを使うのが良いか見てみよう。

federationがよくあう一般的なケースが2つある。 それぞれ順番に見ていく。

Prometheusの階層構造

以前議論したように、Prometheusは、データセンターごとに少なくとも1つのインスタンスがあり、普通は全体のグラフ化とアラーティングのためのグローバルなPrometheusがあるように意図されている。 federationによって、階層構造の上に集約することが出来る。 その階層は、通常は2レベルからなるが、3、4レベルも全く聞かないわけではない。

例えば、全てのマシンのメモリ量合計をグローバルレベルに集約したいとする。

初めに、各データセンターのPrometheusのための設定ファイルの一部を示す。

global: 
  external_labels:
    datacenter: eu-west-1

rule_files:
  - node.rules

scrape_configs:
  etc.

external_labelsに着目すること。 ある組織内のPrometheusはそれぞれユニークなexternalラベルを持つべきである。

次にルールファイルnode.rulesでデータセンターレベルまで集約する。

job:node_memory_MemTotal:sum = sum without(instance)(node_memory_MemTotal{job="node"})

jobラベルのみが時系列に残されるので、プリフィックスjob:をとり、sumをしているので、:sumというサフィックスになっている。

グローバルなPrometheusの設定で、このメトリクスをpullする。

global:
  external_labels:
    datacenter: global  # 高可用性の構成では、ここは`global1`や`global2`になるだろう

scrape_configs:
  - job_name: datacenter_federation
    honor_labels: true
    metrics_path: /federate
    params:
      match[]:
        - '{__name__=~"^job:.*"}'
    static_configs:
      - targets:
        - eu-west-1-prometheus:9090

etc.

このmatch[]によってジョブレベルの時系列を取るようになっているので、この命名規約に従うことで、新しい集約ルールが出来るたびに設定を調整する必要がなくなる。

サービス間の集約

2つ目の一般的なユースケースは、同レベルのPrometheusから時系列をいくつかpullしたい場合である。 例えば、HAProxyのPrometheusとフロントエンドのPrometheus両方が同じ数のリクエストを通していることを確認したいだろう。

その設定は、上記の設定と似たものになるだろう。ただし、必要な時系列それぞれを明示的に名前で取得することになるだろう。 他の人のPrometheusを使うのは、保守性と安定性の観点で、ドキュメント化されていない内部ライブラリを使うのと似たことになりうる。 したがって、もし他のチームで運用されているPrometheusからpullするなら、まず彼らと話し合うのを忘れないように。

Grafanaは複数のデーターソース(Prometheusサーバー)が一つのグラフに利用されることをサポートしているので、このようなfederationは普通はアラートのためだけに行われるだろう。

federationが適さない場面

上記のどちらのケースでも、限られた集約済みの時系列を他のPrometheusからpullするためにfederationが利用されている。 そうしなければ、そのPrometheusがアラートを起こしたりグラフ化のためのクエリに答えたりする仕事をし続けなければならない。

federationが適していないのは、多くの種類の時系列(さらには全ての時系列)を他のPrometheusからpullしてアラートやグラフ化をする場合である。 これには、3つの理由がある。

1つ目は、パフォーマンスとスケーリングである。 Prometheusのパフォーマンスを制限する要因は、1つのマシンでどれぐらい処理できるかなので、全てのデータを1つのグローバルなPrometheusに送ることは、監視を1つのマシンで出来ることに制限することになる。 代わりに集約された時系列のみをpullすることで、グローバルなPrometheusのスケーリングに悩む必要なく新しいデータセンターを追加できるようになり、1つのデータセンターのPrometheusが処理できるものが制限になるだけである。 federationのリクエスト自体が受信側のPrometheusにとって重くなることもある。

2つ目は、信頼性である。 アラートするためのデータをあるPrometheusから他のPrometheusに移動すると、単一障害点を1つ増やしたことになる。 これは、インターネットのようなWANリンクが絡んでいるときには特にリスクがある。 アラートは、federationの階層構造のできる限り深いところに押えるようにするべきである。 例えば、監視対象がダウンしているというアラートは、そのターゲットをscrapeしているPrometheusで設定するべきであり、いくつかのステップが省けるグローバルなPrometheusでは設定してはいけない。

3つ目は、正確性である。 federationは、その仕組み上、データがscrapeされた後いくらか時間が経った後にpullするし、データの取り損ないもあり得る。 グラフ化とアラートのための多くの仕事をこなすのがデーターセンターのPrometheusサーバーであるように設定されている場合には、 グローバルのPrometheusにこのようなデータの不自然さがあっても一般的に許容できるが、全てをfederateしている場合には、問題が起きる可能性が高くなる。

これらの問題は、データーセンターとグローバルのPrometheus間に当てはまるだけではない。 scrapeをしているPrometheusから実質的な仕事をする他のPrometheusにデータをpullするためにfederaionを使って、Prometheusをある種のプロキシサーバーとして利用しようと試みた人もいる。 これには、上記の正確性のような問題がある。 このような状況にあることが分かったら、scrapeしているPrometheusにアラートとグラフ化をさせるか、proxy_urlを使って本当のプロキシサーバー経由でscrapeをすること。

関連ドキュメント

翻訳元

おすすめ書籍

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム