15秒ごとに取りに行く設定で、1秒だけ続く山は60回中52回が記録に残りませんでした。
公式も、正確さが要る用途には向かないと述べています。見えない前提で使う道具です。
取りに行った瞬間の値だけが残ります。間隔より短い出来事は、記録の上では起きません。
Prometheusは、値を取りに行って集めます。公式は計測が組み込まれた仕事から値を取りに行く。直接か、短命な仕事のためには中継役を経由すると述べています。
取りに行った瞬間しか残りません。では、間隔と山の長さでどれだけ変わるのか。実際に並べて数えました。
1時間ぶん（3600秒）の値を1秒きざみで作り、60回の山を置く ふだんは 100、山のあいだは 900。取りに行く間隔を変えて、山を捉えられた割合を見る 山の長さ 1秒ごと 5秒ごと 15秒ごと 60秒ごと 1秒 100% / 見逃し0回 20% / 見逃し48回 13% / 見逃し52回 2% / 見逃し59回 3秒 100% / 見逃し0回 55% / 見逃し27回 20% / 見逃し48回 3% / 見逃し58回 10秒 100% / 見逃し0回 100% / 見逃し0回 65% / 見逃し21回 17% / 見逃し50回 30秒 100% / 見逃し0回 100% / 見逃し0回 100% / 見逃し0回 68% / 見逃し19回
山の長さが間隔以上なら、必ず捉えられます。左上の三角がすべて100%なのはそのためです。
問題は逆側です。15秒ごとの設定で1秒の山は13%しか捉えられず、52回は記録に残りません。
この表は、だんだん悪くなる形をしていません。間隔をまたいだところで0%か100%かに分かれます。
だから設定は「細かいほど良い」ではなく、見たい山の長さで決まります。10秒の山を確実に見たいなら、10秒以下にします。
この境目の効き方は遅延監視の記事で扱った平均と最大の食い違いとも重なり、平らな数値が実態を隠す点は共通しています。
間隔をまたぐと、捉えられる割合が一気に落ちる。
Prometheus scrapes metrics from instrumented jobs, either directly or via an intermediary push gateway for short-lived jobs.原文Prometheus 公式ドキュメント「Overview」 この内容の有効期限2027-02-18
公式が課金には向かないと明言しています。数え上げの合計も、間隔しだいで欠けます。
Prometheusは、正確さが要る用途には向きません。公式はリクエストごとの課金のように100%の正確さが要るなら、集めた値は十分に細かくも完全でもないため、良い選択ではないと述べています。
どれくらい欠けるのか。処理が再起動して数え直しが起きる場合で実際に組み直して比べました。
1日ぶん（86400秒）。毎秒 20 件を数え上げる（本当の合計 1,728,000 件） 途中で数え直し（0に戻る）が起きる。取りに行った点だけから合計を組み直して、本当の値と比べる 数え直しの回数 15秒ごと 60秒ごと 300秒ごと 0回 0件 (0.00%) 0件 (0.00%) 0件 (0.00%) 2回 400件 (0.02%) 1,300件 (0.08%) 6,100件 (0.35%) 12回 2,200件 (0.13%) 7,300件 (0.42%) 40,680件 (2.35%) 48回 8,660件 (0.50%) 28,460件 (1.65%) 137,600件 (7.96%)
数え直しがなければ0.00%です。積み上げた値の差を取るだけなので、間隔は関係ありません。
数え直しが入ると変わります。48回・5分ごとでは137,600件、7.96%が欠けました。
0.5%の誤差は、傾きを見る用途では問題になりません。増えたか減ったかは分かります。
請求だと話が違います。1件ずつ突き合わせる用途には、この誤差は使えません。公式の指摘はここを指しています。
請求のように1件も落とせない集計は、Kafkaの記事で扱ったような、記録を残して後から組み直せる仕組みの側で行うことになります。
If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice, as the collected data will likely not be detailed and complete enough.原文Prometheus 公式ドキュメント「Overview」 この内容の有効期限2027-02-18
重さは値の数ではなくラベルの組み合わせで決まります。1つ足すと桁が変わります。
Prometheusは、値をラベル付きの時系列として保ちます。公式は値は記録した時刻とともに、ラベルと呼ばれる任意の組と並べて保存されると述べています。
ラベルの組み合わせぶんだけ系列ができます。どれくらい増えるのか、実際に作って測りました。
まず 1 系列あたりの重さを実測する。500,000 系列を作って割ると 197 バイトだった その単価を、ラベルの重ね方ごとの系列数に掛ける ラベルの重ね方 組み合わせ 系列数 見積もり使用量 1つ前との比 経路のみ 50 50 0.0MB ＋方式 50×5 250 0.0MB 5倍 ＋応答コード 50×5×8 2,000 0.4MB 8倍 ＋利用者ID 50×5×8×200 400,000 75.0MB 200倍
最初の3つは足し算のように見えますが、実際は掛け算です。それでも2,000系列までなら軽いままです。
4つ目で崩れます。利用者IDを足しただけで200倍、40万系列になりました。
分かれ目は、値の種類が利用者数や件数に比例するかどうかです。比例するものを入れると、増えるほど重くなります。
利用者ID・注文ID・住所・問い合わせ文などが該当します。経路名や応答コードのように種類が決まっているものなら安全です。
3つの計測はいずれも手元で書いた模型で、実際のPrometheusを動かしたものではありません。山の見逃しは、山が一様に散らばると置いた上での結果です。数え上げの取りこぼしは「値が減っていたら数え直しとみなす」という組み直し方に固有のもので、実装によって扱いは違います。1系列あたり197バイトはNodeのMapでの実測値で、実際の保存形式とは違います。ここで見せているのは、間隔をまたぐと捉えられる割合が段差で落ちるという点と、ラベルは掛け算で効くという点の2つです。
Prometheus collects and stores its metrics as time series data, i.e. metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels.原文Prometheus 公式ドキュメント「Overview」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る