Prometheus CONSEPTSページのメモ

データモデル

Prometheus > Concepts > Data model

基本的にすべてのデータを時系列で保存する

ここでいう時系列とは
あるラベルセットによってラベリングされたメトリクスがあったとして、そのメトリクスに属するタイムスタンプが付けられた一連の値。保存した時系列データに対してクエリすることで派生した時系列データを生成することもできる。

メトリックの名前とラベル

時系列データは、
・メトリックの名前
・ラベル(key/valueペアのセット)
で一意に決まる。

メトリクスの名前をみればどんな測定をしたメトリクスかがわかる。
例えばhttp_requests_totalというメトリックスであれば、受け取ったHTTPリクエストの総数を意味する。

ASCII文字列と数字、アンダースコア、コロンを使用できる。

ラベルによってプロメテウスの多次元データモデルが実現されている。
あるメトリクスに対してのラベルの組み合わせによって、そのメトリクスがどんな次元でインスタンス化されたかがわかる。クエリ言語はその次元をもとにメトリクスをフィルタリングしたり集約したりする。

ラベルの値が変わったり追加されたり削除されたりすることで新しい時系列データが作られる。

アンダースコア2つ”__”ではじまるラベル名は内部の処理に使われるもの。

サンプル

ここでいうサンプル=メトリクスをスクラップした結果(値)

サンプルは
・64ビット浮動小数点の値
・ミリ秒精度の時刻
で構成される

表記法

メトリックの名前とラベルセットを指定することで時系列データを識別できる

書き方↓

<metric name>{<label name>=<label value>, ...}

メトリクスに対してラベル名とラベルの値のセット指定する(複数可)

例:
メトリック名:api_http_requests_total
ラベル1の名前:method
ラベル1の値:POST
ラベル2の名前:handler
ラベル2の値:/messages
だったら、時系列データは

api_http_requests_total{method="POST", handler="/messages"}

となる

ちなみにこれはOpenTSDBと同じ表記法。

メトリックタイプ

CONCEPTS > Metryc types

Prometheusのクライアントライブラリは4つのメトリクタイプを提供する。
– Counter
– Gauge
– Histogram
– Summary

Counter – カウンター

カウンターとは

累積的なメトリック
単なる数値

用途

数をカウントするのに使う

例えば
・受け付けたリクエストの数
・完了したタスクの数
・発生したエラーの数
などをカウントする

こんな用途はだめ

ある時点のカウントが下がりそうなアイテムの数をカウントすること。今時点で動いているgoroutineの数とか。そういったものを対象にする場合は「Gauge」タイプのメトリクスを使うこと。

Gauge – ゲージ

gaugeとは

単一の増減する数値

用途

値の計測に使う

例えば
・気温
・メモリ使用量
・増減する可能性のあるカウント値(goroutineの数みたいなもの)など

Histogram – ヒストグラム

ヒストグラムとは

例えば
・リクエスト期間
・レスポンスサイズ
のようなものに対しての観測

観測した結果をバケットという枠でカウントしていく
観測した値の総数が見られる

使い方

対象とするメトリック名をとして、histogramメトリックはスクレイプしている間に複数の時系列データを生成する

・バケットを観測した結果である累積値は以下のように得られる

<basename>_bucket{le="<upper inclusive bound>"}

・観測した値の総和は以下のように確認する

<basename>_sum

・観測したイベントの数は以下

<basename>_count

↓のと同じ

<basename>_bucket{le=”+Inf”}

用途

histogram_quantile()関数を使うことで
ヒストグラムからquantile(統計の代表値)や、ヒストグラム自体を集約したものも計算できる

ヒストグラムはApdexスコアを算出するのに最適

バケットを操作するときは、ヒストグラムは累積的であるということを覚えておけ

※よくわからない

Summar – サマリー

ヒストグラムに似ている
リクエスト期間やレスポンスサイズなんかの観測を試みる

観測の数をカウントする一方で、観測した結果(値)の総和も出す
スライディングタイムウインドウ上で定義されたクォンタイルを計算する

もととなるメトリック名をとして、summaryは以下のよう使う

  • 観測したイベントのφクォンタイル
  • <basename>{quantile="<φ>"}
  • すべての観測値の総和
  • <basename>_sum
  • イベント自体の数
  • <basename>_count

φクォンタイルについてん詳細な説明はベストプラクティスのページを参照

ジョブとインスタンス

CONCEPTS > Jobs and instance

  • インスタンスとは
  • スクレイプ可能なエンドポイントのこと
    通常は単一プロセスに該当

  • ジョブとは
  • 目的が同じインスタンスを集めたもの
    例えば、スケーラビリティあるいはリライアビリティのためにレプリケートされたプロセス=インスタンスの集合のこと

  • ジョブとインスタンスの例
  • 4つのインスタンスからなるapi-serverのジョブ

    job: api-server <br>
        instance 1: 1.2.3.4:5670
        instance 2:  1.2.3.4:5671
        instance 3: 5.6.7.8:5670
        instance 4: 5.6.7.8:5671
    

ラベルの自動生成と時系列の関係

Prometheusは、スクレイプした時系列データに、ターゲットを識別するためのラベルを自動的につける。jobとinstanceもその一つ。

ラベルの値は、

  • job:
  • ターゲットが属するジョブ名前(任意に設定するもの。さっきの例のapi-serverのように運用者がターゲットを特定するためのグルーピング)

  • instance:
  • : (スクレイプしたターゲットURLの一部)

スクレイプしたデータがすでにこのラベルをもっていたら、設定ファイルのhonor_labelsオプションの内容に従ってラベルを設定する。
詳細は

スクラップしたサンプルの例

  • インスタンスに対してスクレイプできたかどうか
  • up{job="<job-name>", instance="<instance-id>"}: [0|1]

    値は0か1のどちらかを返す。
    1の場合はインスタンスへのスクレイプが成功。つまりインスタンスがhealthyの状態。
    0の場合はインスタンスへのスクレイプが失敗。この場合はインスタンスがダウンしているのか、NW的な要因でスクレイプに失敗しているのかまでは判断できない。
    インスタンスへのモニタリングができているかを確認するのに使える。

  • スクレイプに要する時間(期間)- duration of scrape
  • scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}: 
  • リラベルをした後に残っているサンプルの数(リラベルされなかったサンプルの数)
  • scrape_samples_post_metric_relabeling{job="<job-name">, instance="<instance-id>"}: value
  • ターゲットからスクレイプしたサンプルの数
  • scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}: value