Prometheus Meetup #3 参加の記録です。
Remote Write API と Thanos を活用したメトリクス永続化
ZLabには500以上(5~10Nodeが多め)のK8sクラスタがある。それぞれのクラスタにPrometheusがある。
ただし、永続化なし。また数週間で再作成。
Prometheusのメトリクスがノードの再作成時に失われてしまう課題があった。
180日を超える長期間のメトリクスを参照できるようにしたかった。
理想は、Prometheusは短期間のメトリクスを保持、メトリクスをオブジェクトストレージに保持
第一案
最初はCortexの利用を検討
アーキテクチャが複雑。オブジェクトストレージにメトリクスが保存されないため見送り
第二案
独自アダプターの開発
TSDBをForkし、オブジェクトストレージにChunkを保存するように修正
Remote Read/Write APIを利用
# 例
remote_write:
- url: xxxxxxxx
Remote Write APIの注意点
・API Endpointを複数指定しても、ラウンドロビンでの負荷分散はできない(受ける側で負荷分散する)
・エンドポイントがダウンすると、Prometheusがリトライするので、復帰してもやられてしまうことも
第三案
Thanos
Thanosのコンポーネント: Sidecar, Store, Query, Rule, Compact, Receive
Receiveとアダプターを組み合わせて、メトリクスをオブジェクトストレージに保存する
Receiveは複数並べて、ロードバランサーで負荷分散する
Thanos Receiveでメトリクスの冗長化もできる
Thanos Receiveの利用の注意点
ドキュメントが少ない
現状と今後の課題
・シンプルな環境においては設定したゴールをクリア
・500クラスタから受けられるようにするにはまだ工夫が必要
・複数のメトリクスが混在しないようにする
Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤
Victoria Metricsで1500億のDataPoint
コロプラのこれまでの構成: Single Tenant(ゲームタイトルごとにKubernetes環境がある)
Kubernetes: Prometheus = 1:1
負荷試験時に1/8, 1/4, 1/2, 1/1と負荷を順番にかけた時に、1/4の時点でPrometheusが死んだ
Prometheusが落ちないように、3rd-Party Productを検討
大規模環境のPrometheusのうち、TSDBへの直接アクセスでOOMが発生しやすくなっていた
Cortex, Thanos, M3DBなどを検討
Cortex: 複雑だったため見送り
Thanos: 当時の問題で通常の2倍近くメモリを消費していた(Prometheusに起因)ため、試したが見送り
M3DB: 構築コスト、学習コストが高かったため、試したが見送り
Victoria Metricsを最終的に採用！
アーキテクチャとしては、VMSelect, VMStorage, VMInsertの3つが構成要素
Scale Outも容易(VMStorageはScale InをするとDataLoss)
Consistent hashingと全StorageへのQueryへのSelect・Mergeによって、StorageのScale Outを可能にしている。
PrometheusがRead + Writeを行ってOOMが発生していた
→ PrometheusはRead(Scrape)に専念。データの集約はVictoriaMetricsに任せる。その役割分担がよく効いた
Victoria Metricsの課題
・VMStorageのScale Inが実質不可能
・Alert機能なし
・WebUI未実装
パラメータをいくつかチューニングしている(詳細は資料参考)
その他工夫
Memoryを多く使うため、スケジューリングを工夫してNodeを占有にした
Prometheusは落ちなくなったが、Grafanaは相変わらず重いまま
→ レンダリングの時間を減らすために、パネルを減らす
→ GPUの性能の良いPCを使う(!)
次世代のログ基盤 Grafana Lokiを始めよう！
Lokiはログの収集・可視化のツール
UIでのGrepもできる
Lokiのアーキテクチャ: ほぼCortexのアーキテクチャ
主要コンポーネント: Distributor, Ingester, Chunk Store, Querier, Table Manager
Lokiのコンポーネントはすべて一つのバイナリなのが特徴
マルチテナントにも対応
Prometail: Like Prometheus, but for logs.
後半はprometail.yamlの項目説明について説明(詳細は資料参照)
ログからアラートを生成
pipeline_stagesを定義する
他設定項目の説明が続くため、詳細は資料参照
感想
今回のテーマは、Prometheusのエコシステムということでしたが、Prometheusで解決できなかった課題を解決するための実践的な話題が多かったように感じました。
参加できてよかったです。
以上