レイテンシも数えた比 — 閾値の下に何件あったか

この回で決めることは、レイテンシの「良い」です。可用性では状態コードで良い・悪いを分けました。レイテンシでは、閾値を1本引き、その下に入った要求を良いと数えます。数えるのは件数なので、SLI はこれまでと同じ「良い÷有効」の比になります。もう1つ、失敗した要求を分子と分母のどちらに入れるかも決めます。

SRE Workbook 第2章の Table 2-1 は、レイテンシの SLI をこう定義します。

The proportion of requests that were faster than some threshold.

一方、同じ章の Table 2-2 は、レイテンシを histogram_quantile(0.9, ...) と (0.99, ...) で計算しています。割合の定義と百分位の計算が、同じ章に並んでいます。その間の段落が理由を書いています。

Generally speaking, it is better to count the slow requests than to approximate them with a histogram. But, because that information isn’t available, we use the histogram provided by our monitoring system.

数えるほうが良いが、手元に無いので histogram で近似した、までです。「百分位を使うな」とは書いていません。

件数の比が正確だったのは、閾値 0.3 がバケット境界だったからです。Prometheus 公式文書は、境界が無い場合をこう書きます。

Instead of an estimation, no result is returned at all.

さらに、境界が一部の histogram にしか無いと an incomplete result is returned, but without any warning とも書きます。どちらもエラーにならないのが厄介です。

閾値そのものは SLI 仕様の決め事です。Workbook では第2章が 450/900 ms、付録A が 400/850 ms ですが、付録A は測定期間(2018-01-01〜01-28)と 50 ms 切り上げを明記しています。第2章の実測 432/891 ms を切り上げても 400/850 にはならないので、食い違いではなく別の測定から出た例です。不等号は両文書とも散文が <、実装が「以下」(less than or equal to)で、文書間の差ではありません。

もう1つの決め事が失敗の扱いです。付録A の式は count of all "api" http_requests で割り、分子にも分母にも状態コードの条件がありません。速い 500 は良い側に入ります。ただし同じ付録に可用性 SLI が別にあり、5xx はそこで数えます。SRE Book 第6章は、失敗を混ぜると misleading calculations になりうると書いたうえで、a slow error is even worse than a fast error! と続け、除外ではなく別に追えと言います。