VictoriaMetrics+Prometheusで構築する複数Kubernetesの監視基盤

で構築する
複数Kubernetesの監視基盤
in CNDT 2020
CyberAgent, Inc.
Speakers: Riku Gemba, Katsuya Kawabe #CNDT2020_C

View Slide

AGENDA
1. 自己紹介
2. AKEの紹介と背景
3. VictoriaMetricsとPrometheus
4. 監視基盤のアーキテクチャ
5. 監視基盤の運用

View Slide

自己紹介
- 川部勝也
- CIU (CyberAgent group Infrastructure Unit) 所属
- インフラエンジニア
- 2020年新卒入社
- 趣味: カラオケ
- 源波陸
- CIU所属
- インフラエンジニア
- 2020年新卒入社
- 特技: マインスイーパー

View Slide

AGENDA
1. 自己紹介 ✔
2. AKEの紹介と背景
3. VictoriaMetricsとPrometheus

View Slide

AKE の紹介

View Slide

AKE の紹介
AKEについてより詳しく知りたい方は @makocchi, @amsy810 お二人の資料を漁ってください

View Slide

AKE のアーキテクチャ
AKE Client
master node node node
Pod Pod
Pod
Pod
Pod
Pod
Pod
Pod
Pod
Ingress
controller
Pod
Ingress
VM
external
network
VM

View Slide

✱ マネージドサービスとしての質を高めたい
✱ 監視ツールを用いて障害に即時対応
✱ 横断監視で Datadog を使用するのは、費用が高くなりやすい
✱ プロダクトが増えるごとにコストが増加する
✱ クラスタが増えればもっと増える
背景

View Slide

背景: 複数のDatadogで監視するメトリクスが重複
横断監視用Datadog
プロダクトAのメトリクスプロダクトBのメトリクス
プロダクトCのメトリクスプロダクトDのメトリクス
・・・
・・・
プロダクトAのDatadog
プロダクトAのメトリクス
プロダクトBのDatadog
プロダクトBのメトリクス

View Slide

背景: PrometheusとGrafana
Datadog のダッシュボードが横断監視用とプロジェクト用で乱立し、
費用が高くなる、同じメトリクスを二つのAPIキーで
送信しなければならないといった問題が発生する
Prometheus と Grafana を用いれば、
横断監視しつつ、ダッシュボードをプロダクト毎に払い出すことができる

View Slide

AGENDA
1. 自己紹介 ✔
2. AKEの紹介と背景 ✔
3. VictoriMetricsとPrometheus

View Slide

VictoriaMetrics と Prometheus

View Slide

こいつは何者？
VictoriaMetrics と Prometheus

View Slide

ログを永続化
Prometheus
Prometheusのみで横断監視する場合
Storage
PodやDeployment といったユーザの管理するリ
ソースから kubelet や kube-proxyといった
Kubernetesのコンポーネントも監視
Federation 機能を使って複数Prometheusのログを
集約可能

View Slide

ログを永続化
Prometheus
Storage
PodやDeployment といったユーザの管理するリ
ソースから kubelet や kube-proxyといった
Kubernetesのコンポーネントも監視
1サーバなのでいつか限界がくる

View Slide

Storage
Victoria
Metrics
メトリクスを永続化
Prometheusの収集したメトリクスを
さらに集約して永続化する機構

View Slide

VictoriaMetricsのアーキテクチャ
Load Balancer
vmselect vmselect
vmstorage vmstorage
vminsert vminsert
Load Balancer
図参考: https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Cluster-VictoriaMetrics
読み込みフロー:
Grafana や Prometheus からのクエリは vmselect が
vmstorage からデータを読み込み、マージして返す
vmselect はステートレス
書き込みフロー:
remote write や OpenTSDB の put protocol をサポート
ConsistentHash を用いて vmstorage への負荷分散を行う
vminsert はステートレス
実データを保存するストレージプロセス
データはファイルシステムにファイルとして保存される
ステートフル
・・・
・・・
・・・

View Slide

