每日百億查詢請求，咋敢玩可觀測性的呢？

　　百度搜尋中臺系統不但承接了搜尋的阿拉丁流量，也致力於構建各個垂直業務的搜尋能力。隨著業務的不斷髮展，系統的流量規模已經達到百億級別。而在百億流量的背後，是千級別的微服務模組和數十萬的例項數量，如何保證這套複雜系統的高可用、高效能和高可控，全要素多維度的可觀測性成為搜尋中臺系統能力的關鍵。

　　本文首先會介紹什麼是可觀測性以及雲原生時代為什麼更要關注可觀測性，然後闡述搜尋中臺是如何以極低的機器成本打造百億流量的實時指標監控（Metrics）、分散式追蹤（Traces）、日誌查詢（Logs）和拓撲分析（Topos）。

　　 一、雲原生和可觀測性（Observability）

　　1、什麼是可觀測性

　　大家對監控並不陌生，只要有系統存在，就需要有監控幫我們去感知系統發生的問題。而隨著業界傳統技術架構往雲原生架構的邁進，可觀測性逐漸在越來越多的場合中被提到。如Distributed Systems Observability、Monitoring in the time of Cloud Native等都是對分散式系統可觀測性的一些解讀。在CNCF的雲原生定義中，也將可觀測性當成雲原生架構很重要的一個特性CNCF CloudNative Definition 1.0。

　　可觀測性是監控的一個超集。監控關注的是一些具體指標的變化與報警，而可觀測性不僅需要提供對分散式系統所有鏈路執行狀況的高階概覽，還需要在系統發生問題時提供系統鏈路細化的分析，讓開發和運維同學“理解”系統發生的一切行為。

　　目前，業界廣泛推行可觀測性的基本要素包括：

　　指標監控（Metrics）

　　分散式追蹤（Traces）

　　日誌查詢（Logs）

　　經過一些實踐之後，我們還擴充了一個要素：拓撲分析（Topos）。「分散式追蹤」是從微觀角度去看一個請求的完整鏈路，而「拓撲分析」是從宏觀角度去分析問題。比如某個服務 Qps 比平時擴大了數倍，我們需要定位異常流量的源頭，就依賴拓撲分析工具。

　　2、雲原生架構下可觀測性的必要性　　

　　在雲原生時代，傳統的服務架構和研發運維模式正在進行著正規化轉變。微服務、容器化、FAAS（serverless）等技術從根本上改變了應用的研發模式和運維方式。但是，雲原生架構在帶來業務迭代效率指數級提升的同時，也產生了一些新的挑戰。從單體應用往微服務進行的轉變導致原本聚焦的系統變得分散，服務與服務之間連線的複雜度迅速提高，我們對系統整體的掌控力也在逐漸變弱。在這種情況下，如何去快速定位異常，做到系統的清晰可視，就成為了亟需解決的問題。

　　 二、我們面臨的挑戰

　　1、超大系統規模

　　隨著微服務化等技術的使用和新業務的接入，百度搜尋中臺的服務和例項規模不斷增加，服務間的鏈路關係也日趨複雜，在這樣一個龐大系統中建設可觀測性，也面臨著更多的挑戰。　　

　　對於日誌的trace來說，目前搜尋中臺天級別的請求量已經達到了百億級別，如果使用常規的技術方案（如Dapper的思路），將日誌放到集中式儲存裡，意味著我們要付出上百臺機器資源，成本是非常高昂的。部分團隊使用抽樣或針對錯誤請求進行記錄的方式，這種方式在搜尋中臺場景存在著明顯問題：一. 抽樣無法保證覆蓋線上case。二. 很難有一種有效的方法識別錯誤請求，此外，使用者對一些正常請求仍然有trace需求（如誤召回問題）。

　　同樣地，對於指標的資料聚合來說，在超大系統規模下，如何最佳化資源佔用和時效，也是一個極具挑戰的問題。

　　2、從應用到場景的觀測要求

　　隨著搜尋中臺業務場景的不斷豐富，我們的觀測視角也在發生著變化。過去更多關注的是應用維度的資訊，而現在一個應用裡可能有幾十種業務場景，不同場景流量的規模是完全不同。如果只關注應用維度的指標，便可能在一些場景異常時，上層無法感知。如下圖就是一個典型的例子：場景三的流量因為較小，無法從應用級別的指標中提現，因此在異常發生時，監控沒有報警。同時，這種細分場景的指標也可以輔助上層做一定的決策，如不同的場景，其中一個場景透過同步載入，而另一場景透過非同步載入，兩者的超時要求是不一樣的，這時候就可以透過這種細分場景的指標，指導我們做精細化的控制。　　

　　但是，從應用到場景的細分，導致系統的指標量級急劇擴大，達到了百萬級。這對於指標的聚合和計算來說，就成為一個新的挑戰。

　　3、對拓撲鏈路的宏觀分析

　　在雲原生架構下，應用與應用之間的連線關係變得越來越複雜。分散式追蹤可以幫助我們定位某個具體請求的問題。而在系統出現一些宏觀問題：流量劇增，97分位耗時增加，拒絕率增加等，就需要拓撲分析工具幫助我們進行定位。同時它對上層決策也有比較強的指導意義。如下圖右側的例子：商品搜尋有兩類場景，第1類場景有運營活動，預計增加300qps的流量，如果沒有拓撲分析工具的話，我們就很難評估各個服務的容量Buffer。　　

