作者：涯海
前文回顧：
使用篇｜鏈路追蹤（Tracing）其實很簡單：請求軌跡回溯與多維鏈路篩選
在前面文章裏面，我們介紹了單鏈路的篩選與軌跡回溯，是從單次請求的視角來分析問題，類似查詢某個快遞訂單的物流軌跡。但單次請求無法直觀反映應用或接口整體服務狀態，經常會由於網絡抖動、宿主機 GC 等原因出現偶發性、不可控的隨機離羣點。當一個問題發生時，應用負責人或穩定性負責人需要首先判斷問題的實際影響面，從而決定下一步應急處理動作。因此，我們需要綜合一段時間內所有鏈路進行統計分析，這就好比我們評估某個物流中轉站點效率是否合理，不能只看某一個訂單，而要看一段時間內所有訂單平均中轉時間與出錯率。
統計分析是我們觀察、應用分佈式鏈路追蹤技術的重要手段。我們既可以根據不同場景要求進行實時的後聚合分析，也可以將常用的分析語句固化成規則生成預聚合指標，實現常態化監控與告警。相對於鏈路多維篩選，統計分析需要明確分析對象與聚合維度。其中，分析對象決定了我們對哪些指標進行聚合操作，比如請求量、耗時或錯誤率。而聚合維度決定了我們對哪些特徵進行統計對比，比如不同應用、接口、IP、用戶類型的統計量對比。接下來，我們先了解下分析對象和聚合維度的具體概念，再介紹實時分析與監控告警的具體用法。
01 分析對象
分析對象，又稱爲度量值（Measure），決定了我們對哪些指標進行聚合操作。常見的度量值包括“黃金三指標”——請求量、錯誤和耗時。 除此之外，消息延遲、緩存命中率或自定義度量值也是高頻應用的分析對象，我們來逐一瞭解下。
（一）請求量
請求量可以說是我們最熟悉的度量值之一。這個接口被調用了多少次？這一分鐘的請求量與上一分鐘相比有什麼變化，與前一天相比有什麼變化？這些問題都是我們在日常運維過程中最熟悉的對話。
請求量通常按照一個固定的時間間隔進行統計，比如按秒統計的請求量通常稱之爲 QPS（Queries Per Second），有些場景也會稱之爲 TPS（Transactions Per Second）。兩者有一些細微差別，但含義基本相同，經常被混用。我們可以使用 QPS 來衡量系統的單位時間吞吐能力，用以指導系統資源的分配調度；或者觀測用戶行爲的變化，判斷系統是否出現異常。
如下圖所示，創建訂單接口每天上午 10 點和 12 點的請求量都會有一個週期性的突增，這種情況大概率是整點促銷活動的正常表現，我們在做資源容量評估時需要參考整點的峯值請求量，而不是系統平均請求量，否則每當流量突增時系統可用性就可能大幅下降，影響用戶體驗。
下面第二張圖的創建訂單接口在 10 月 8 號凌晨 00:39 分有一個非常明顯的下跌，並且前一天的曲線是比較平滑的，這種現象大概率是接口異常導致的，已經影響了用戶的下單體驗，需要深入排查定位原因。
請求 QPS 的變化趨勢反映了系統吞吐能力的變化，是請求量最常用的一種方式。但在某些離線計算場景，對短時間內的吞吐變化不敏感，更需要一個比較大的時間間隔內的吞吐總量統計，比如一天或一週的請求處理總量。以便靈活分配離線計算資源。
錯誤
每一次鏈路請求都會對應着一個狀態：成功，或失敗。一次失敗的請求通常稱之爲錯誤請求。單條錯誤請求可能由於各種各樣的偶發性原因不予關注。但是當錯誤數累積到一定程度，超過一定閾值時，就必須要進行處理，否則會引發大面積的系統故障。
錯誤指標除了像請求量一樣，分爲錯誤 QPS 和錯誤總量之外，還有一種比較特殊的統計方式，就是錯誤率。錯誤率是指在單位時間間隔內錯誤數佔請求總數的比例。 比如 A 接口一分鐘內被調用了 10000 次，其中有 120 次是錯誤調用，那麼 A 接口這一分鐘的錯誤比率就是 120 / 10000 = 0.012，也就是 1.2%。
錯誤率是衡量系統健康程度的關鍵指標，針對它的健康閾值設置不會受請求量的週期性變化影響。比如下單接口的請求量在白天達到峯值的 10000 QPS，在夜間的谷值只有 100 QPS，全天的請求量變化範圍在 100 ~ 10000 QPS 之間。相應的錯誤量變化範圍在 0.2 ~ 20 QPS 之間，而錯誤率基本固定在 0.2% 左右。無論是使用固定閾值或同環比的方式，錯誤數都很難精確反映系統實際的健康程度，而錯誤率使用起來就簡單、有效的多。比如設置錯誤率超過 1% 時就發送告警短信，超過 5% 就電話通知穩定性負責人立即排查。
（二）耗時
耗時也是我們非常熟悉的度量值之一，簡單地說就是這次請求的處理花費了多長時間。但是不同於請求量。對耗時次數或總量的統計不具備實用價值，最常用的耗時統計方式是平均耗時。比如 10000次調用的耗時可能各不相同，將這些耗時相加再除以 10000 就得到了單次請求的平均耗時，它可以直觀的反應當前系統的響應速度或用戶體驗。
不過，平均耗時有一個致命的缺陷，就是容易被異常請求的離散值干擾，比如 100 次請求裏有 99 次請求耗時都是 10ms，但是有一次異常請求的耗時長達1分鐘，最終平均下來的耗時就變成（60000 + 10*99）/100 = 609.9ms。這顯然無法反應系統的真實表現。因此，除了平均耗時，我們還經常使用耗時分位數和耗時分桶這兩種統計方式來表達系統的響應情況。
耗時分位數
分位數，也叫做分位點，是指將一個隨機變量的概率分佈範圍劃分爲幾個等份的數值點，例如中位數（即二分位數）可以將樣本數據分爲兩個部分，一部分的數值都大於中位數，另一部分都小於中位數。相對於平均值，中位數可以有效的排除樣本值的隨機擾動。
舉個例子，你們公司每個同事的薪資收入可能各不相同，如果財務負責人要統計公司的中間薪資水平有兩種方式，一種就是把所有人的薪資加在一起再除以人數，這樣就得到了平均薪資；還有一種是將薪資從高到低排序，選取排在中間的那個人的薪資作爲參考值，也就是薪資中位數。這兩種做法的效果對比如下圖所示：
分位數被廣泛應用於日常生活的各個領域，比如教育領域的成績排布就大量使用了分位數的概念，大家最熟悉的應該就是高考錄取分數線。假如某大學在 A 省招收 100 人，而該省有 1 萬人報考該大學，那麼該大學的錄取分數線就是所有報考學生成績的 99 分位數，也就是排名前 1% 的同學可以被錄取。無論該省的高考試題是偏難還是偏簡單，都能準確錄取到預定的招生人數。
將分位數應用在 IT 領域的耗時指標上，可以準確的反映接口服務的響應速度，比如 99分位數可以反映耗時最高的前 1% 接口請求的處理時間。對於這部分請求來說服務的響應速度可能已經達到了一個無法忍受的程度，例如 30 秒鐘。相對於平均耗時，耗時 99 分位數額外反映了 3 個重要的信息：
- 有 1% 的服務請求可能正在忍受一個超長的響應速度，而它影響到的用戶是遠大於 1% 的比例。因爲一次終端用戶請求會直接或間接的調用多個節點服務，只要任意一次變慢，就會拖慢整體的終端體驗。另外，一個用戶可能會執行多次操作，只要有一次操作變慢，就會影響整體的產品體驗。
- 耗時 99 分位數是對應用性能瓶頸的提前預警。當 99 分位數超出可用性閾值時，反映了系統服務能力已經達到了某種瓶頸，如果不加處理，當流量繼續增長時，超時請求影響的用戶比例將會不斷擴大。雖然你現在處理的只是這 1% 的慢請求，但實際上是提前優化了未來 5%、10%，甚至更高比例的慢請求。
- 什麼樣的用戶請求更可能觸發 99 分位數的異常？根據經驗表明，往往是那些數據體量大，查詢條件複雜的“高端”用戶更容易觸發慢查詢。同時，這部分用戶通常是影響產品營收和口碑的高價值用戶，絕不能置若罔聞，而要優先響應解決。
duration>3s AND serviceName="orderCenter" | SELECT SUM(request_count) AS total_count,
spanName GROUP BY spanName ORDER BY total_count DESC LIMIT 10
除了 99 分位數，常用的耗時分位數還包括 99.9、95、90、50 分位數，可以根據應用接口的重要性和服務質量承諾（SLA）選擇適當的分位數進行監控和預警。當一條時間序列上的分位數連在一起就形成了一條“分位線”，可用於觀察耗時是否存在異常的變化趨勢，如下圖所示：
耗時直方圖
耗時分位數和平均值將接口響應速度抽象成了有限的幾個數值，比較適合監控和告警。但是，如果要做深度的分析，識別所有請求的耗時分佈情況，那就沒有比直方圖更適合的統計方式了。
直方圖大家可能不是很熟悉，平時接觸的也比較少。它的橫座標代表請求耗時，縱座標代表請求次數，並且橫/縱座標值通常都是非等分的，因爲耗時與次數的分佈通常是不均衡的，使用非等分座標軸更容易觀測重要且低頻的慢請求分佈，而等分座標軸很容易將低頻值忽略掉。如下圖所示，我們可以直觀的發現不同耗時範圍內的請求次數分佈：耗時在 100ms 左右的請求次數最多，超過了 10000 次；耗時在 5-10s 範圍內次數也不少，接近 1000 次，而超過 30s 以上的請求也有接近 10 次。
直方圖可以與分位數結合使用，每一個耗時分位數都會落在直方圖具體的某個區間內，如下圖所示 P99 分位數落在了 3s 的區間。這樣，我們不僅能夠快速發現最慢的 1% 請求耗時閾值是3s，還能進一步區分這 1% 最慢的請求在 3-5s，5-7s，7-10s，10s 以上的具體分佈數量。同樣的 P99 分位數（3s），慢請求全部集中在 3-5s 區間，和全部集中在 10s 以上區間所反映的問題嚴重程度，以及問題背後的原因可能是完全不同的。
通過對比不同時段的直方圖分佈，我們可以精準發現每一個耗時區間的變化情況。如果你的業務是面向終端用戶，每一個長尾請求都代表着一次糟糕的用戶體驗，那你應該重點關注耗時區間最高的那部分變化，比如 P99 分位數所在的區間；如果你的系統是負責圖形圖像處理，更加看重單位時間內的吞吐率，不那麼在意長尾耗時，那你應該優先關注大部分請求的耗時變化，比如 P90 或 P50 所在區間的分佈變化。
直方圖能夠爲我們分析耗時問題提供更豐富的細節，在後續章節的實踐案例中我們將做進一步的介紹。
（三）其他度量值
請求量、錯誤和耗時又被稱爲“黃金三指標”，可以應用於絕大部分類型的鏈路請求，如 HTTP，RPC，DB等。除此之外，一些特殊的請求類型，具備獨特的場景特性，需要一些新的度量值來表達其語義，例如緩存命中率、消息時延、任務調度時延等。這一類度量值的通用性不高，但是可以恰當地描述所屬類型的關鍵特徵。下面我們以緩存命中率爲例，瞭解下它的典型用法。
緩存命中率
小玉負責的訂單中心會調用存儲在 Redis 緩存中的商品詳情，只有查詢緩存未命中時纔會去請求數據庫。有一個問題一直苦惱着小玉，就是每次促銷活動剛開始的時候就會出現訪問量激增又下降再緩慢回升，伴隨耗時大幅抖動的現象，而緩存和數據庫的請求量也會相對應的抖動變化，如下圖所示：
我們可以看到緩存請求量的變化是與創建訂單接口大致相同的，而數據庫的請求量有一個比較大幅的增長。可以初步判斷是由於促銷活動初期出現了大量緩存未命中，從而調用數據庫導致的創建訂單接口耗時異常，因爲查詢數據庫的耗時開銷要遠大於緩存。那麼，緩存未命中的原因又是什麼呢？主要有兩種常見原因，一種是查詢了大量冷數據導致的緩存命中率下降，另一種是查詢量激增導致緩存連接被打滿，超過其服務提供能力。兩種原因的具體表現可以結合緩存命中率指標進一步區分，如下圖所示。
爲了減少冷數據對促銷活動體驗的影響，可以提前進行緩存預熱提高命中率；而連接打滿的問題可以提前調整客戶端或服務端的緩存連接池最大連接數限制，或者提前擴容。緩存命中率下降的嚴重後果會導致大量請求擊穿數據庫，最終導致整體服務不可用。因此，在生產環境中建議對緩存命中率設置告警，提前發現風險。
（四）自定義度量值
除了分佈式鏈路追蹤框架默認生成的通用度量值外，我們還可以將自定義度量值添加到 Attributes 對象中，再對其執行統計、分析和告警等操作。這些自定義度量值可以很好的拓展分佈式鏈路追蹤在業務域的應用。比如，我們將每筆訂單的金額添加至 Attributes 中，類似 attributes.price = 129.0 。接下來，按照接口維度聚合訂單金額，就可以看到不同接口的關聯收入，並給出相應的漏斗分析圖。幫助業務同學分析哪一步行爲影響了用戶的最終支付，造成了潛在的營收損失，如下圖所示。
02 聚合維度
分析對象決定了我們要對哪些指標進行操作，而聚合維度決定了對該指標從多少個切面進行統計分析。通過對不同切面進行展開和對比，我們能夠發現這些指標值爲什麼會發生這樣或那樣的一些變化。例如某個接口一段時間內的平均耗時爲 3s，但是分佈在兩個不同的版本，其中 v1 版本的平均耗時只有 1s，而 v2 版本的平均耗時卻高達 5s。此時，我們可以將問題明確的聚焦在 v2 版本上，觀察 v2 版本相對於 v1 版本有哪些不同，進而定位耗時高的原因，如下圖所示。
如果說分析對象回答了“是什麼”的問題，那麼聚合維度就回答了“爲什麼”的問題。選擇一個恰當的聚合維度進行展開，可以幫忙我們有效的分析異常發生的特徵分佈，例如版本、IP、用戶類型、流量類型等等。如果單個維度不足以定位問題，就需要進行多個維度的聚合分析，比如查看特定應用特定版本在不同用戶類型的接口耗時變化。
與分析對象類似，常用的聚合維度可以分爲鏈路框架自動生成的基礎特徵維度，以及用戶自定義標籤維度這兩類，如下所示：
- 鏈路基礎特徵聚合：在鏈路特徵篩選的章節我們介紹過鏈路基礎特徵主要是指調用鏈本身所具備的一些基礎信息，比如接口名稱，所屬應用，節點IP、請求狀態等等。無論是何種編程語言、何種埋點框架，這些基礎特徵都是由鏈路埋點框架自行生成的，也是最常用的聚合分析維度。目前主流的 Tracing 或 APM 產品都會提供預置的應用服務維度聚合指標，例如 Jaeger、Zipkin、Skywalking 等開源實現還會提供對應的監控大盤。
- 用戶自定義標籤聚合：除了鏈路基礎特徵以外，用戶如果想要擴展業務屬性，就可以通過鏈路 SDK 向 Attributes 裏添加自定義標籤，例如流量類型、用戶類型、業務領域、商品類目、銷售渠道等等。自定義標籤提供了一種從業務視角分析流量問題的手段，靈活的運用自定義標籤可以更好的發揮分佈式鏈路追蹤的數據價值。不過，由於自定義標籤具有一定的埋點改造和運維成本，目前在生產環境還沒有被大規模應用起來，需要 Tracing 產品提供更加靈活、成本更低的打標方案，例如白屏化動態打標，我們在後續章節再進行詳細介紹。
（一）基礎特徵與自定義標籤結合使用
小玉作爲訂單中心的應用負責人，對於核心接口的版本更新一直非常謹慎，按照慣例，她會先在預發環境進行灰度用戶引流，對比新老版本的差異，確認無誤後再發布至生產環境。此時，小玉會同時對應用、接口、環境、IP等多個基礎特徵進行聚合，再結合自定義的版本標籤對比流量狀態變化，如下圖所示，v1.1 新版本的接口耗時大幅上升，錯誤率也遠高於 v1.0 版本，應該立即停止發佈，回滾版本，避免影響線上用戶體驗。
在這個案例中，由於 v1.1 版本的灰度流量要遠小於 v1.0 版本，如果沒有按照版本維度進行聚合比對，新版本的異常問題就會被整體流量平均稀釋掉，難以被提前發現。只能等到發佈比例增加到足夠大的程度，對線上用戶造成更加嚴重的影響後，纔可能被定位。
（二）注意事項
不是所有的聚合維度都是有意義的，一個有效的聚合維度必須具備一個前提，就是它的值分佈在有限的、肉眼可觀測的數據集，而不能無限發散。比如一個日活上億的 APP 應用，不應該直接將訪問用戶的 UserId 作爲聚合維度，因爲聚合後的上億條曲線完全無法觀測，不具備監控和告警價值。相對應的，我們可以選擇用戶類型作爲聚合維度，區分遊客、普通會員、白金會員、鑽石會員等不同用戶類型的訪問情況。
還有一種情況是，聚合維度部分發散，比如 URL 裏面有部分字段包含了時間戳，UID 等變量信息。此時，我們需要對 URL 做模糊化處理，通過收斂算法將不斷變化的字段收斂成星號 *，保留不變的協議、域名、路徑等，收斂前後的效果如下圖所示。
03 鏈路實時分析
隨着時間的流逝，馬上要臨近雙11啦，爲了保障大促洪峯流量下的系統可用性，小玉的部門發起了全面治理慢調用接口的活動。小玉接到通知後，有一些發愁，雖然她已經熟練掌握了調用鏈的篩選與查詢，但是微服務調用接口有這麼多，一條條的查詢調用鏈，每個接口全都治理一遍的成本屬實有點高，即使她瘋狂加班也不一定能按時完成。此時，小明建議她優先分析與治理慢調用出現次數最多的 Top10 核心接口。那麼，如何快速識別出 Top10 的慢接口有哪些呢？這就是我們本小節將要介紹的鏈路實時分析功能。
鏈路實時分析，是基於給定的調用鏈明細數據樣本集（通常是全量數據），自由組合篩選條件與聚合規則，得出分析對象統計維度的分佈結果。 相比於鏈路篩選，實時分析需要指定分析對象和聚合維度，對滿足篩選條件的結果集執行二次聚合（GROUP BY）操作。比如對訂單中心應用耗時大於 3s 的慢請求按照接口名稱維度，對請求總次數進行聚合與排序，就可以得到訂單中心 Top10 接口的慢調用次數分佈結果，如下所示。
鏈路實時分析可以從統計分佈的視角給出問題的影響面，結合自定義標籤與度量值，靈活的滿足各類業務分析需求。比如大於3秒的下單請求有多少次，佔總請求的比例是多少？下單失敗的請求集中在哪些渠道或品類？由於下單失敗導致的潛在營收損失數額有多大？
靈活性是鏈路實時分析的最大優勢，但缺點也很明顯，主要有以下三點：
- 基於明細數據的實時分析結果會受到調用鏈採樣率的影響，一旦開啓了調用鏈採樣，基於非全量數據的實時分析結果就會產生偏差，出現樣本傾斜情況，影響用戶判斷，分析價值會大打折扣。
- 基於明細數據的查詢分析成本較高，每次需要掃描大量原始數據，當調用鏈數據量較大時，分析速度會比較慢，不適合做常態化、高頻次的監控與告警。
- 實時分析需要用戶給定查詢與聚合條件，不支持開箱即用，使用和學習成本較高。
鏈路實時分析適用於個性化、低頻的查詢場景，而面向經典、高頻查詢場景，鏈路監控無疑是更合適的選擇。
04 鏈路監控
爲了彌補鏈路實時分析採樣不精確、查詢速度慢、使用成本高等問題，聰明的程序員想到了一個好辦法，就是對鏈路明細數據提前進行預處理，在鏈路採樣發生前將其預聚合成監控指標。比如上文中提到的大於 3s 的慢請求接口分佈，如果在端側提前將滿足條件的 Span 記錄進行預聚合，即使單位時間內滿足該條件的 Span 只有1個，由於監控指標不受採樣率影響，仍然可以精準記錄該 Span 的調用情況；如果單位時間內同一個接口大於 3s 的 Span 非常多，比如大於 1萬次，最終轉化的監控指標也只有一條，後續的數據處理與存儲成本將大幅下降，查詢速度也會顯著提升。
（一）經典指標 vs 自定義指標
爲了進一步降低用戶的使用成本，大部分鏈路追蹤開源實現或商業化產品都會面向經典查詢提供開箱即用的鏈路指標與大盤。比較典型的包括應用流量總覽，HTTP 狀態碼統計，數據庫 SQL 統計等。
開箱即用的經典鏈路指標與大盤，可以滿足大部分用戶的通用查詢需求，但是無法滿足不同用戶的差異化查詢訴求。那麼該如何平衡易用性與靈活性的天秤，低成本的釋放鏈路數據的完整價值呢？
一種比較有效的方法就是自定義指標。比如慢 SQL 治理是一種生產系統面臨的經典難題，但是不同業務類型對“慢”的定義不同，金融類系統容忍度比較低，可能大於 0.5s 就算慢。而提供文件下載服務的系統容忍度比較高，可能大於 10s 纔算慢。爲了平衡不同用戶的差異化訴求，爲每個用戶生成專屬的慢SQL自定義指標是個不錯的選擇。
（二）影響應用健康的關鍵鏈路監控有哪些?
小玉作爲訂單中心的 Owner，需要全力保障訂單服務的穩定運行，爲了實時監控應用服務的健康狀態，及時處理線上風險，小玉該掌握哪些關鍵的鏈路監控大盤呢？
- 對外提供的關鍵接口的 RED 黃金三指標：作爲應用 Owner，最優先要關注的就是對外提供的服務是否正常，只要對外提供的服務保持在健康水位之內，其他的指標波動不會即刻產生太大的業務影響。因此，梳理訂單中心對外服務的關鍵接口列表，掌握它們在不同時段的流量、耗時與錯誤率變化特徵，是小玉保障應用健康的“重中之重”。
- SQL 響應耗時：慢 SQL 是影響服務健康的“致命殺手”。據不完全統計，線上系統 40% 響應慢引發的故障的罪魁禍首都是慢 SQL。因此，小玉應該重點關注 SQL 響應耗時，無論是連接慢、執行慢還是結果處理慢，都應及時跟進、儘快恢復。
- 緩存命中率：緩存命中率是一個影響應用健康的間接指標或預警指標，一旦緩存命中率大幅下跌，通常會伴隨着數據庫查詢次數快速上升，壓力過載，最終導致服務不可用等問題。影響緩存命中率的常見因素包括冷數據查詢，緩存熱點，請求量突增等，小玉應該針對性給予處理。
除了上述關鍵鏈路監控外，爲了更好的保障應用健康，小玉還應關注連接池負載、FGC、CPU、內存、磁盤空間使用率、網絡重傳率等其他非鏈路數據的監控。這些內容我們將在第4章《如何保障系統可用性》再進行詳述。
（三）鏈路監控的限制
上文介紹了鏈路監控具備統計精度高、查詢速度快、使用成本低等優勢，那這種優勢的代價又是什麼，它還存在哪些方面的限制？接下來，讓我們來了解下鏈路監控在數據與使用這兩方面的主要限制：
- 預聚合精度：首先，鏈路監控的信息密度直接受預聚合維度的數量影響。預聚合維度數量越多，指標包含的信息就越具體，但是當預聚合維度達到最大時，指標的數量幾乎等同於鏈路明細數據，已經失去了預聚合的意義。如果預聚合維度數量比較少，比如只有應用和接口，沒有 IP，那我們就無法通過指標判斷異常發生在哪些 IP，缺失了關鍵信息。因此，如何合理控制預聚合的維度組合，保留關鍵信息，是鏈路監控非常重要的探索性課題。
- 先驗性知識：預聚合監控相比對後聚合實時分析，一個很重要的特點就是需要輸入先驗性知識，即對哪些數據在哪些維度上進行統計。這些先驗性知識可以是系統內置的，也可以由用戶提前輸入。但是，一旦流量已經發生，就錯過了預聚合的時機。預聚合規則只能作用於對未發生的鏈路數據，指標的生成相對於預聚合規則生效具有一定的滯後性。
- 被動式響應：監控這種使用方式本身受人爲因素影響，需要人來“看”監控。在生產環境的實際應用中，這裏就會引發兩個問題，一是用戶什麼時候來看監控，二是用戶怎麼知道要看哪些監控指標？如果系統沒有問題，那麼用戶是不需要看監控的，如果系統出了問題，用戶如何第一時間知道，並且快速定位異常的監控指標？監控自身無法突破被動式響應的限制，我們可以帶着這些問題來看下一小節將要介紹的鏈路告警功能。
05 鏈路告警
爲了突破監控被動式響應的限制，聰明的程序員又開始琢磨，可不可以寫一段程序，由它來代替人們對所有的監控指標進行週期性掃描，一旦發現某項監控指標符合了預先設定的異常特徵（比如超過某個固定閾值，或環比下跌 30%），就通過短信/電話/郵件等方式主動通知用戶進行處理，這就是告警。
鏈路告警相對於其他告警，在實現原理上並沒有本質的區別，但在使用上卻有不同的側重與分工。由於鏈路數據描述了用戶行爲轉化爲系統請求後，在分佈式系統中的流轉與狀態。因此，鏈路告警可以作爲業務告警與系統告警的一個聯結，起到承上啓下的作用。
比如，某電商系統的交易金額突然下跌了 30%，此時，地址修改接口的錯誤率超過 95%，相關應用的機器也出現磁盤空間不足告警。這時，我們就可以比較清晰的判斷出是由於機器磁盤空間不足，導致地址修改接口不可用，進而導致交易額下跌的業務資損。如果缺失了中間的鏈路告警，我們就很難明確根因，無法快速做出清理磁盤或精準擴容等故障恢復手段。
（一）經典鏈路告警規則
與上一小節的關鍵鏈路監控類似，經典鏈路告警規則包括核心接口的黃金三指標告警：流量下跌、響應變慢、錯誤率上升。此外，異常調用次數增多、慢 SQL 與緩存命中率下跌也是比較重要的鏈路告警規則，可以默認啓用。
（二）如何避免鏈路告警風暴
鏈路告警相比於其他類型的告警，具有一個很重要但也很容易引發問題的維度：接口名稱。由於告警的有效性主要是基於統計數據的趨勢變化進行判斷，一旦數據呈現出明顯的離散現象，就很容易造成誤告警。比如某個接口的流量很小，偶爾發生一次錯誤調用，就很容易觸發錯誤率超過 50% 的告警通知；再比如某個 URL 或 SQL 接口名稱中包含了一個時間戳變量，導致接口極度發散，無法反映出該類接口的實際分佈特徵，很容易引發鏈路告警風暴。
因此，爲了避免由接口名稱引發的誤告警或更爲嚴重的告警風暴，我們可以採取以下措施：
- 對接口名稱進行模板化處理，比如抹去 URL 中不斷變化的 Parameters 部分，只保留相對靜態的 Path 部分。針對 SQL，只保留模板語句，不記錄實際的執行語句，將 SQL 中的參數用 ？代替。
- 通過自動收斂算法對接口名稱進行收斂處理，儘可能避免變量導致的接口發散。
- 設置告警規則時附加一個調用次數限制，比如過濾掉每分鐘調用次數小於 10 次的接口，減少小流量接口引發的誤告警。
- 只面向核心接口設置接口粒度的告警規則，非核心接口不單獨設置告警規則，只看組件類型整體的變化情況。
當然，除了接口名稱以外，實例 IP 或其他自定義維度也可能導致鏈路告警風暴，可以通過告警抑制等手段臨時屏蔽，再參考接口名稱的治理手段進行告警規則優化。
06 小結
本小節詳細介紹了統計分析的兩個關鍵概念：分析對象與聚合維度，以及它們在鏈路實時分析、監控、告警三種不同場景下的用法與區別。三種場景的優劣勢互有補充，層層遞進，不僅幫助我們有效的解決了鏈路問題的定界，也爲其他數據類型的統計分析應用提供了理論參考。因此，我們有必要彙總一下三種不同場景的特徵對比表格，如下所示。
