Help us understand the problem. What is going on with this article?

Prometheus Meetup #3 参加報告

Prometheus Meetup #3 参加の記録です。

https://prometheus.connpass.com/event/157721/

Remote Write API と Thanos を活用したメトリクス永続化

https://speakerdeck.com/summerwind/using-thanos-as-a-long-term-storage-for-your-prometheus-metrics

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で作りあげる大規模・超負荷システムモニタリング基盤

https://speakerdeck.com/inletorder/monitoring-platform-with-victoria-metrics

Victoria Metricsで1500億のDataPoint

コロプラのこれまでの構成: Single Tenant(ゲームタイトルごとにKubernetes環境がある)
Kubernetes: Prometheus = 1:1

負荷試験時に1/8, 1/4, 1/2, 1/1と負荷を順番にかけた時に、1/4の時点でPrometheusが死んだ:cry:

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を始めよう!

https://speakerdeck.com/uesyn/prometheus-meetup-tokyo-3-lets-start-the-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で解決できなかった課題を解決するための実践的な話題が多かったように感じました。
参加できてよかったです。

以上

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした