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

CNDT2020 Track Cで発表したスライドです

発表者: @gurapomu, @KKawabe108

Transcript

1. で構築する 複数Kubernetesの監視基盤 in CNDT 2020 CyberAgent, Inc. Speakers: Riku Gemba, Katsuya Kawabe #CNDT2020_C
2. AGENDA 1. 自己紹介 2. AKEの紹介と背景 3. VictoriaMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用
3. 自己紹介 - 川部 勝也 - CIU (CyberAgent group Infrastructure Unit) 所属 - インフラエンジニア - 2020年新卒入社 - 趣味: カラオケ - 源波 陸 - CIU所属 - インフラエンジニア - 2020年新卒入社 - 特技: マインスイーパー
4. AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 3. VictoriaMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用
5. AKE の紹介
6. AKE の紹介 AKEについてより詳しく知りたい方は @makocchi, @amsy810 お二人の資料を漁ってください
7. AKE のアーキテクチャ AKE Client master node node node Pod Pod Pod Pod Pod Pod Pod Pod Pod Ingress controller Pod Ingress VM external network VM
8. ✱ マネージドサービスとしての質を高めたい ✱ 監視ツールを用いて障害に即時対応 ✱ 横断監視で Datadog を使用するのは、費用が高くなりやすい ✱ プロダクトが増えるごとにコストが増加する ✱ クラスタが増えればもっと増える 背景
9. 背景: 複数のDatadogで監視するメトリクスが重複 横断監視用Datadog プロダクトAのメトリクス プロダクトBのメトリクス プロダクトCのメトリクス プロダクトDのメトリクス ・・・ ・・・ プロダクトAのDatadog プロダクトAのメトリクス プロダクトBのDatadog プロダクトBのメトリクス
10. 背景: PrometheusとGrafana Datadog のダッシュボードが横断監視用とプロジェクト用で乱立し、 費用が高くなる、同じメトリクスを二つのAPIキーで 送信しなければならないといった問題が発生する Prometheus と Grafana を用いれば、 横断監視しつつ、ダッシュボードをプロダクト毎に払い出すことができる
11. AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 ✔ 3. VictoriMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用
12. VictoriaMetrics と Prometheus
13. こいつは何者？ VictoriaMetrics と Prometheus
14. ログを永続化 Prometheus Prometheusのみで横断監視する場合 Storage PodやDeployment といったユーザの管理するリ ソースから kubelet や kube-proxyといった Kubernetesのコンポーネントも監視 Federation 機能を使って複数Prometheusのログを 集約可能
15. ログを永続化 Prometheus Prometheusのみで横断監視する場合 Storage PodやDeployment といったユーザの管理するリ ソースから kubelet や kube-proxyといった Kubernetesのコンポーネントも監視 1サーバなのでいつか限界がくる
16. Storage Victoria Metrics メトリクスを永続化 Prometheusの収集したメトリクスを さらに集約して永続化する機構 Prometheusのみで横断監視する場合
17. 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 はステートレス 実データを保存するストレージプロセス データはファイルシステムにファイルとして保存される ステートフル ・・・ ・・・ ・・・
18. vmstorageのデータと対応ストレージ vmstorage データの実態は vmstorage が 動くマシンのファイルシステムに 保存される つまり GCS や S3 を FUSEで ファイルシステムとして マウントすればバックエンドスト レージとして使用可能 当然 NFS も使用可能
19. 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/
20. VictoriaMetricsのデータ圧縮の工夫 Gorilla による浮動小数点以下の圧縮 VictoriaMetrics による浮動小数点以下の圧縮 浮動小数点以下に 10^N を乗算し、整数化することで ランレングス符号化やハフマン符号化による圧縮がより機能しやすくなる
21. VictoriaMetricsによるデータ圧縮のパフォーマンス 画像出典: https://victoriametrics.com/ 2TBのディスクに2年間保存できるサンプルの量は80万超 となっており、既存の時系列DBに比べて圧倒的。
22. 競合のOSS (Thanos, Cortex)
23. ✱ Cortex ✱ DynamoDB, Google Bigtable, Cassandra, S3, GCS, Microsoft Azure など 多様なストレージに対応 ✱ HA対応のアーキテクチャ ✱ インメモリキャッシュによる高速なクエリの処理 ✱ Helmで運用可能 ✱ Thanos ✱ GCS, S3 にメトリクスを保存 ✱ Prometheus のデータを ObjectStorage に保存する Gateway を冗長可能 ✱ Operator, Helmで運用可能 競合のOSS (Thanos, Cortex)
24. ✱ Consul、Memcache、DynamoDB、BigTable、Cassandraなど多くのサードパー ティソフトウェアに依存していて、アーキテクチャが複雑で運用負荷が高い ✱ Helmのチャートが新しいKubernetesのバージョンで動かなかったりする ✱ VictoriaMetricsに比べてCPU, Memory使用率が高い ✱ サンプルの圧縮率が低い Why not Cortex 参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf
25. ✱ データ損失すると最大2時間分消失する可能性がある ✱ ThanosサイドカーをデプロイするのとPrometheusのデータ圧縮を無効化する必要 があり、Prometheusの性能を低下させてしまう可能性がある ✱ VictoriaMetricsよりCPU, Memoryを使用率が高い Why not Thanos 参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf
26. Why VictoriaMetrics 色々検証しましたが・・・
27. Why VictoriaMetrics ✱ シンプルなアーキテクチャによる運用のしやすさ ✱ 高圧縮なアルゴリズム ✱ 必要十分な可用性、耐障害性、スケール性
28. AGENDA 1. 自己紹介 ✔ 2. AKEの紹介 ✔ 3. VictoriMetricsとPrometheus ✔ 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用
29. 横断監視基盤の構成: メトリクスの書き込み K8s Cluster K8s Cluster K8s Cluster Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・
30. 横断監視基盤の構成: クエリの実行 Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・ vmalert alertmanager AKE Developer 通知 可視化
31. 横断監視基盤の構成: メトリクスの書き込み K8s Cluster K8s Cluster K8s Cluster Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・
32. 横断監視基盤の構成: よくあるクラスタ Client
33. 横断監視基盤の構成: よくあるクラスタ Client LoadBalancer も監視したい
34. AKE のアーキテクチャ AKE Client master node node node Pod Pod Pod Pod Pod Pod Pod Pod Pod Ingress controller Pod Ingress VM external network VM
35. Ingress はクラスタに紐づくリソースだが、 実態のVMやプロセスがクラスタの外部に存在する しかし、VM上で動作するプロセスやVMのパフォーマンスに関す るメトリクスを Prometheus で監視したい Ingress の監視
36. 横断監視基盤の構成: クラスタ内部の監視構成 kube-state-metrics AKE Prometheus node exporter kube-proxy kubelet Core DNS etcd Pull Ingress VM VM 様々な exporter 様々な exporter
37. 横断監視基盤の構成: クラスタ内部の監視構成 kube-state-metrics AKE Prometheus node exporter kube-proxy kubelet Core DNS etcd Pull Ingress VM VM 様々な exporter 様々な exporter ✱ どうやってIngress VMのIPアドレスを リ ソースの作成に応じてディスカバリするのか ✱ VMはユーザによって減ったり増えたりする可能性もある
38. ✱ Prometheus のみではクラスタ外部に構成されている、ロードバランサの実態とし て作成される複数のVMをディスカバリできない ✱ static_configs や file_sd_configs を使用すれば明示的にIPアドレスを指定でき る ✱ static_configs や file_sd_configs を自動的に埋めたい クラスタ外に立つリソースの監視手法
39. ✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている ✱ Operatorは static_configs, file_sd_configs を Secret で管理している ✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に Ingress VM の Exporter の Job をPullすることができる クラスタ内部の監視構成 これを実現する CronJob を実装すればやりたいことはできる！
40. ✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている ✱ Operatorは static_configs, file_sd_configs を Secret で管理している ✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に Ingress VM の Exporter の Job をPullすることができる クラスタ内部の監視構成 これを実現する CronJob を実装すればやりたいことはできる！ Custom Controller に 実装する手もあったが、責任の分 散と実装、デバッグのしやすさから CronJob を選択
41. クラスタ内部の監視構成
42. Ingressの監視 static_configs が書かれたyamlの実態は secretに格納されている
43. Base64エンコードされたyamlを書き換える 元のSecret Data Ingress監視Jobを追加したSecret Data Ingressの監視
44. Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 1. Heatstack リソースを列挙 する 2. VM の IP を Heatstack リ ソース毎に抽出する
45. Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 3. PrometheusのSecretを取得する 4. Heatstack リソースごとに static_configs の job を追加して、 Secret の data を更新する
46. Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 5. Service を列挙して label から AKE Prometheus を特定する
47. Ingressの監視: CronJobの動作 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
48. ✱ クラスタ毎の Prometheus と VictoriaMetrics によって横断監視を実現 ✱ Kubernetesクラスタとは独立したロードバランサの監視は CronJob によって実現 横断監視基盤の構成
49. 余談: ingress-nginxに簡単なパッチを当てた話
50. ✱ NginxのプロセスはLuaスクリプトでリクエストのメトリクスをバッファリングしている ✱ その件数が1秒間最大1万件でハードコーディングされていた ✱ プロダクトではその数倍のリクエスト数が想定されていたのでオプション化 ✱ Luaスクリプト書いたり、そのテストも書いたり ✱ 0.34.0以上で使えるようになってる 余談: ingress-nginxに簡単なパッチを当てた話
51. KuberhealthyというOSSにもパッチを当てて Kubernetes 1.16以上で動くようにしたのですが、 まだマージされていないので別の機会に・・・ 余談: kuberhealthy
52. AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 ✔ 3. VictoriaMetricsとPrometheus ✔ 4. 監視基盤のアーキテクチャ ✔ 5. 監視基盤の運用
53. 通知システムの構成 AKE Developer
54. Grafana Dashboard
55. Grafana Dashboard
56. 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,...
57. 4. 横断監視基盤の構成: Ingressの監視 systemd exporter bird exporter node exporter nginx metrics Calicoやingress-nginxが Dockerで正常に動いているか BGPのPeer Linkが 正常に貼られているか Ingress VMのCPUや メモリのメトリクス Ingress-nginxが持つ リクエストやコネクション のメトリクス
58. ✱ Critical ✱ 即時対応 ✱ 業務時間外は PagerDuty による輪番制 ✱ Warning ✱ 日中帯対応（休日含む） ✱ 業務時間外は PagerDuty による輪番制 ✱ Informational ✱ 翌営業日対応 横断監視基盤の構成: アラート優先度
59. ✱ 1ヶ月あたり130GB ✱ クラスタ数 30+ ✱ ノード数 200+ ✱ ポッド数 3500+ ✱ 必要ないメトリクスは可能な限り絞る ✱ exporter の起動オプションで指定可能 ✱ --no-collector.hoge VictoriaMetrics のメトリクスサイズ
60. ✱ Datadog を使用 ✱ サードパーティの監視 ✱ Dashboard とアラート設定 VictoriaMetrics を監視する
61. ✱ アラートしきい値 ✱ 「実は異常が起こっていたが気づかなかった」は避けたい ✱ あとから調整していけばいいよね・・・ ✱ 結果夜中に何度もたたきおこされる ✱ 監視が必要ないクラスタ ✱ むしろアラートがうるさい ✱ 検証クラスタを立てるたびに silence を入れるのは面倒 ✱ アラート発砲させないオプションは必須 (隠し flag など) 監視基盤構築の苦労話 1, 2
62. ✱ 毎朝9時に大量のアラート ✱ 急激に VictoriaMetrics の負荷が上がってメトリクスが途切れる ✱ 多くのクラスタの Prometheus と疎通がとれず ✱ よくよく調べると vmstorage がメモリリークしていた... 監視基盤構築の苦労話 3
63. ✱ クラスタのアップデートで突然 Grafana のダッシュボードが消える ✱ AlertManager の silence も消えてアラートが鳴りまくる ✱ Grafana と AlertManager のストレージが pv になっておらず pod のリスタートが走りデータが消失した ✱ 意図せず Grafana のバージョンが 7系にアップデートされる 監視基盤構築の苦労話 4
64. 本日のまとめ
65. ✱ Datadog にたよらず独自に横断監視を VictoriaMetrics と Prometheus で実現 することでプロダクトの増加による追加コストを抑えることができる ✱ VictoriaMetrics は Prometheus や InfluxDB より高圧縮かつ高速な読み書きの ストレージを実現 ✱ シンプルなアーキテクチャによって高可用性、耐障害性を持つ ✱ クラスタ外のエンドポイントの監視は CronJob でディスカバリする処理を動かす ✱ KaaS特有の監視項目を含めながら運用されている まとめ
66. Thank you for listening !