## 定義 ヒストグラムメトリクスは、レイテンシなどの測定値を単一の平均値やパーセンタイル値に潰さず、分布のビンごとのサンプル数として保持するメトリクスである。[[Heinrich Hartmann]] の SREcon19 EMEA 資料では、レイテンシ SLO を計算するために、関連 API のレイテンシ情報をヒストグラムとして取得し、ノード・エンドポイント・時間をまたいで集約したうえで、しきい値以下のビンのサンプル数を数える方式として示される (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 ## 横断的知見 - **ヒストグラムメトリクスは SLO 判定を「代表値監視」から「分布の事後問い合わせ」へ移す**: SRE Book 系の実践ではパーセンタイルがレイテンシ評価の重要指標とされるが、Hartmann の資料はパーセンタイル時系列そのものを SLO 実装に使うと集約不能性で破綻すると示す。ヒストグラムを保持しておけば、SLO 判定時に期間・ノード・エンドポイントを横断して全体分布を作り、しきい値以下のリクエスト割合を計算できる。これは [[サービスレベル目標]] の「良いイベント数 / 全イベント数」型 SLI を、レイテンシ分布に対して実装するデータ構造である (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 - **ログ・カウンタ・ヒストグラムは同じ SLO を異なる保存コストと柔軟性で実装する 3 点である**: ログは正確で後から任意しきい値を選べるが長期保存が高価(~1GB/1000 万リクエスト)、しきい値別カウンタは安価で正確だがしきい値を先に決める必要がある。ヒストグラムは計装とメトリクスストアを要求する代わりに、しきい値・時間窓・集約粒度の柔軟性を保つ(HDR: ~300バイト/ヒストグラム)。これはテレメトリ保持層における「情報量をどこまで残すか」の設計問題である (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2019__SREcon19 Americas__Latency SLOs Done Right]])。 - **Prometheus の累積バケット比率は、レイテンシ SLO の直感的な初期実装として現れる**: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale|Wilkinson SREcon17 Americas]] は、2ms 以下のレイテンシバケットの rate を `+Inf` バケットの rate で割り、60% 未満なら発火する例を示す。これは「分位点そのもの」ではなく「しきい値以下の良いイベント割合」を計算する点で、Hartmann 2019 のレイテンシ SLO 実装と同じ方向を先に示している。ただし Wilkinson 2017 はアラート設計の実例であり、Hartmann 2019 ほどパーセンタイル集約不能性を体系的には論じていない。(Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) - **ログリニアヒストグラムのマージ可能性はビン境界の共有に依存する**: Moyer はヒストグラムの最大利点として `h(A ∪ B) = h(A) ∪ h(B)` で表されるマージ可能性を挙げる。ただし A と B は同一のビン境界を持つ必要がある。libcircllhist は 2 有効桁の 10 進浮動小数点数(10^{+/-128} 範囲)を固定ビン境界として採用することでこの条件を満たし、任意の時間ウィンドウ・任意のノード集合をまたいだ集約を可能にする。Liz Fong-Jones は「しきい値がビン境界線上にあることを確認せよ」と補足しており、ビン設計がクエリ精度を決める設計決定点であることを示す (Source: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] p.41-42)。 - **TSDB のヒストグラムネイティブサポートは 2019 年時点でも IRONdb 以外は不十分だった**: Moyer は結論スライドで「スパース符号化・HDR ヒストグラムの TSDB サポートは IRONdb 以外欠如している」と明示し、これがヒストグラムによる SLO 計算普及のボトルネックになっていることを示唆した。その後 Prometheus native histograms (2022〜) 等が登場しているが、2019 年時点では Circonus 実装が先行していた (Source: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] p.49)。 - **ログリニア HDR ヒストグラムは 46,081 ビンで ±10^±128 の全 10 進浮動小数点範囲をカバーする**: 有効桁 2 桁の 10 進表現(10, 11, ..., 100, 110, ..., 1000, 1100, ...)で隣接ビンは等しい相対誤差を持つ。値が存在するビンのみを保持するスパース符号化により、100K 超エントリでも典型サイズ 300 バイト/ヒストグラムとなる。OSS 実装は hdrhistogram.org (Tene @ Azul Systems) と github.com/circonus-labs/libcircllhist (Circonus、IRONdb 向け) が代表的である (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] p.26)。 - **マージ可能分位点要約の系譜**: circllhist (Schlossnagle @ Circonus 2013)、HDR Histograms (Tene @ Azul Systems 2015)、t-digest (Dunning @ MapR, Erl @ Dynatrace 2015)、DD-Sketch (Masson @ DataDog 2019) の 4 系統が 2019 年時点の実用候補。Python ライブラリ比較（2015 MBP ベンチマーク、参照値 p90=35.774ms）では: circllhist 0.001% 誤差・挿入 0.86s/merge 0.000262s/p90 0.000005s で精度・速度の両立が最も優れる。HDR Histogram 0.000% 誤差だが挿入が 3.59s と遅い。t-digest 0.029% 誤差で挿入 97s と著しく低速。DD-Sketch 0.256% 誤差で挿入 2.39s と高速だが精度は最低。Notebook: github.com/HeinrichHartmann/Statistics-for-Engineers/ (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] p.31-32)。 - **「平均の単純平均は不正確」という同一の落とし穴が、SLO 実装(Hartmann 2019)と一般的なオブザーバビリティ入門(Observability Engineering 第5章)の双方で独立に例示される**: Hartmann はレイテンシ SLO 判定の文脈で「パーセンタイル時系列を単純平均すると集約不能性で破綻する」と論じたのに対し、`Observability Engineering` 第5章はより一般的な「per-instance の平均応答時間を単純平均する」例で同じ数理的誤りを示す(web.1=100件・web.2=57件・web.3=98件の場合、単純平均183msは加重平均175msから乖離する)。後者は解決策として「リクエスト数と合計応答時間」という未集計に近い2値の保持を提示し、これはヒストグラムメトリクスが解く問題の最小形(2バケット版)とみなせる。両ソースとも到達点は同じで「集計後にデータ点数の重みを失うと元の分布は数学的に復元できない」ため、事前にヒストグラム(またはカウント+合計)として保持しておく必要があると説く。(Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]]) - **circllhist の作者自身が、実装(2013年)の 5 年後に、その理論的な必要性を PDF/CDF/分位関数から一般読者向けに再構成していた**: [[Circonus]] 創業者 [[Theo Schlossnagle]] は『SREの探求』21 章で、なぜ単純な統計量(最小・最大・中央値・平均)ではなく分布そのもの(ヒストグラム)を保持する必要があるかを、PDF(確率密度関数)・CDF(累積密度関数)・分位関数という基礎から説明する。Hartmann・Moyer(SREcon19)の資料が「パーセンタイル時系列は集約不能」という実装上の問題を先に示し、その解決策としてヒストグラムを導入する構成であるのに対し、Schlossnagle(2018年執筆)はこの章で先に「なぜ分布全体を見る必要があるか」という統計的な動機づけを一般化して示しており、時系列としては後発の SREcon19 資料が扱う実装(ビン設計・マージ可能性・TSDB 対応)の理論的土台にあたる。図21-3 のヒストグラム例は、モード(A)・複数の挙動の重なり(B・C・D)・ロングテール(LT)を視覚的に示し、「最小値・最大値・中央値・平均値では元データへの理解が貧弱になる」と明示する点で、本 concept の「代表値監視から分布の事後問い合わせへ」という知見の一般向け解説として機能する (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.3-21.4, [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 - **ヒストグラムの元データへの正確な問い合わせは、視覚化されたグラフだけでは得られない精度を持つ——Hartmann のビン境界設計への注意を、Schlossnagle は具体的な計算例で裏付ける**: Schlossnagle は、グラフから「99% のリクエストが 5ms 以内」というおおよその適合を視覚的に確認したうえで、元データ(ビンとサンプル数)を使って計算すると、実際には利用者全体の 99.4597%(約 6 万件中 324 件が基準未達)という正確な値が得られると示す。これは Hartmann(SREcon19 EMEA)が「しきい値がビン境界線上にあることを確認せよ」と補足した注意——ビン設計がクエリ精度を決める——を、実際にビンから正確な比率を逆算する計算例として具体化したものである。両者を合わせると、ヒストグラムメトリクスの価値は「分布の形を見る」ことに加え「任意のしきい値に対する正確なカウントを事後的に問い合わせられる」ことにある点が明確になる (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.4-21.5, [[@2019__SREcon19 Americas__Latency SLOs Done Right]] p.41-42)。 ## 未解決の問い - Prometheus native histograms、DD-Sketch、t-digest、HDR Histogram のようなマージ可能要約は、SLO バーンレートアラートの実装でどの程度互換的に扱えるか。近似誤差を SLA に近い契約指標へ使う場合、どの誤差境界を明示すべきか。 - ヒストグラムのビン設計は、高基数ラベルや長期保持コストとどう折り合うべきか。任意しきい値の柔軟性を残すほど保持コストが増える場合、どの粒度が実運用で妥当か。 - レイテンシ以外の SLO、たとえば生成 AI の出力品質スコアや RAG 検索品質に、ヒストグラムメトリクス型の分布保持はどこまで有効か。 ## 関連 - ソース: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] / [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] / [[@2019__SREcon19 Americas__Latency SLOs Done Right]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]] / [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] - 概念: [[サービスレベル目標]] / [[テレメトリ]] / [[時系列データベース]] / [[エラーバジェット]] / [[レイテンシ分析]] - エンティティ: [[Heinrich Hartmann]] / [[Fred Moyer]] / [[Circonus]] / [[Theo Schlossnagle]] ## 出典 - [[@2019__SREcon19 EMEA__Latency SLOs Done Right]](p.19-33: ログ・カウンタ・ヒストグラムによるレイテンシ SLO 実装、p.32: mergeable summary 比較) - [[@2019__SREcon19 Americas__Latency SLOs Done Right]](p.16-21: パーセンタイル平均化の誤り、p.26-48: 3 手法の詳細、p.39: マージ可能性、p.41-42: ビン境界設計、p.49: TSDB サポート状況) - [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]](p.25-29: バケット化された分布と Prometheus 風アラート例) - [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]]("Metrics Are Typically Aggregated": 平均の単純平均が不正確になる例とヒストグラムメトリクスの導入) - [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]](§21.3-21.5: PDF/CDF/分位関数の基礎、ヒストグラムによるモード・ロングテールの可視化、しきい値以下サンプル数の正確な計算例)