Latency（延遲）是我們?cè)诒O(jiān)控線上的組件運(yùn)行情況的一個(gè)非常重要的指標(biāo)，它可以告訴我們請(qǐng)求在多少時(shí)間內(nèi)完成。監(jiān)控 Latency 是一個(gè)很微妙的事情，比如，假如一分鐘有 1億次請(qǐng)求，你就有了 1億個(gè)數(shù)字。如何從這些數(shù)字中反映出用戶(hù)的真實(shí)體驗(yàn)?zāi)兀?/span>

之前的公司用平均值來(lái)反應(yīng)所有有關(guān)延遲的數(shù)據(jù)，這樣的好處是計(jì)算量小，實(shí)施簡(jiǎn)單。只需要記錄所有請(qǐng)求的一個(gè)時(shí)間總和，以及請(qǐng)求次數(shù)，兩個(gè)數(shù)字，就可以計(jì)算出平均耗時(shí)。

但問(wèn)題是，平均耗時(shí)非常容易掩蓋真實(shí)的問(wèn)題。比如現(xiàn)在有 1% 的請(qǐng)求非常慢，但是其余的請(qǐng)求很快，那么這 1% 的請(qǐng)求耗時(shí)會(huì)被其他的 99% 給拉平，將真正的問(wèn)題掩蓋。

所以更加科學(xué)的一種監(jiān)控方式是觀察 P99/P95/P90 等，叫做 Quantile。簡(jiǎn)單的理解，P99 就是第 99% 個(gè)請(qǐng)求所用的耗時(shí)。假如 P99 現(xiàn)在是 10ms，那么我們可以說(shuō) “99% 的請(qǐng)求都在 10ms 內(nèi)完成”。雖然在一些請(qǐng)求量較小的情況下，P99 可能受長(zhǎng)尾請(qǐng)求的影響。但是由于 SRE 一般不會(huì)給在量小的業(yè)務(wù)上花費(fèi)太多精力，所以這個(gè)問(wèn)題并不是很大。

但是計(jì)算就成了一個(gè)問(wèn)題。P99 是計(jì)算時(shí)間的分布，所以我們是否要保存下來(lái) 1 億個(gè)請(qǐng)求的時(shí)間，才能知道第 99% 的請(qǐng)求所用的時(shí)間呢？

這樣耗費(fèi)的資源太大了。考慮到監(jiān)控所需要的數(shù)據(jù)對(duì)準(zhǔn)確性的要求并不高。比如說(shuō) P99 實(shí)際上是 15.7ms 但是計(jì)算得到數(shù)據(jù)是 15.5ms，甚至是 14ms，我認(rèn)為都是可以接受的。

我們關(guān)注更多的是它的變化?！癙99 耗時(shí)從 10.7ms 上漲到了 14ms” 和 “P99耗時(shí)從 11ms 上漲到了 15.5ms” 這個(gè)信息對(duì)于我們來(lái)說(shuō)區(qū)別并不是很大。（當(dāng)然了，如果是用于衡量服務(wù)是否達(dá)到了服務(wù)等級(jí)協(xié)議 SLO 的話(huà)，還是很大的。這樣需要合理地規(guī)劃 Bucket 來(lái)提高準(zhǔn)確性）。

所以基于這個(gè)，Prometheus 采用了一種非常巧妙的數(shù)據(jù)結(jié)構(gòu)來(lái)計(jì)算 Quantile: Histogram。

Histogram 本質(zhì)上是一些桶。舉例子說(shuō)，我們?yōu)榱擞?jì)算 P99，可以將所有的請(qǐng)求分成 10 個(gè)桶，第一個(gè)存放 0-1ms 完成的請(qǐng)求的數(shù)量，后面 9 個(gè)桶存放的請(qǐng)求耗時(shí)上區(qū)間分別是 5ms、10ms、50ms、100ms、200ms、300ms、500ms、1s、2s，這樣只要保存 10 個(gè)數(shù)字就可以了。

