百億級流量的百度搜索中臺，是怎麼作可觀測性建設的？

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

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

1、雲原生和可觀測性（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）等技術從根本上改變了應用的研發模式和運維方式。可是，雲原生架構在帶來業務迭代效率指數級提高的同時，也產生了一些新的挑戰。從單體應用往微服務進行的轉變致使本來聚焦的系統變得分散，服務與服務之間鏈接的複雜度迅速提升，咱們對系統總體的掌控力也在逐漸變弱。在這種狀況下，如何去快速定位異常，作到系統的清晰可視，就成爲了亟需解決的問題。

2、咱們面臨的挑戰

1）超大系統規模

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

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

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

隨着搜索中臺業務場景的不斷豐富，咱們的觀測視角也在發生着變化。過去更多關注的是應用維度的信息，而如今一個應用裏可能有幾十種業務場景，不一樣場景流量的規模是徹底不一樣。若是隻關注應用維度的指標，即可能在一些場景異常時，上層沒法感知。以下圖就是一個典型的例子：場景三的流量由於較小，沒法從應用級別的指標中提現，所以在異常發生時，監控沒有報警。同時，這種細分場景的指標也能夠輔助上層作必定的決策，如不一樣的場景，其中一個場景經過同步加載，而另外一場景經過異步加載，二者的超時要求是不同的，這時候就能夠經過這種細分場景的指標，指導咱們作精細化的控制。

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

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

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

3、咱們作了什麼

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

1）日誌查詢、分佈式追蹤

隨着業務規模的增加，搜索中臺總體的日誌量級達到了PB級的規模，經過離線存儲日誌數據，再進行索引的方式會帶來巨大的資源開銷。而咱們在這裏使用了一種突破性的解決方案：在離線結合，離線存儲了少許的種子信息，在線直接複用線上的日誌（0成本）。

具體作法是：

1. 在流量入口層將logid、ip、訪問的時間戳存下來，存到一個kv存儲裏。
2. 當用戶使用logid檢索的時候，在kv存儲中查詢logid對應的ip和時間戳。
3. 經過ip和時間戳去對應的實例獲取完整的日誌信息。
4. 經過規則解析日誌，獲取下游實例的ip和時間戳信息。
5. 重複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信息，串聯成完整的調用拓撲。

4、最後

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

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

原文連接：https://mp.weixin.qq.com/s/5R1vJBhN8KBE0Rj7cWOdgA

---

百度架構師

百度官方技術公衆號上線啦！

技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會

招聘信息 · 內推信息 · 技術書籍 · 百度周邊

歡迎各位同窗關注！