prometheus

Prometheus

What is Prometheus?時系列データを扱う監視システム

サービスの死活監視パフォーマンスのモニタリング

競合監視システム Ganglia Graphite Zabbix

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

Componens

Components (of Ganesha)

Time series database Dashboard

scrape

Alert Manager

scrape & evaluate metrics

alerting

PushGateway scrape

BurrowExporter

GraphiteExporter

CloudWatchExporterr

Service Discovery

scrape

Monitoring targets

register

NodeExporterscrape

planting rules

planting rules


Dashboardscrape

Alert Manager


alerting

PushGateway

BurrowExporter

GraphiteExporter

CloudWatchExporterr

Service Discovery

scrape

register

NodeExporterscrape

Time series database

Monitoring targets

scrape

Push 型ではなく Pull 型

各種 Exporter があるので簡単な設定で様々なメトリクスが監視できる．

PushGateway で metrics の Push も受けられる

planting rules

scrape

Monitoring targets


Dashboardscrape

Alert Manager


alerting

PushGateway

BurrowExporter

GraphiteExporter

CloudWatchExporterr

Service Discoveryregister

NodeExporterscrape

scrape


Consul 経由で Container Serviceの監視も楽

Registrator で簡単に Consul 登録

scrape

Monitoring targets


Dashboardscrape

Alert Manager


alerting

PushGateway

BurrowExporter

GraphiteExporter

CloudWatchExporterr

register

NodeExporterscrape

scrape


Service Discoveryplanting

rulesconsul-planter で

consul KV にルールを格納

consul-template で Alert Manager に埋め込み

発火すると Slack にアラートが飛ぶ

scrape

Service Discoveryplanting

rules

scrape

Monitoring targets


Dashboard

Alert Manager


alerting

PushGateway

BurrowExporter

GraphiteExporter

CloudWatchExporterr

register

NodeExporterscrape


scrape

Grafana でカッコよくビジュアライズ !!

Summary of This Section各種 Exporter でいろんなソースから簡単に

Metrics を取れるConsul や Kubernetes との連携でコンテナ監視も

楽Alert Manager で Slack 通知

consul-planter と consul-template でいい感じにconsul KV連携してアラートルール管理してます．

Grafana かっこいい

PromSQL &Alert Manager

Metrics in Prometheusラベルを使った多次元時系列データ

topic=kafka-topic-v1


Input records

0m 1m 2m 3m 4m

ラベル

Metrics in PrometheusMetrics の種類 ( 厳密には 4 種類あるらしいけ

ど ..) Counter

• 数の累積を取る． (Kafka の Offset とか )• リセットされない限単調増加

Guage• 毎時変動する値 ( メモリの使用量とか )

カスタムメトリクスを自前で Export するときは，この違いを意識しないとおかしなことになる．

What is PromSQL多次元時系列 Metrics を操作するための

Prometheus の独自クエリ言語Alert Rule の設定や， Dashboard での可視化に

使う．

Instant Vector & Range VectorInstant Vector

ある時刻の各ラベルのデータプロットの VectorRange Vector

ある時点からの特定の時間区間のデータプロットのVector



0m 1m 2m 3m 4m

Instant Vector

Range Vector

Query Example (Instant Vector)全ラベル

ラベルの値で絞り込み

特定のラベルについて合計

burrow_consumed_offset

burrow_consumed_offset { topic=“kafka-topic-v1” }

sum(burrow_consumed_offset) by (topic)

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])

Reference四則演算や論理演算，その他の関数を駆使して

クエリを書く https://prometheus.io/docs/querying/functions/

Alert RulePromSQL で発火条件を記述

Instant Vector は基本的に集合演算 (true/false ではない )

クエリで抽出されたラベルセット全てについてアラートが発火する．

Alert Rule



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 値になるわけではない

Alert Rule Example

IF ( sum(burrow_head_offset{topic=~"^kafka-*"}) BY (topic) - sum(burrow_head_offset{topic=~”^kafka-.*} offset 6m) BY (topic)) != 0unless ( sum(burrow_consumed_offset{consumer="collector"}) BY (topic) - sum(burrow_consumed_offset{consumer="collector"} offset 6m) BY (topic)) > 0FOR 5mANNOTATIONS { topic="{{$labels.topic}}",}

① topic ラベルが kafka- から始まる各トピックで burrow_head_offset の合計値の 6 分前の値との差が 0 でないもの

② consumer ラベルが collecto で burrow_consumed_offset の合計値の 6 分前との差が 0 より大きいもの

① のラベルセットにあって②のラベルセットにないものこの条件が 5 分以上継続している場合発火

ANNOTATION にはラベルの値をつかえる

Summary of This SectionPromSQL で instant vector や range vector を

こねくり回して Visualize したり Alert を設定する．

ラベルによって多次元構造になっていることで Query での表現自由度が高くなっていて良い．

Scalability

Performance特にチューニングしなくても 100,000 個の

Time series を扱えるらしい

Federation性能が足りない場合は Federation が必要

とはいえ， Multi DC や，かなり大きい DC で大量のノードを監視したいみたいな状況じゃないと早々必要にはならないっぽい．

あとはクエリの評価を高速化したい場合ぐらい

FederationPrometheus が他の 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

Hieralchical federation階層構造を組んで徐々に metrics の集約度を

上げていく構成多分 DWH と考え方は似ている

scrape scrape

store lower level data

store higher level data = aggregated data

Summary of this section実はバックエンドも長年の研究成果の結晶

1 台でも 100,000 個もの Time series を捌ける

それでも足りない場合 ( すごい大規模な DC を監視する場合など ) は Federation 構成を組みましょう．

ConclusionExporter と簡単な設定を追加するだけでいろんな

Metrics が取れる． Service Discovery 周りのサポートが優秀 Exporter は一部デキの悪いものも…

ラベル付きの多次元データモデルと PromSQL で複雑な状況も柔軟に監視，アラートができる．

処理性能もかなりのもので Federation 構成もとれて　安定している．大規模 DC にも対応できる．

prometheus

Engineering