Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Prometheus

1,359 views

Published on

Introduction of metric collecting and monitoring System Prometheus

Published in: Engineering
  • Be the first to comment

Prometheus

  1. 1. Prometheus
  2. 2. What is Prometheus?  時系列データを扱う監視システム  サービスの死活監視  パフォーマンスのモニタリング  競合監視システム  Ganglia  Graphite  Zabbix
  3. 3. What am I talking about?  Prometheusのコンポーネント  PromSQL + AlertManager周りの話  PrometheusのScalability
  4. 4. Componens
  5. 5. Components (of Ganesha) Time series database Dashboard scrape Alert Manager scrape & evaluate metrics alerting PushGateway scrape BurrowExporter GraphiteExporter CloudWatch Exporterr Service Discovery scrape Monitoring targets register NodeExporter scrape planting rules
  6. 6. planting rules Components (of Ganesha) Dashboard scrape Alert Manager scrape & evaluate metrics alerting PushGateway BurrowExporter GraphiteExporter CloudWatch Exporterr Service Discovery scrape register NodeExporter scrape Time series database Monitoring targets scrape  Push型ではなくPull型  各種Exporterがあるので 簡単な設定で様々な メトリクスが監視できる.  PushGatewayでmetricsの Pushも受けられる
  7. 7. planting rules scrape Monitoring targets Components (of Ganesha) Dashboard scrape Alert Manager scrape & evaluate metrics alerting PushGateway BurrowExporter GraphiteExporter CloudWatch Exporterr Service Discovery register NodeExporter scrape scrape Time series database  Consul経由で Container Serviceの 監視も楽  Registratorで簡単に Consul登録
  8. 8. scrape Monitoring targets Components (of Ganesha) Dashboard scrape Alert Manager scrape & evaluate metrics alerting PushGateway BurrowExporter GraphiteExporter CloudWatch Exporterr register NodeExporter scrape scrape Time series database Service Discovery planting rules consul-planterで consul KVに ルールを格納  consul-templateで Alert Managerに 埋め込み  発火するとSlackに アラートが飛ぶ
  9. 9. scrape Service Discovery planting rules scrape Monitoring targets Components (of Ganesha) Dashboard Alert Manager scrape & evaluate metrics alerting PushGateway BurrowExporter GraphiteExporter CloudWatch Exporterr register NodeExporter scrape Time series database scrape  Grafanaでカッコよくビジュアライズ!!
  10. 10. Summary of This Section  各種Exporterでいろんなソースから簡単に Metricsを取れる  ConsulやKubernetesとの連携でコンテナ監視も楽  Alert ManagerでSlack通知  consul-planterとconsul-templateでいい感じにconsul KV 連携してアラートルール管理してます.  Grafanaかっこいい
  11. 11. PromSQL & Alert Manager
  12. 12. Metrics in Prometheus  ラベルを使った多次元時系列データ topic=kafka-topic-v1 topic=kafka-topic-v2 Input records 0m 1m 2m 3m 4m ラベル
  13. 13. Metrics in Prometheus  Metricsの種類 (厳密には4種類あるらしいけど..)  Counter • 数の累積を取る.(KafkaのOffsetとか) • リセットされない限単調増加  Guage • 毎時変動する値 (メモリの使用量とか)  カスタムメトリクスを自前でExportするときは, この違いを意識しないとおかしなことになる.
  14. 14. What is PromSQL  多次元時系列Metricsを操作するための Prometheusの独自クエリ言語  Alert Ruleの設定や,Dashboardでの可視化に使う.
  15. 15. Instant Vector & Range Vector  Instant Vector  ある時刻の各ラベルのデータプロットのVector  Range Vector  ある時点からの特定の時間区間のデータプロットのVector topic=kafka-topic-v1 topic=kafka-topic-v2 0m 1m 2m 3m 4m Instant Vector Range Vector
  16. 16. Query Example (Instant Vector)  全ラベル  ラベルの値で絞り込み  特定のラベルについて合計 burrow_consumed_offset burrow_consumed_offset { topic=“kafka-topic-v1” } sum(burrow_consumed_offset) by (topic)
  17. 17. Query Example (RangeVector)  5分前から今まで  7分前から2分前まで  5分前から今までの平均 burrow_consumed_offset{ topic=”kafka-topic-v1” }[5m] burrow_consumed_offset{ topic=”kafka-topic-v1" }[5m] offset 2m avg_over_time( burrow_consumed_offset{ topic=”kafka-topic-v1” }[5m] )
  18. 18. Reference  四則演算や論理演算,その他の関数を駆使して クエリを書く  https://prometheus.io/docs/querying/functions/
  19. 19. Alert Rule  PromSQLで発火条件を記述  Instant Vectorは基本的に集合演算 (true/falseではない)  クエリで抽出されたラベルセット全てについて アラートが発火する.
  20. 20. Alert Rule  topic=kafka-topic-v1 topic=kafka-topic-v1 0m 1m 2m 3m 4m Instant Vector Input_records IF input_records < 4 FOR 1m ANNOTATIONS { summary = ”few input records” } 3 8 [ topic=“kafka-topic-v1” 3 ] Result Bool値になるわけではない
  21. 21. Alert Rule Example IF ( sum(burrow_head_offset{topic=~"^kafka-*"}) BY (topic) - sum(burrow_head_offset{topic=~”^kafka-.*} offset 6m) BY (topic) ) != 0 unless ( sum(burrow_consumed_offset{consumer="collector"}) BY (topic) - sum(burrow_consumed_offset{consumer="collector"} offset 6m) BY (topic) ) > 0 FOR 5m ANNOTATIONS { topic="{{$labels.topic}}", } ① topicラベルがkafka-から始まる各トピックでburrow_head_offsetの 合計値の6分前の値との差が0でないもの ② consumerラベルがcollectoで burrow_consumed_offsetの合計値の6分前との差が0より大きいもの ①のラベルセットにあって②のラベルセットにないもの この条件が5分以上継続している場合発火 ANNOTATIONにはラベルの値をつかえる
  22. 22. Summary of This Section  PromSQLでinstant vectorやrange vectorを こねくり回してVisualizeしたりAlertを設定する.  ラベルによって多次元構造になっていることで Queryでの表現自由度が高くなっていて良い.
  23. 23. Scalability
  24. 24. Performance  特にチューニングしなくても100,000個の Time seriesを扱えるらしい
  25. 25. Federation  性能が足りない場合はFederationが必要  とはいえ,Multi DCや,かなり大きいDCで大量の ノードを監視したいみたいな状況じゃないと 早々必要にはならないっぽい.  あとはクエリの評価を高速化したい場合ぐらい
  26. 26. Federation  Prometheusが他のPromethuesをScrapeする構成  設定に応じて/federateに渡すmetricsがExportされる. - job_name: 'federate' scrape_interval: 15s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' static_configs: - targets: - 'source-prometheus-1:9090’ - 'source-prometheus-2:9090’ source-prometheus-1:9090/federate source-prometheus-2:9090/federate scrape scrape
  27. 27. Hieralchical federation  階層構造を組んで徐々にmetricsの集約度を 上げていく構成  多分DWHと考え方は似ている scrape scrape store lower level data store higher level data = aggregated data
  28. 28. Summary of this section  実はバックエンドも長年の研究成果の結晶  1台でも100,000個ものTime seriesを捌ける  それでも足りない場合 (すごい大規模なDCを監視する場合など)は Federation構成を組みましょう.
  29. 29. Conclusion  Exporterと簡単な設定を追加するだけでいろんな Metricsが取れる.  Service Discovery周りのサポートが優秀  Exporterは一部デキの悪いものも…  ラベル付きの多次元データモデルとPromSQLで 複雑な状況も柔軟に監視,アラートができる.  処理性能もかなりのものでFederation構成もとれて 安定している.  大規模DCにも対応できる.

×