## 定義 ヒストグラムメトリクスは、レイテンシなどの測定値を単一の平均値やパーセンタイル値に潰さず、分布のビンごとのサンプル数として保持するメトリクスである。[[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 点である**: ログは正確で後から任意しきい値を選べるが長期保存が高価、しきい値別カウンタは安価で正確だがしきい値を先に決める必要がある。ヒストグラムは計装とメトリクスストアを要求する代わりに、しきい値・時間窓・集約粒度の柔軟性を保つ。これはテレメトリ保持層における「情報量をどこまで残すか」の設計問題である (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[テレメトリ]])。 ## 未解決の問い - Prometheus native histograms、DD-Sketch、t-digest、HDR Histogram のようなマージ可能要約は、SLO バーンレートアラートの実装でどの程度互換的に扱えるか。近似誤差を SLA に近い契約指標へ使う場合、どの誤差境界を明示すべきか。 - ヒストグラムのビン設計は、高基数ラベルや長期保持コストとどう折り合うべきか。任意しきい値の柔軟性を残すほど保持コストが増える場合、どの粒度が実運用で妥当か。 - レイテンシ以外の SLO、たとえば生成 AI の出力品質スコアや RAG 検索品質に、ヒストグラムメトリクス型の分布保持はどこまで有効か。 ## 関連 - ソース: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 概念: [[サービスレベル目標]] / [[テレメトリ]] / [[時系列データベース]] / [[エラーバジェット]] - エンティティ: [[Heinrich Hartmann]] / [[Circonus]] ## 出典 - [[@2019__SREcon19 EMEA__Latency SLOs Done Right]](p.19-33: ログ・カウンタ・ヒストグラムによるレイテンシ SLO 実装、p.32: mergeable summary 比較)