Varbitという3つのエンコード方法を提供しています。使う時に適切なエンコード方法を指定できます。Deltaこの方法は一番シンプルな方法なので、圧縮率は一番低いです。timestampとmetric_valueをそのまま保存するではなく、delta値を保存する方法です。delta)ではなく、chunkの最初値との差分のdeltaです。そこで、indexからすぐ元の値を逆算することができます。メトリクスデータは元の値と比べて、delta値の方が小さいということで、値の表現必要なbit-widthがより小さくなり、データ圧縮できます。8のbit-widthの中にdelta値を表現できる最小bit-witdhを選択しています。ランダムアクセスのために、chunkの中に全てのサンプルは同じbit-widthでエンコードする必要ですが、異なるchunkは異なるbit-widthでエンコードすることが可能です。chunkのbit-widthはchunkヘッダに保存されています。chunkの途中に必要なbit-widthが高くなる場合には高いbit-widthでchunkを最初から再エンコードするか、新chunkにするかを行っています。ポイント3)chunk毎に異なるbit-widthでエンコードできるので、データが壊れる時にdelta値の変化は急に大きくになっても、そのchunkのみに影響することです。bit-widthで表現できます。DoubleDeltaDoubleDeltaはdelta値をもう一回deltaをするというイメージです。以下の式で計算しています。0delta値と比べて、double-delta値はもっと小さくなるので、表現に必要なbit-widthがより少なくなります。それ以外はDelta方法と同じです。indexから上の式ですぐ元の値を計算できるので、chunk内のランダムアクセスは可能ですね。Prometheusは定期的に収集ターゲットからメトリクスを取りに行くので、double-delta値がほどんと0になり、必要なbit-widthが0になります。DoubleDelta方法は平均1サンプルあたり3.3bytes必要で、圧縮率は約5倍です。現在、DoubleDeltaはデフォルトのエンコード方法として設定されています。Varbit上の二つのエンコード方法はchunk毎に別々のbit-widthでエンコードできますが、chunk内の全サンプルは同じbit-widthでエンコード必要です。Varbit方法はchunk内の各サンプルが異なるbit-widthでエンコードできるようになる方法です。名前からでもそういう意味ですね。Database」という論文から参考されていると書かれています。ExponentとMantissaの頭が同じです。8.625の64bitバイナリを見てみましょう。14.0625と8.625のXOR結果見てみましょう。00000000ということは、直前の値とXORした結果は以下の特徴があります。bitsを除いた残り部分です。011上の特徴がありますので、サンプルの値をそのまま保存する代わりに、以下のようなアルゴリズムでエンコードし、保存時に必要なデータ量が少なくなります。bitsデコードする時には、chunkの頭から順次に行う必要です。bitsからXOR結果を計算できます。XORの逆算はXORですので、前の値とXOR結果からXOR演算で現在値を計算できます。この方法は平均1サンプルあたり1.3bytes必要で、圧縮率は約12.3倍です。圧縮率は一番高いですが、chunk内のランダムアクセスはできないので、他の方式と比べて、エンコードとデコードコストがちょっと高くなります。考察AbemaTVにPrometheusを導入し、運用してみて多くのメリットを感じ、また楽しかったです。Kubernetesとの連携はすごいので、クラスタ内のサービスからメトリクスの取集するための設定はシンプルです。すべてのレベルのメトリクスの取集はPrometheusのみでも可能になっています。PromQLも使いやすいです。現在他のメンバーは自分でメトリクス追加・ダッシュボード作成までやっています。システム障害発生時にダッシュボードが事前に用意されていないデータを見たかったら、チームメンバーはすぐにクエリを書くことができます。Prometheusが利用するディスク量も少なかったです。上記のような色々なメリットがありましたが、もちろんこれから期待している事も存在しています。Prometheusが使用するメモリ周りです。現在Prometheusではメモリ内のchunk数を制限するための設定ができますが、オーバーヘッドやPromQLエンジンで使うメモリもあるので、必要なメモリ量の正確な数字がわかりません。chunkサイズの3倍ぐらい書かれていますが、そうではない場合もありました。実際はメモリ制限のissueもありました。次の期待はGolangのGCにもうちょっと優しくなることだと考えています。上のグラフを見てみると、OSから貰うメモリサイズは実際に利用しているサイズの3倍ぐらいでした。idleの量はかなり大きいです。そこで、将来のバージョンはメモリをもうちょっと節約して欲しいです。Prometheus内部のストレージなどについて説明しました。記事が長くなってしまいまして、申し訳ないですが、読んで頂きありがとうございました。何かご意見がありましたら、是非コメントを頂ければ嬉しいです。明日はshigemk2さんの記事で最後なんですが、是非読んでください。AbemaTVgrafanakubernetesmonitoringprometheusモニタリング監視nghialvCyberAgentの15新卒として入社した後,Amebaアプリ,FRESH!生放送チームのiOSエンジニアをやりました。現在はAbemaTVでサーバーエンジニアとして働いています。