Kubernetesの監視にPrometheusを使用する理由とその方法（後半）

Kubernetesの監視にPrometheusを使用する理由とその方法についての記事です。長い記事なので、前半と後半の２つに分けて投稿いたします。今回は後半です。

Prometheusにおける高カーディナリティへの対応

Graphiteには前述のような欠点がありますが、Prometheusと比較して、私たちが対処しなければならない2つの利点があります。まず、Graphiteは時系列をどれだけ細分化しても、階層構造の各葉がディスク上の独自のファイルに保存されるため、気にすることはないという点です。一方、Prometheusは、ある時系列のすべてのラベルを一緒に保存するため、「高カーディナリティ」、つまり時系列があまりにも多くの異なる値のラベルを持つ場合、パフォーマンスの問題が発生し、クラッシュすることもあります。そのため、Prometheusのメトリクスのカーディナリティには、Graphiteのときよりも注意する必要があるということです。

Prometheusでメトリックのカーディナリティを制限する3つのガイドライン

• サーバ固有のラベルを避ける — IPアドレスやノード名などの刹那的なデータをラベルとして使用することは避けています。なぜなら、これらは行ったり来たりしており、時間が経つと徐々に高いカーディナリティになることがあるからです。
• アプリケーション固有のラベルを避ける — 私たちは、雇用主、求職者、求人の名前やIDのような、高いカーディナリティのアプリケーション・データをメトリック・ラベルに使用することも避けています。
• ウェブデータのラベルをグループ化する — httpのステータスコードでも、メトリックラベルとして1桁目のみを使用するようにしています。3xxリダイレクト、4xxユーザーエラー、5xxサーバーエラーは追跡できますが、20種類ある特定のステータスコードのうち、どれを提供したかという詳細までは追跡しません。

私たちは、1つの指標について、その指標のすべてのラベルのカーディナリティの積を1000以下にすることを一般的な経験則としています。

この例では：

{host=$hostname, app=$appname, other=$thing}

ということは、（ホストネームの数 * アプリネームの数 * その他の数）< 1,000ということになります。

Prometheusで長い期間のメトリクスを保存するのはRAMを消費する

Graphiteの2つ目のメリットは、データが古くなるにつれて長い間隔でデータを集計し、長い期間にわたってメトリクスを保存するように設計されていることです。Prometheusにはこのような機能はありません。Prometheusは、一定のサンプリング周波数で一定時間データを保存し、それ以降の古いデータは削除されます。