vmstorageのデータと対応ストレージ
vmstorage
データの実態は vmstorage が
動くマシンのファイルシステムに
保存される
つまり GCS や S3 を FUSEで
ファイルシステムとして
マウントすればバックエンドスト
レージとして使用可能
当然 NFS も使用可能

View Slide

VictoriaMetricsのデータ圧縮の工夫
✱ VictoriaMetrics独自の圧縮アルゴリズムを採用
✱ Gorilla(Prometheus や InfluxDB で使われている時系列DB)の圧縮手法より
node exporter のデータ圧縮率が10倍である
✱ 符号化したデータに更に zstd で圧縮をかけている
✱ Prometheus の Counter メトリクスをデルタ符号化で圧縮
参考: https://medium.com/faun/victoriametrics-achieving-better-compression-for-time-series-data-than-gorilla-317bc1f95932
https://hnakamur.github.io/blog/2017/02/12/tried-facebook-gorilla-time-series-database-compression/

View Slide

VictoriaMetricsのデータ圧縮の工夫
Gorilla による浮動小数点以下の圧縮 VictoriaMetrics による浮動小数点以下の圧縮
浮動小数点以下に 10^N を乗算し、整数化することで
ランレングス符号化やハフマン符号化による圧縮がより機能しやすくなる

View Slide

VictoriaMetricsによるデータ圧縮のパフォーマンス
画像出典: https://victoriametrics.com/
2TBのディスクに2年間保存できるサンプルの量は80万超
となっており、既存の時系列DBに比べて圧倒的。

View Slide

競合のOSS (Thanos, Cortex)

View Slide

✱ Cortex
✱ DynamoDB, Google Bigtable, Cassandra, S3, GCS, Microsoft Azure など
多様なストレージに対応
✱ HA対応のアーキテクチャ
✱ インメモリキャッシュによる高速なクエリの処理
✱ Helmで運用可能
✱ Thanos
✱ GCS, S3 にメトリクスを保存
✱ Prometheus のデータを ObjectStorage に保存する Gateway を冗長可能
✱ Operator, Helmで運用可能
競合のOSS (Thanos, Cortex)

View Slide

✱ Consul、Memcache、DynamoDB、BigTable、Cassandraなど多くのサードパー
ティソフトウェアに依存していて、アーキテクチャが複雑で運用負荷が高い
✱ Helmのチャートが新しいKubernetesのバージョンで動かなかったりする
✱ VictoriaMetricsに比べてCPU, Memory使用率が高い
✱ サンプルの圧縮率が低い
Why not Cortex
参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf

View Slide

✱ データ損失すると最大2時間分消失する可能性がある
✱ ThanosサイドカーをデプロイするのとPrometheusのデータ圧縮を無効化する必要
があり、Prometheusの性能を低下させてしまう可能性がある
✱ VictoriaMetricsよりCPU, Memoryを使用率が高い
Why not Thanos
参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf

View Slide

Why VictoriaMetrics
色々検証しましたが・・・

View Slide

Why VictoriaMetrics
✱ シンプルなアーキテクチャによる運用のしやすさ
✱ 高圧縮なアルゴリズム
✱ 必要十分な可用性、耐障害性、スケール性

View Slide

AGENDA
1. 自己紹介 ✔
2. AKEの紹介 ✔
3. VictoriMetricsとPrometheus ✔

View Slide

横断監視基盤の構成: メトリクスの書き込み
K8s Cluster
K8s Cluster
K8s Cluster
Load Balancer
vmselect vmselect
vmstorage vmstorage
vminsert vminsert
Load Balancer
・・・
・・・
・・・

View Slide

横断監視基盤の構成: クエリの実行
Load Balancer
vmselect vmselect
vmstorage vmstorage
vminsert vminsert
Load Balancer
・・・
・・・
・・・
vmalert
alertmanager
AKE
Developer
通知
可視化

View Slide

横断監視基盤の構成: メトリクスの書き込み
K8s Cluster
K8s Cluster
K8s Cluster
Load Balancer
vmselect vmselect
vmstorage vmstorage
vminsert vminsert
Load Balancer
・・・
・・・
・・・

View Slide

横断監視基盤の構成: よくあるクラスタ
Client

View Slide

横断監視基盤の構成: よくあるクラスタ
Client
LoadBalancer も監視したい

