Introduction of metric collecting and monitoring System Prometheus

1. Prometheus

2. What is Prometheus?
 時系列データを扱う監視システム
 サービスの死活監視
 パフォーマンスのモニタリング
 競合監視システム
 Ganglia
 Graphite
 Zabbix

3. What am I talking about?
 Prometheusのコンポーネント
 PromSQL + AlertManager周りの話
 PrometheusのScalability

4. Componens

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. 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. 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. 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. 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. Summary of This Section
 各種Exporterでいろんなソースから簡単に
Metricsを取れる
 ConsulやKubernetesとの連携でコンテナ監視も楽
 Alert ManagerでSlack通知
 consul-planterとconsul-templateでいい感じにconsul KV
連携してアラートルール管理してます．
 Grafanaかっこいい

11. PromSQL &
Alert Manager

12. Metrics in Prometheus
 ラベルを使った多次元時系列データ
topic=kafka-topic-v1
topic=kafka-topic-v2
Input records
0m 1m 2m 3m 4m
ラベル

13. Metrics in Prometheus
 Metricsの種類 (厳密には4種類あるらしいけど..)
 Counter
• 数の累積を取る．(KafkaのOffsetとか)
• リセットされない限単調増加
 Guage
• 毎時変動する値 (メモリの使用量とか)
 カスタムメトリクスを自前でExportするときは，
この違いを意識しないとおかしなことになる．

14. What is PromSQL
 多次元時系列Metricsを操作するための
Prometheusの独自クエリ言語
 Alert Ruleの設定や，Dashboardでの可視化に使う．

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. Query Example (Instant Vector)
 全ラベル
 ラベルの値で絞り込み
 特定のラベルについて合計
burrow_consumed_offset
burrow_consumed_offset { topic=“kafka-topic-v1” }
sum(burrow_consumed_offset) by (topic)

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. Reference
 四則演算や論理演算，その他の関数を駆使して
クエリを書く
 https://prometheus.io/docs/querying/functions/

19. Alert Rule
 PromSQLで発火条件を記述
 Instant Vectorは基本的に集合演算 (true/falseではない)
 クエリで抽出されたラベルセット全てについて
アラートが発火する．

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. 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. Summary of This Section
 PromSQLでinstant vectorやrange vectorを
こねくり回してVisualizeしたりAlertを設定する．
 ラベルによって多次元構造になっていることで
Queryでの表現自由度が高くなっていて良い．

23. Scalability

24. Performance
 特にチューニングしなくても100,000個の
Time seriesを扱えるらしい

25. Federation
 性能が足りない場合はFederationが必要
 とはいえ，Multi DCや，かなり大きいDCで大量の
ノードを監視したいみたいな状況じゃないと
早々必要にはならないっぽい．
 あとはクエリの評価を高速化したい場合ぐらい

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. Hieralchical federation
 階層構造を組んで徐々にmetricsの集約度を
上げていく構成
 多分DWHと考え方は似ている
scrape scrape
store lower level data
store higher level data = aggregated data

28. Summary of this section
 実はバックエンドも長年の研究成果の結晶
 1台でも100,000個ものTime seriesを捌ける
 それでも足りない場合
(すごい大規模なDCを監視する場合など)は
Federation構成を組みましょう．

29. Conclusion
 Exporterと簡単な設定を追加するだけでいろんな
Metricsが取れる．
 Service Discovery周りのサポートが優秀
 Exporterは一部デキの悪いものも…
 ラベル付きの多次元データモデルとPromSQLで
複雑な状況も柔軟に監視，アラートができる．
 処理性能もかなりのものでFederation構成もとれて
安定している．
 大規模DCにも対応できる．