要計(jì)算 P99 的話(huà)，只需要知道第 99% 個(gè)數(shù)字落在了哪一個(gè)桶，比如說(shuō)落在了 300ms-500ms 的桶，那我們就可以說(shuō)現(xiàn)在的 99% 的請(qǐng)求都在 500ms 之內(nèi)完成（這樣說(shuō)不太準(zhǔn)確，如果準(zhǔn)確的說(shuō)，應(yīng)該是第 99% 個(gè)請(qǐng)求在 300ms – 500ms 之間完成）。這些數(shù)據(jù)也可以用來(lái)計(jì)算 P90、P95 等等。

由于我們的監(jiān)控一般是繪制一條曲線，而不是一個(gè)區(qū)間。所以 P99 在 300-500 之間是不行的，需要計(jì)算出一個(gè)數(shù)字來(lái)。

Prometheus 是假設(shè)每一個(gè)桶內(nèi)的數(shù)據(jù)都是線性分布的，比如說(shuō)現(xiàn)在 300-500 的桶里面一共有 100 個(gè)請(qǐng)求，小于300個(gè)桶里面一共有 9850 個(gè)請(qǐng)求。所有的桶一共有 1萬(wàn)個(gè)請(qǐng)求。

那么我們要找的 P99 其實(shí)是第 10000 * 0.99 = 9900 個(gè)請(qǐng)求。第 9900 個(gè)請(qǐng)求在 300-500 的桶里面是第 9900 – 9850 = 50 個(gè)請(qǐng)求。根據(jù)桶里面都是線性分布的假設(shè)，第 50 個(gè)請(qǐng)求在這個(gè)桶里面的耗時(shí)是 (500 – 300) * (50/100) = 400ms，即 P99 就是 400ms。

可以注意到因?yàn)槭腔诰€性分布的假設(shè)，不是準(zhǔn)確的數(shù)據(jù)。比如假設(shè) 300-500 的桶中耗時(shí)最高的請(qǐng)求也只有 310ms，得到的計(jì)算結(jié)果也會(huì)是 400ms。桶的區(qū)間越大，越不準(zhǔn)確，桶的區(qū)間越小，越準(zhǔn)確。

寫(xiě)這篇文章，是因?yàn)樽蛱焱屡軄?lái)問(wèn)我，“為啥我的日志顯示最慢的請(qǐng)求也才 1s 多，但是這個(gè) P999 latency 顯示是 3s？”

我查了一下確實(shí)如他所說(shuō)，但是這個(gè)結(jié)果確實(shí)預(yù)期的。因?yàn)槲覀冊(cè)O(shè)置的桶的分布是：10ms、50ms、100ms、500ms、1s、5s、10s、60s。

如上所說(shuō)，Prometheus 只能保證 P999 latency 落在了 1s – 5s 之間，但不能保證誤差。

如果要計(jì)算準(zhǔn)確的 Quantile，可以使用 Summary 計(jì)算。簡(jiǎn)單來(lái)說(shuō)，這個(gè)算法沒(méi)有分桶，是直接在機(jī)器上計(jì)算準(zhǔn)確的 P99 的值，然后保存 P99 這個(gè)數(shù)字。但問(wèn)題一個(gè)是在機(jī)器本地計(jì)算，而不是在 Prometheus 機(jī)器上計(jì)算，會(huì)占用業(yè)務(wù)機(jī)器的資源；另一個(gè)是無(wú)法聚合，如果我們有很多實(shí)例，知道每一個(gè)實(shí)例的 P99 是沒(méi)有什么意義的，我們更想知道所有請(qǐng)求的 P99。顯然，原始的信息已經(jīng)丟失，這個(gè) P99 per instance 是無(wú)法支持繼續(xù)計(jì)算的。

另外一個(gè)設(shè)計(jì)巧妙的地方是，300-500 這個(gè)桶保存的并不是 300-500 耗時(shí)的請(qǐng)求數(shù)，而是 <500ms 的請(qǐng)求數(shù)。也就是說(shuō)，后面的桶的請(qǐng)求數(shù)總是包含了它前面的所有的桶。這樣的好處是，雖然我們保存的數(shù)據(jù)沒(méi)有增加（還是10個(gè)數(shù)字），但是保存的信息增加了。假如說(shuō)中間丟棄一個(gè)桶，依然能夠計(jì)算出來(lái) P99，在某些情況下非常有用，比如監(jiān)控資源不夠了，我們可以臨時(shí)不收集前5個(gè)桶，依然可以計(jì)算 P99。