View Slide

AKE のアーキテクチャ
AKE Client
master node node node
Pod Pod
Pod
Pod
Pod
Pod
Pod
Pod
Pod
Ingress
controller
Pod
Ingress
VM
external
network
VM

View Slide

Ingress はクラスタに紐づくリソースだが、
実態のVMやプロセスがクラスタの外部に存在する
しかし、VM上で動作するプロセスやVMのパフォーマンスに関す
るメトリクスを Prometheus で監視したい
Ingress の監視

View Slide

横断監視基盤の構成: クラスタ内部の監視構成
kube-state-metrics
AKE Prometheus
node exporter
kube-proxy
kubelet
Core DNS
etcd
Pull
Ingress
VM VM
様々な
exporter
様々な
exporter

View Slide

横断監視基盤の構成: クラスタ内部の監視構成
kube-state-metrics
AKE Prometheus
node exporter
kube-proxy
kubelet
Core DNS
etcd
Pull
Ingress
VM VM
様々な
exporter
様々な
exporter
✱ どうやってIngress VMのIPアドレスをリ
ソースの作成に応じてディスカバリするのか
✱ VMはユーザによって減ったり増えたりする可能性もある

View Slide

✱ Prometheus のみではクラスタ外部に構成されている、ロードバランサの実態とし
て作成される複数のVMをディスカバリできない
✱ static_configs や file_sd_configs を使用すれば明示的にIPアドレスを指定でき
る
✱ static_configs や file_sd_configs を自動的に埋めたい
クラスタ外に立つリソースの監視手法

View Slide

✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている
✱ Operatorは static_configs, file_sd_configs を Secret で管理している
✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に
Ingress VM の Exporter の Job をPullすることができる
クラスタ内部の監視構成
これを実現する CronJob を実装すればやりたいことはできる！

View Slide

✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている
✱ Operatorは static_configs, file_sd_configs を Secret で管理している
✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に
Ingress VM の Exporter の Job をPullすることができる
これを実現する CronJob を実装すればやりたいことはできる！
Custom Controller に実装する手もあったが、責任の分
散と実装、デバッグのしやすさから CronJob を選択

View Slide


View Slide

Ingressの監視
static_configs が書かれたyamlの実態は
secretに格納されている

View Slide

Base64エンコードされたyamlを書き換える
元のSecret Data Ingress監視Jobを追加したSecret Data
Ingressの監視

View Slide

Ingressの監視: CronJobの動作
Ingress HeatStack
Resource
AKE
Prometheus
Secret
Services
Cronjob
1. Heatstack リソースを列挙
する
2. VM の IP を Heatstack リ
ソース毎に抽出する

View Slide

Ingress HeatStack
Resource
AKE
Prometheus
Secret
Services
Cronjob
3. PrometheusのSecretを取得する
4. Heatstack リソースごとに
static_configs の job を追加して、
Secret の data を更新する

View Slide

Ingress HeatStack
Resource
AKE
Prometheus
Secret
Services
Cronjob
5. Service を列挙して label から
AKE Prometheus を特定する

View Slide

Ingress HeatStack
Resource
AKE
Prometheus
Secret
Services
Cronjob
6. Service から Endpoint を指定し、
Prometheus のリロードAPIを叩く
POST or PUT
https://ake-prometheus.kube-system.svc.cluster.local:9090/-/reload

View Slide

✱ クラスタ毎の Prometheus と VictoriaMetrics によって横断監視を実現
✱ Kubernetesクラスタとは独立したロードバランサの監視は CronJob によって実現
横断監視基盤の構成

View Slide

余談: ingress-nginxに簡単なパッチを当てた話

View Slide

✱ NginxのプロセスはLuaスクリプトでリクエストのメトリクスをバッファリングしている
✱ その件数が1秒間最大1万件でハードコーディングされていた
✱ プロダクトではその数倍のリクエスト数が想定されていたのでオプション化
✱ Luaスクリプト書いたり、そのテストも書いたり
✱ 0.34.0以上で使えるようになってる
余談: ingress-nginxに簡単なパッチを当てた話

View Slide

