業務で触れる機会のあったVictoraiMetricsというOSSを紹介します。
VictoraiMetricsとは
以前、Cortexアーキテクチャを紹介する際、Prometheus ServerのHA構成の問題点について紹介しました。
VictoriaMetricsも同様にPrometheus ServerのHA構成を実現できるOSSです。
Prometheus Serverのremote writeからメトリクスを取得し、ストレージに保存します。
VictoriaMetricsは主に、以下のコンポーネントで構成されます。
- vminsert
- Prometheus Serverからメトリクス取得する
- vmstorage
- メトリクスを保存するストレージ
- vmselect
- Grafana等からメトリクスを問い合わせる
構成
VictoriaMetricsは以下のような構成で使用します。
LBはk8s SVCでも可能です。
vmselect / vminsertはstalenessなので、スケールアウト/スケールインの双方が可能です。
一方、vmstorageはstatefulでスケールアウトは可能ですが、スケールインは原則不可となります。
VictoriaMetricsの機能
Multitenancy
VictoraiMetricsのURLフォーマットにある通り、accountID / projectIDを設定することが可能です。
例えば、prometheus-server-0とprometheus-server-1のメトリクスを明示的に区別したい場合、別accountIDを設定することでメトリクスを分けることができます。
accountIDとprojectIDはaccountID:projectIDの組み合わせで使用します。
(projectIDを指定しなかった場合、デフォルトで0になる）
Prometheus Serverのremote writeからaccountID: 0 / projectID: 0でメトリクスを保存する場合のURLは以下のようになります。
http://<vminsert>:8480/insert/0/prometheus
vmselectからaccountID: 0 / projectID: 0へメトリクス問い合わせを行う場合は以下のようなURLになります。
http://<vmselect>:8481/select/0/prometheus/query
Replication
vminsertの-replicationFactorというパラメータを設定すると、レプリケーションが有効になります。
vmstorage 3台に-replicationFactor=2を設定すると、メトリクスA / メトリクスBがそれぞれ別のvmstorageにコピーされます。
この場合、vmstorage 1台に障害が発生しても、データを損失しません。
-replicationFactor=3を設定するとすべてのvmstorageにメトリクスがコピーされます。
（もちろん、この場合はvmstorage 2台までの障害まではデータ損失が起きません）
トレードオフとして、高負荷やストレージ使用量増、Disk I/O増などが挙げられます。
この機能を使用した場合、vmselectでは-dedup.minScrapeInterval=1msを設定し、重複排除を行う必要があります。
Deduplication
vmstorage内でも重複排除機能を使用することができます。
先述したvmselectの重複排除とvmstorage内での重複排除が2つあるようなのですが、この章では後者の重複排除について紹介します。
（Replicationの仕組みと矛盾を感じる部分があるので、個人的には使用していない機能です。なので、紹介もざっくりです…）
-dedup.minScrapeIntervalというパラメータを使用して、重複排除を行います。
Prometheus Serverのexternal_labelsで設定したラベルが同一のものを重複排除の対象とします。
（おまけ）バックアップ
バックアップはvmbackupを使用して行うことができます。
まとめ
VictoraiMetricsというツールがあります！！
Crotex / Thanosに比べてシンプルな構成でPrometheus Serverが冗長化できます。
疑問点
Replicationとvmstorage内での重複排除を同時に行った場合、Replicationしたデータを消してしまわないのだろうか。