前面的章節，我們了解了怎樣編寫出更具有可觀測性的日志，更具有可觀測性的日志可以幫助我們更快速地定位問題産生的原因。統計名額和日志一樣，也是無處不在的。今天，我就來帶你了解一下統計名額。
名額功能
統計名額在日常生活中很常見，每月按時到公司的次數、每天代碼送出的 commit 數等，都可以算是統計名額。它會記錄系統在一段時間内的某個次元的數值，是以，它能最直覺地展現出系統是否出現了問題。每一個統計名額都可以被量化為一個數值，是以，它是高度可量化的。根據這一特點，我們可以通過它完成一些工作，比如以下 2 個方面：
- 業務分析：産品一般可以通過業務型名額了解到産品上線之後的真實效果如何，進而優化下一步的産品決策。業務型名額包括成單率、使用者留存等。
- 系統運作狀态：通過在系統中埋點或是統計已有資料，比如最常見的 CPU 使用率、通路 QPS、響應耗時等，開發人員可以快速了解到系統的運作狀态。
通過統計名額你能夠感性地認識到整個系統的運作情況。出現問題後，各個名額資料會首先出現波動，這些波動會反映出系統是在哪些方面出現了問題，我們可以由此排查出現問題的原因。
前段時間我遇到了一個問題：使用 HttpClient 架構發送 HTTP 請求時總是會卡死，并且堆棧總會卡死在發送請求上。最後我去查詢句柄的名額資料時，才發現是因為句柄被占滿了，無法執行導緻的卡死。
名額類型
介紹了名額的作用後，我們來看一下統計名額都有哪些類型，它們又分别有哪些不同的作用？
計數器（Counter）
計數器是一個數值單調遞增的名額，一般這個值為 Double 或者 Long 類型。我們比較常見的有 Java 中的 AtomicLong、DoubleAdder，它們的值就是單調遞增的。QPS 的值也是通過計數器的形式，然後配合上一些函數計算得出的。
圖 1：計數器
儀表盤（Gauge）
儀表盤和計數器都可以用來查詢某個時間點的固定内容的數值，但和計數器不同，儀表盤的值可以随意變化，可以增加也可以減少。比如在 Java 線程池中活躍的線程數，就可以使用 ThreadPoolExecutor 的 getActiveCount 擷取；比較常見的 CPU 使用率和記憶體占用量也可以通過儀表盤擷取。
圖 2：儀表盤
直方圖（Histogram）
直方圖相對複雜一些，它是将多個數值聚合在一起的資料結構，可以表示資料的分布情況。
如下圖，它可以将資料分成多個桶（Bucket），每個桶代表一個範圍區間（圖下橫向數），比如第 1 個桶代表 0~10，第二個桶就代表 10~15，以此類推，最後一個桶代表 100 到正無窮。每個桶之間的數字大小可以是不同的，并沒有規定要有規律。每個桶和一個數字挂鈎（圖左縱向數），代表了這個桶的數值。
圖 3：直方圖
以最常見的響應耗時舉例，我把響應耗時分為多個桶，比如我認為 0~100 毫秒比較快，就可以把這個範圍做一個桶，然後是 100~150 毫秒，以此類推。通過這樣的形式，可以直覺地看到一個時間段内的請求耗時分布圖，這有助于我們了解耗時情況分布。
摘要（Summary）
摘要與直方圖類似，同樣表示的是一段時間内的資料結果，但是資料反映的内容不太一樣。摘要一般用于辨別分位值，分位值就是我們常說的 TP90、TP99 等。
假設有 100 個耗時數值，将所有的數值從低到高排列，取第 90% 的位置，這個位置的值就是 TP90 的值，而這個桶的值假設是 80ms，那麼就代表小于等于90%位置的請求都 ≤80ms。
用文字不太好了解，我們來看下面這張圖。這是一張比較典型的分位值圖，我們可以看到圖中有 6 個桶，分别是 50、75、80、90、95、99，而桶的值就是相對應的耗時情況。
圖 4：分位值圖
通過分位值圖，我們可以看到最小值和最大值以外的一些資料，這些資料在系統調優的時候也有重要參考價值。
在這裡面我需要補充一個知識點，叫作長尾效應。長尾效應是指少部分類資料在一個資料模型中占了大多數樣本，在資料模型中呈現出長長的尾巴的現象。如圖所示，最上面的 TP99 相當于這個圖表的尾巴，可以看到，1% 使用者通路的耗時比其他 5 個桶加起來的都要長。這個時候你如果通過名額檢視某個接口的平均響應時間，其實意義不大，因為這 1% 的使用者通路已經超出了平均響應時間，是以平均響應時間已經無法反映資料的真實情況了。這時使用者會出現嚴重的量級分化，而量化分級也是我們在進行系統調優時需要着重關注的。
這種情況我們一般很難通過撥測、自己通路來複現。但我們通過觀測這一部分内容，通過鍊路追蹤的方式可以定位到問題的根源。這是我在後續課時中會介紹的。
常見名額
在本課時的最後，我會列舉一些工作用常見的名額，你可以通過這些名額看到系統運作的情況。
QPS
Query Per Second，每秒查詢的數量。QPS 在系統中很常見，它不再是單單和“查詢”這個特殊條件綁定。QPS 現在也與請求量挂鈎，我們可以通過這個值檢視某個接口的請求量。假設我們在 1 秒内進行了 1 次接口調用，就可以認為在這 1 秒内，QPS 增加了 1。如果系統進行過壓測，那麼也可以估算出 QPS 的峰值，進而預估系統的容量。
SLA
Service Level Agreement，服務等級協定。SLA 是服務商和使用者之間的協定，規定了服務的性能和可用性。根據這種可量化的協定，雙方可以更詳細地制定細則，比如沒有到達一定的可用性時的賠償方案。阿裡雲之前就規定了短信發送的 SLA 方案，并制定了詳細的賠償明細。具體細節可檢視： https://help.aliyun.com/document_detail/63935.html?spm=5176.13910061.sslink.1.64b922b2xSbOT9。
最常見的可用性名額類似于“四個九”“五個九”，四個九指的是 99.99%，五個九就是 99.999%，以此類推。SLA 并不是一個固定的數值，“四個九”“五個九”隻是代表系統可以保持穩定的時間。SLA 會因為成功數與請求數的不同而變化，可能是 95%，也可能是 80%，這需要我們去計算。
如果你要計算某個接口的 SLA 情況，就可以指定一段時間區間，然後依據以下的公式來計算：
總計成功數 / 總計請求數 = 百分比(%)
那總計成功數是怎麼得來的呢？比如 HTTP 請求，狀态碼 200 就可以算是成功，此時成功數就可以 +1；dubbo 不出現異常時成功數就可以 +1。當然，這也不是一定的，根據公司内部的 HTTP 響應狀态碼等内容也可以更細粒度地規定，如果将相應結果中 json 的 code 值 1 定為成功，則滿足條件是成功數也可以 +1。
你可能會問，這個 SLA 算出來之後和我們的工作有什麼關系呢？比如說，我們需要保證這個服務 1 年的 SLA 是“五個九”。那麼 1 年就是時間機關，由此我們可以算出服務不可用的時間：
1 年 = 365 天 = 8760 小時
三個九 = 8760 * (1 - 99.9%) = 8.76 小時
四個九 = 8760 * (1 - 99.99%) = 0.876 小時 = 0.876 * 60 = 52.6 分鐘
五個九 = 8760 * (1 - 99.999%) = 0.0876 小時 = 0.0876 * 60 = 5.26 分鐘
1 年内，該服務不可用的時間為 5.26 分鐘。
由此可見，想要保證越多的“九”，就要保證服務穩定，縮短服務錯誤的時間，是以，它對系統穩定有重要的意義，“九”也成了公認的标準。
Apdex
Application Performance Index，應用性能指數。Apdex 會用響應耗時來判斷使用者對應用性能的滿意度，并通過可量化的形式展現出來。通過這個量化的值，我們可以快速感覺使用者的滿意程度。這也是首次和使用者的使用體驗相結合的一個名額。
Apdex 分為 3 個區間：
- 滿意（Satisfactory）：使用者對于這樣的響應時間是十分滿意的，感覺十分流暢。
- 容忍（Tolerating）：稍微慢了一點兒，但是可以接受。
- 失望（Frustrating）：實在太慢，快要放棄了。
有了這樣的名額資訊，無論你是否參與了這個服務的開發，無論你是否懂技術，都可以了解這個服務是否令人滿意。
那這個衡量使用者是否滿意的值是怎樣計算出來的呢？
它需要管理人員給一個時間機關 T，來表示當小于或等于多少秒的時候使用者的感覺非常好的。映射到 3 個區間内，Apdex 規定，符合滿意程度的是 1T，符合容忍程度的是 1T~4T，失望則大于 4T。通過這樣的形式，我們就能得知目前請求是屬于哪個區間的。
比如我們要計算某個時間段内的 Adpex 值，就可以通過這樣的公式來計算：
(滿意數量 + (容忍數量 / 2)) / 總數 = Apdex 值
通過這個公式，我們可以得出服務整體的 Apdex 值，這個值會在 0~1 的範圍内。值越接近 1 代表使用者的滿意度越高。通過這樣可自定義門檻值的計算方式，如何衡量業務的滿意度也有了一個可量化的标準。
結語
我相信通過對名額的介紹，你應該已經對名額有了更深刻的認識。你覺得除了我上面介紹的這 3 個常見的名額外，還有哪些是你經常關注的名額？ 歡迎在留言區分享你的看法。
下一節，我将帶你了解各個資料源上都有哪些資料名額是可以觀測的，幫助你更好地通過名額定位系統隐患。