KuberhealthyというOSSにもパッチを当てて
Kubernetes 1.16以上で動くようにしたのですが、
まだマージされていないので別の機会に・・・
余談: kuberhealthy

View Slide

AGENDA
1. 自己紹介 ✔
2. AKEの紹介と背景 ✔
3. VictoriaMetricsとPrometheus ✔
4. 監視基盤のアーキテクチャ ✔

View Slide

通知システムの構成
AKE
Developer

View Slide

Grafana Dashboard

View Slide

4. 横断監視基盤の構成: Kubernetes の監視
node exporter
kube-state-metrics
kubelet
Master Components
k8s Node Resources
のメトリクス
CPU, Memory, I/O, etc...
k8s Resources のメトリクス
deploy, sts, ds,
pod, pv, etc…
k8s Components
のメトリクス
kube-apiserver,
etcd, kubelet,
coredns, etc,...

View Slide

4. 横断監視基盤の構成: Ingressの監視
systemd exporter bird exporter
node exporter nginx metrics
Calicoやingress-nginxが
Dockerで正常に動いているか
BGPのPeer Linkが
正常に貼られているか
Ingress VMのCPUや
メモリのメトリクス
Ingress-nginxが持つ
リクエストやコネクション
のメトリクス

View Slide

✱ Critical
✱ 即時対応
✱ 業務時間外は PagerDuty による輪番制
✱ Warning
✱ 日中帯対応（休日含む）
✱ 業務時間外は PagerDuty による輪番制
✱ Informational
✱ 翌営業日対応
横断監視基盤の構成: アラート優先度

View Slide

✱ 1ヶ月あたり130GB
✱ クラスタ数 30+
✱ ノード数 200+
✱ ポッド数 3500+
✱ 必要ないメトリクスは可能な限り絞る
✱ exporter の起動オプションで指定可能
✱ --no-collector.hoge
VictoriaMetrics のメトリクスサイズ

View Slide

✱ Datadog を使用
✱ サードパーティの監視
✱ Dashboard とアラート設定
VictoriaMetrics を監視する

View Slide

✱ アラートしきい値
✱ 「実は異常が起こっていたが気づかなかった」は避けたい
✱ あとから調整していけばいいよね・・・
✱ 結果夜中に何度もたたきおこされる
✱ 監視が必要ないクラスタ
✱ むしろアラートがうるさい
✱ 検証クラスタを立てるたびに silence を入れるのは面倒
✱ アラート発砲させないオプションは必須 (隠し flag など)
監視基盤構築の苦労話 1, 2

View Slide

✱ 毎朝9時に大量のアラート
✱ 急激に VictoriaMetrics の負荷が上がってメトリクスが途切れる
✱ 多くのクラスタの Prometheus と疎通がとれず
✱ よくよく調べると vmstorage がメモリリークしていた...
監視基盤構築の苦労話 3

View Slide

✱ クラスタのアップデートで突然 Grafana のダッシュボードが消える
✱ AlertManager の silence も消えてアラートが鳴りまくる
✱ Grafana と AlertManager のストレージが pv になっておらず
pod のリスタートが走りデータが消失した
✱ 意図せず Grafana のバージョンが 7系にアップデートされる
監視基盤構築の苦労話 4

View Slide

本日のまとめ

View Slide

✱ Datadog にたよらず独自に横断監視を VictoriaMetrics と Prometheus で実現
することでプロダクトの増加による追加コストを抑えることができる
✱ VictoriaMetrics は Prometheus や InfluxDB より高圧縮かつ高速な読み書きの
ストレージを実現
✱ シンプルなアーキテクチャによって高可用性、耐障害性を持つ
✱ クラスタ外のエンドポイントの監視は CronJob でディスカバリする処理を動かす
✱ KaaS特有の監視項目を含めながら運用されている
まとめ

View Slide

Thank you for listening !

View Slide

VictoriaMetrics+Prometheusで構築する複数Kubernetesの監視基盤

VictoriaMetrics+Prometheusで構築する複数Kubernetesの監視基盤

Bo0km4n

More Decks by Bo0km4n

Other Decks in Programming

Featured

Transcript