百度大規模時序資料儲存（一）| 監控場景的時序資料

負責百度運維大資料儲存平臺的設計和研發，致力於追求大規模儲存系統的高效能和高可用。

百度運維大資料平臺的時序資料儲存系統（Time Series Database，TSDB）是智慧運維團隊於 2014 年自研的一套分散式監控資料儲存系統。發展至今，經歷過幾次大的架構更迭，現在 TSDB 作為百度監控系統的底層儲存服務，承載了公司諸多核心產品線的監控資料儲存和查詢需求，日均寫入資料點數以萬億計，承載 50K QPS的查詢請求。百度大規模時序資料儲存系列文章將介紹 TSDB 在監控場景的應用和系統設計實踐，本文將介紹 TSDB 在監控場景下的應用以及系統設計面臨的技術挑戰。

百度的監控時序資料來源於監控系統在全網數十萬臺伺服器上部署的Agent，Agent 採集各類監控物件的監控項，並以不同的頻率向 TSDB 上報這些監控項的測量值。透過一張 CPU 空閒率趨勢圖可以直觀地看到監控時序資料。

圖1    CPU 空閒率趨勢圖

監控物件可以分為三類：

• 機器級：物理機、虛擬機器、作業系統等

• 例項級：容器、程式、日誌等

• 服務級（邏輯物件）：服務、服務組、叢集等 

圖2    監控物件

監控物件的一些需要關注的指標，如機器的 CPU 空閒率、記憶體使用率、網路卡頻寬以及磁碟 I/O等，稱為監控項。除了這些通用的機器監控項以外，根據不同的需求還可以自定義監控項，比如資料服務的緩衝對列長度、查詢請求的平均響應時間等。

標籤是一對 Key-Value，標識了監控物件在某個維度（Key）的特徵（Value），一個監控物件也可以從多個維度來標識，比如部署在多地域、多運營商的服務可以有地域和運營商兩個維度，根據不同的維度取值可以生成不同標籤，如 (“機房=杭州”, “運營商=電信”) 和 (“機房=北京”, “運營商=聯通”)。

把監控物件的監控項測量值，按照時間的順序排列起來就構成了時間序列：

時間序列 = 監控物件 + 標籤列表 + 監控項 + 資料點

其中資料點由時間戳和取值構成，每個時間序列對應到趨勢圖上的一條曲線。

透過 Web 頁面、HTTP API 或命令列工具，使用者可以方便地從 TSDB 種獲取到自己關注的資料：

• 在日常運維工作中，運維工程師透過 Web 頁面人工檢視趨勢圖、同環比報表和熱力圖等來了解系統的最新或歷史狀態

• 一些自動化的服務透過高頻、批次地查詢時序資料來進行資料分析，進一步地挖掘資料的價值，如異常檢測、匯聚計算、根因定位等

在時序資料的大多數使用場景中，我們更加關注最近一段時間的資料，而這些資料的產生卻是 7 *24 小時不間斷的，這就導致時間序列的讀請求與寫請求特徵迥異且量級懸殊：

• 隨機寫：不同的時間序列按照不同頻率各自寫入資料點

• 順序讀：指定時間範圍讀取一段連續的資料點

• 寫多讀少：寫入請求量佔比達九成以上

前面提到，可以使用標籤來從多個維度標識一個監控物件，在獲取資料時，也可以透過標籤，將監控物件按維度進行篩選聚合。如，對於一個多地域、多運營商部署的服務，獲取其在某段時間內、不同地域相同運營商的總流量：

圖3    多維度聚合查詢

在百度，有數千萬的監控物件，時間序列的總量近 10 億。監控項的採集週期通常為 10s，在高時效性要求的場景下要求 5s 的採集週期，這意味著每一秒鐘都有數千萬個資料點要寫入 TSDB，每天產生的資料點規模達到萬億量級。與此同時，TSDB 每秒鐘還要處理數萬次查詢請求，由於查詢有一定的突發性，峰值的查詢流量可達到常態流量的數百倍，且根據業務的需求，絕大多數的請求都應該能在 500ms 返回結果給使用者。

在處理 7 * 24 小時持續高併發寫入的同時，還要應對高併發的查詢請求，負載不可謂不重，高吞吐和低延遲是對 TSDB 的基本要求。此外，打鐵還需自身硬，作為監控系統自身的基礎服務，其可用性必須有所保障，根據業務需求，我們制定的可用性目標至少是 99.99%。

前文提到監控時序資料的使用場景有很多，包括匯聚值報警、檢視指標的歷史趨勢圖、實時的資料包表（天/周/季/年的同/環比）、趨勢異常檢測以及歷史資料離線分析等，這些場景分別有著獨特的查詢特點：

可以看到，每種場景的查詢資料量、資料的分佈以及對資料時效性的需求不盡相同，TSDB 需要在這些場景下都能夠高效地獲取資料。

百度的產品線數量、業務規模在不斷地增加，相應地，監控系統的體量也隨著增長，TSDB 的規模也勢必增長，必然會面臨容量、成本和可用性的壓力。低成本地換取系統容量的增加和可用性的提升，是在系統設計時需要考慮的重點之一。

不同的業務對監控資料的儲存時長有不同的要求，不同的場景對資料的粒度也有不同的要求，例如，想要知道某服務過去一天的總流量相比去年同期的變化，需要資料至少儲存一年，但資料的粒度可以是天級；而對於最近一個小時的流量，希望能夠支援更細粒度的監控資料，以便能夠發現短暫的流量突變。

本文主要介紹了監控場景時序資料的特點，以及我們在設計時序資料儲存時面臨的挑戰，對於百度在應對這些挑戰時的設計實踐，敬請期待下期文章。