　　 三、我們做了什麼

　　我們在去年，對可觀測性的四個要素進行了探索和實踐，併發布了全要素的觀測平臺，為保障搜尋中臺的可用性提供了有力保障。

　　1、日誌查詢、分散式追蹤

　　隨著業務規模的增長，搜尋中臺整體的日誌量級達到了PB級的規模，透過離線儲存日誌資料，再進行索引的方式會帶來巨大的資源開銷。而我們在這裡使用了一種突破性的解決方案：在離線結合，離線儲存了少量的種子資訊，線上直接複用線上的日誌（0成本）。　　

　　具體做法是：

　　在流量入口層將logid、ip、訪問的時間戳存下來，存到一個kv儲存裡。

　　當使用者使用logid檢索的時候，在kv儲存中查詢logid對應的ip和時間戳。

　　透過ip和時間戳去對應的例項獲取完整的日誌資訊。

　　透過規則解析日誌，獲取下游例項的ip和時間戳資訊。

　　重複3-4的廣度遍歷過程，得到完整的呼叫鏈路拓撲。

　　但是這裡仍然存在一個問題：Trace時間較長。

　　例項需要需要對自己的日誌檔案進行全量 grep，這在日誌檔案大、請求鏈路長的時候，會導致trace的時間較長，同時也會帶來穩定性的衝擊。這裡我們使用了按時間動態N分搜尋的思路，利用請求的時間資訊和時間有序的日誌結構，快速進行N分查詢。

　　以下圖給大家舉例：圖中日誌檔案是 20 點的日誌檔案，當前需要查詢 20 : 15 分的一個日誌請求。因為 15 分鐘剛好是小時的 1/4，所以會先 fseek 這個檔案的 1/4 位置。當前 1/4 段的日誌資訊在 20 : 13，這個時候下半段的日誌檔案就是 47 分鐘的日誌資料，那就會再往下偏移 2/47，重新進行fseek。重複這個過程就可以快速查詢對應的詳細日誌資訊。　　

　　這種檢索方式可以獲得非常快的收斂速度，單例項的日誌檢索耗時控制在 100ms 以內，對 io 的影響基本忽略不計。同時，使用者整體的檢索時間也控制在了秒級別。

　　2、指標監控

　　因為我們的觀測視角從應用級別發展到了場景級別，指標數量也從萬級別增加到了百萬級別，所以我們對監控架構進行了重新設計。這張圖就是升級後的一個架構圖。

　　它的主體思想是線上例項嵌一個依賴庫，這個依賴庫會收集所有的指標資訊，並將它做一定的預聚合，之後採集器輪詢式的去獲取線上的例項的指標資料，然後把聚合後的資料寫到tsdb裡。值得注意的一點，這套方案和業界的一些指標方案較大的不同：例項維度的指標會在採集器裡實時聚合，轉換成場景或服務維度的指標，隨後例項的維度指標會被丟棄，不再儲存到tsdb中。因為例項維度的指標參考意義有限，我們是使用聚合後的資料等來分析應用的執行情況。　　

　　在這套架構裡，我們對計算和儲存進行了很多的最佳化，從線上指標變化到平臺展現，只需要2s的反饋時間，資源開銷非常輕量。以指標的聚合為例：線上例項只進行累加操作，而採集器會存上一次抓取的快照資訊，和當前這一次採集做對比，進行線性差值計算。這種方式對線上例項的資源開銷是肉眼不可見的。同時也可以方便的去產出Qps、延遲等資訊。　　

　　除了Qps、延遲之外，我們也最佳化了分位耗時的計算方式。

　　分位耗時的計算常規方案是將請求的耗時做排序，然後取它的分位位置上的耗時數值。這種計算方式在請求量級較高的時候，資源佔用非常高。因此我們採用了分桶計算的方式，按請求的耗時進行分桶，當請求執行結束時，在對應耗時的桶裡加1；而在計算分位值時，先確定分位值所在的桶，桶內資料則認為服從線性分佈，透過這樣的思路可以推導如下圖的公式。　　

　　這樣的好處是資源開銷低，可實時計算，但是缺點是會損失一部分精度。這個精度取決於分桶的粒度，在搜尋中臺使用的桶大小是30ms，一般誤差在15ms以內，可以滿足效能觀測的需求。

　　3、拓撲分析　　

　　拓撲分析的實現利用了指標監控的運作機制。

　　首先，對流量進行染色，並將染色資訊透過RPC傳遞到各個服務。透過這種方式，讓每個span（注：span的定義來自Dapper論文）持有場景的標識以及上游span的名稱。場景標識可以區分不同場景的流量，而span名稱和上游span名稱可以建立父子的連線關係。這些span複用了上述指標計算的機制，透過將span的資訊存入指標中，產出對應的效能資料。當使用者提供一個場景標識時，平臺會把它的全部指標提取出來，根據指標內的span資訊，串聯成完整的呼叫拓撲。　　

　　 四、最後

　　到這裡可觀測性的四個基本要素基本講述完了。在這四個要素之上，我們孵化了很多的應用產品，如歷史快照、智慧報警、拒絕分析等。透過這些產品，可以更好的幫助我們快速去發現和分析問題。

　　當然，可觀測性的工作並不止步於此。我們也在依託這套觀測系統，打造一些自適應、自調整的柔性機制，在異常出現時，能夠自動容忍和恢復，最大化的保持系統的生命力。