基於Falcon的滴滴內部監控系統

作者簡介

聶安，滴滴運維研發工程師，長期從事監控、部署等運維工具平台的開發。現就職於滴滴，曾就職於阿里、小米。

很高興和大家一起分享滴滴監控系統 DD-Falcon 近期的一些進展。今天分享主要包括如下幾個部分 (技術架構、產品形態)：

• DD-Falcon 的系統架構

• DD-Falcon 相比 Open-Falcon 的一些改進

• 目前遇到的問題

• 將來的幾個規劃

DD-Falcon 脫胎於開源監控系統 Open-Falcon。Open-Falcon 是小米運維團隊 2015 年開源的一款監控產品，目前已應用在 小米、美團、滴滴、快網、JD 等眾多互聯網公司，Open-Falcon 的詳情可參見 [1]。

在介紹 DD-Falcon 之前，我們先介紹下 Oepn-Falcon 的系統架構。

上圖是 Open-Falcon（後簡稱 OF）v0.1 的典型架構（v0.2 有些許調整）。橙色的線代表了配置流，綠色的線代表了數據流，紫色的線代表了報警鏈路。

配置信息，由用戶產生，並逐級應用到各個組件，主要流程是:

用戶 –> UI(Portal) –> 配置中心(HBS) –> 採集(Agent), 報警(Judge), 計算(Aggr/Nodata)

其中，HBS 原意為心跳服務、後逐步發展成為配置中心。

監控數據的整個生命周期，分為 採集、收集、分發、存儲、消費等幾個環節。

Falcon-Agent 是主要的採集器和收集器，它被部署在每個單機實例上(物理機或者容器)，採集本機基礎信息（如 CPU、內存、磁碟等，自動採集）、 本機部署的應用程序信息（如埠信息、進程信息等，由用戶配置），同時也會作為代理、接收本機應用程序 主動上報的業務監控數據（如 App 埋點&內存統計產生的 Metrics 數據 等）。Falcon-Agent 將自己採集 或者 收集的監控數據，主動推送給 Transfer。

Transfer 是數據分發組件，將接收到的監控數據 一式兩份、分別發送給 數據存儲組件 Graph 和實時報警組件 Judge。Graph 和 Judge 都採用一致性哈希做數據分片，以提高橫向擴展能力。Transfer 按照哈希規則，將監控數據主動推送到固定的分片上去，對數據生產者屏蔽分片細節。

Graph 提供數據存儲能力。Graph 底層使用 rrdtool 做單個指標的存儲，rrdtool 的特點決定了單個指標存儲空間固定、數據自動降採樣，這個特點很適合監控熱數據的存儲。Graph 在應用層對 rrdtool 做了寫優化（緩存, 分批磁碟寫等），使得一個 Graph 實例能夠處理 8萬+/秒的數據點寫入頻率。

Graph 一般由多個實例構成集群，不同實例存儲不同的監控數據。為了屏蔽存儲集群的分片細節，提供了 Query 模塊，實現了和 Transfer 一樣的一致性哈希分片邏輯，對數據消費者屏蔽存儲分片細節。Transfer + Graph + Query 構成了功能完整、橫向可擴展、技術門檻低的分散式時間序列化數據存儲系統，這是 Open-Falcon 的核心競爭力所在。

存儲之上，長出了用戶最常用的監控看圖功能，對應到上圖中的 Dashboard 模塊。另外，集群聚合模塊Aggr、數據中斷報警模塊 Nodata 都會消費存儲的數據。

Judge 和 Alarm 兩個模塊構成了 OF 的報警鏈路。Judge 由 Transfer 上報的監控數據驅動，結合用戶配置的報警策略，實時計算、產生報警事件。Alarm 組件對報警事件做一些收斂處理後，將最終的報警消息推送到各報警通道。OF 的報警，是由監控數據驅動的，沒有數據上報 就 不會報警。

以上大概介紹了下 OF 的系統架構。相比 OF，DD-Falcon（下面簡稱 DF）的主要組件結構如下。

配置流由棕色曲線表示，數據流由黑色曲線表示。

配置流從右向左，依次為:

用戶 –> 配置(fe/api) –> 存儲(config) –> 生效: 採集(agent/log/net/url), 清洗(transfer), 報警(judge)

數據流從左向右，依次為:

服務(apps) –> 採集 –> 收集 –> 清洗 –> 存儲 –> 消費: 報警, 看圖, 第三方

DF 的配置流，與 OF 的相似，不再贅述。DF 的數據流，核心存儲部分繼續使用 OF 原生組件（transfer + graph + query）, 同時在數據採集、清洗、報警等方面做了調整。

DF 的採集覆蓋了機器指標（如CPU、內存、磁碟）、應用指標（如埠信息、進程信息）、業務指標（如 rps、error_ratio、latency）等。

業務指標，主要是通過 log 本機日誌實時分 和 metrics 業務統計 獲取的。log 分析方式是歷史沿襲，比較方便、但資源消耗不可控，正在被逐步弱化。

metrics 是類似開源 statsd [2] 的解決方案，通過業務代碼埋點 將狀態數據（rpc 調用質量、計數等）上報到本機 metrics-agent，再經由 metrics-agent 周期性的統計聚合，將最終的業務統計數據上報到 本機 agent 上（agent 充當了收集器）。

metrics 對於無狀態的服務非常友好，正在逐步成為主流（有狀態的服務可以在 應用內存中 做統計計數，正如 OF 一樣）。

機器指標、應用指標的採集主要是由 本機上的 agent（DF-Agent）完成的，也會自動採集、主動上報數據，與 OF 相似，不再贅述。

為了應對上報峰值、網路抖動等問題，DF 增加了 nsq [3] 數據緩存隊列，agent上報的監控數據先被q到nsq、再由分發組件消費。nsq按照服務單元（su） 劃分topic。

在nsq數據緩存和存儲之間，增加了一個數據清洗環節，實現了容量控制、垃圾數據過濾等機制，用於監控系統的自我保護。後面會詳細講述。

DF 復用了 OF 的 transfer + graph + query 三個組件，在此基礎上將數據索引模塊index獨立出來（OF 使用 mysql 做簡單的查詢索引）。索引信息，是在指標寫入graph時同步生成的，可以滿足分級查詢的需求。索引模塊是 DF 對 OF 的主要改進之一。

看圖，是長在存儲上的一個功能。DF 的支持動態看圖、臨時圖、監控大盤等產品形態，支持同環比看圖，支持靈活的聚合展示等。

與 OF 相比，報警變成了存儲模塊的一個下游，不再擁有獨立的數據上報鏈路。judge 模塊從 config 處獲取報警配置，然後按需從存儲組件拉取命中的指標數據，進行實時報警計算，產出報警事件。alarm 模塊做報警收斂處理，並將最終的報警通知交給報警通道服務 notify 處理。notify 支持多種報警通道，包括釘釘、語音、簡訊、郵件等。

DF 將報警數據的獲取方式由推變拉，給報警判斷帶來了巨大的靈活性。報警方式由推變拉是 DF 對 OF 的另一個主要改進。

DF 的監控數據完全開放，供各個業務線使用。特別的，不同的業務場景看圖功能的產品形態差異較大，開放數據、讓用戶自定義很可能是監控平台後期的大趨勢。我們正計劃結合 Grafana，給一種低成本的、較通用的個性化看圖解決方案。

以上是對 DD-Falcon 的一個簡單介紹。下面重點聊一下相比 Open-Falcon，我們的一些改進。

主要改進

DD-Falcon 相比 Open-Falcon，主要有如下改進:

1. 監控數據按服務單元分類

2. 增加垃圾數據清洗

3. 分級索引

4. 精簡 RRA

5. 巡檢大盤支持同環比

6. 重組看圖首頁

7. 報警數據獲取由推變拉

8. 幹掉報警模板

9. 重新定義 nodata

下面，針對每一項做下詳細介紹

每一個監控數據點，不管是機器指標、應用指標還是業務指標，都必須標明 所屬的 服務單元 su。

服務單元定義:

su = ${cluster}.${uniq-service-name}

如 gz01.falcon-query 代表 「falcon-query服務 的 gz01 部署集群」（gz01 為邏輯機房標識）

監控數據點舉例：

強制 su 的約束，給後續的緩存分片、數據清洗、報警、看圖展示等增加了一個常用的、可信的服務維度。如，看監控圖時，服務樹與 su 嚴格對應，查看某個服務的監控圖會很方便:

DD-Falcon 繼承了 OF 允許用戶上報自定義數據的功能，帶來了很多便利，同時也給帶來了垃圾數據的困擾。一些用戶，將 traceid、errmsg 等非 tsd 屬性的數據，直接上報到了監控系統。另外，一些通用的中間件採集，也可能會將 orderid 等信息上報到監控系統。

有幾次，我們不得不通過清空歷史數據的方式來清理垃圾數據，監控系統表示受傷很深。垃圾數據經常要事後發現、人肉攔截，開發人員表示無法接受。為此，我們在 nsq 到存儲集群間，增加了一個垃圾數據清洗環節，如下圖所示位置

每個監控數據點，都有幾個固定的維度，包括 su、metric、tagk(如 host、trace)、tagv，垃圾數據一般能在某一個維度上有所體現。下面的例中，垃圾數據就體現在 tagk=trace 這個維度上。另外，垃圾數據通常較」明顯」，通過簡單的字元串匹配就能識別出來。

因此，我們的數據清洗主要集中在如下兩個方面:

1. 清洗維度: 服務單元 su, 指標 metric, tagk, tagv, metric/tagk

2. 清洗方式: 字元串 相等, 前綴, 後綴, 包含

舉例: 垃圾指標，及對應的清洗規則:

從目前的經驗來看, 95% 的清洗規則, 是通過 tagv 前綴匹配 實現的。

垃圾數據，可以通過服務的指標總量、單位時間指標增量、指標最新上報時間等方式被定位，再結合簡單的學習演算法，就能自動生成過濾規則。最終，數據清洗會變得自動化。

3. 分級索引

DD-Falcon 根據滴滴的用戶習慣，實現了一個多級索引結構，讓用戶看圖、數據讀取更靈活。

如上圖，左側是一個典型的監控指標，右側是分級索引。用戶首先選擇要查看的服務，然後選擇一個監控指標，最後設置每個 tagk 的取值；經過這幾步，用戶就能拿到一系列備選曲線，並能夠從中選擇自己想要的曲線。整個過程，耗時不超過 1 秒，用戶體驗很好。

我們採用全內存的方式，實現了上述結構，性能數據如下:

• 1000 萬指標: 構建耗時 30s, 消耗內存 2GB

• 1 億指標: 構建耗時 5min, 消耗內存 17GB

之所以選擇內存方式，是 快速重建索引的需要（早期垃圾數據預防未到位，業務上要求 10min 內恢復服務）。當前沒有計劃做分片，原因在於:

1. 廉價的高內存主機已經很普遍，

2. 內存消耗優化後預計還可以降低 50%

靈活的索引，可能是監控數據查詢語言的雛形，後續還會繼續進化。

4. 精簡 RRA

DD-Falcon 只保留了均值降採樣、幹掉了最大值&最小值降採樣，原因在於 最大值&最小值降採樣使用率過低。DD-Falcon 的高精度數據會保存 8 天，這個是同環比報警的需要。

精簡後的 RRA，如下圖所示:

按需調整 rra 後，節省了更多的磁碟資源

這是一個產品形態上的完善，最終將回饋到 Open-Falcon 社區。大部分公司，業務都是以 1 天或者 1 周為周期變化的（節假日除外），因此我們的同環比只支持 1 天和 1 周兩個選項。

一個典型的每日巡檢大盤，如下圖

其中，綠線代表今天、藍線代表昨天、紅線代表 1 周前，同環比波動一目了然。目前，60% 的巡檢大盤，都是同環比。

我們的監控數據已經帶上了服務單元標識（之前已經有了機器標識），我們的索引已經支持分級查詢，因此我們將 首頁看圖的步驟約定為：

服務單元 –> 節點 –> 機器 –> 指標分組 –> 看圖 –> 訂閱大盤

指標分組，是將用戶常用的、類似的指標歸為一個 tab，以方便查詢。

這是一個比較定製的功能，不一定適合社區環境。最終的首頁看圖，效果如下圖:

DD-Falcon 的報警數據獲取，調整為 judge 主動從存儲拉數據。整個報警過程，變為:

拉數據更靈活，可以實現多種判斷條件: 多條件組合判斷, 同環比報警, 集群報警等。

下圖是 DD-Falcon 的報警配置頁面，

補充一句，在智能報警時代，拉數據的方式必將全面取代推數據的方式，我們也算是提前做了過渡。

OF 為了簡化報警策略的管理，繼承了 zabbix 報警模板的衣缽。從最後的效果看，模板並沒有明顯降低管理成本，卻帶來了很高的學習成本，特別是模板間的繼承、覆蓋云云，最後連維護者都搞不清了。

因此，DD-Falcon 幹掉了模板的概念，每個報警配置就是一條策略，策略和策略之間沒有關聯關係，策略藉助服務樹的節點父子關係實現繼承和動態生效，藉助節點排除實現特例。雖然有可能增加管理成本，但大大降低了用戶的學習成本，這個收益我們更關注。

如下是對典型場景下使用報警模板與否的利弊分析，關注的童鞋可以了解下

DD-Falcon 重新定義了 nodata 報警的業務場景，也簡化了產品形態。具體，如下圖

nodata 報警比較小眾，只適用於 核心指標 + 數據驅動報警的場景，有興趣可以私聊交流下。

以上，是 DD-Falcon 相比 OF 的一些主要改進，再次概括下:

已知問題

DD-Falcon 目前主要面臨如下問題：

1、非周期的數據處理能力不足

• 報警延時風險

• 斷點，環比看圖不易發現問題

• 歷史數據嚴重有損(rrdtool 不能很好地支持非周期數據)

2、打通非時間序列化的系統

• trace（目前通過 服務、機器、指標、時間段這四個固定維度，做關聯跳轉）

將來規劃

DD-Falcon 的平台建設工作，已經趨於完善。後續，我們計劃在如下幾個方面重點投入:

1、全快准穩的發現問題

• 智能報警（低成本）

• 集群報警

2、輔助定位問題

• 基於服務間關聯關係的報警

• 個性化的看圖解決方案（Grafana）

社區介紹

歡迎大家，加入Open-Falcon的開源社區:

• 官網: http://open-falcon.org

• Github: https://github.com/open-falcon

• QQ討論組: 373249123 / 516088946 / 469342415

• 微信公眾號: OpenFalcon

Q&A

提問1：DD-Falcon 源碼也是 go 語言嗎？

聶安: 除了 fe 是 react 外，其他都是 golang

提問2： 能大概說下 Falcon 相對於 prometheus 的區別優劣？

聶安:

1. Falcon 經過了數家公司 2+億指標的海量數據驗證，在穩定性、易用性方面都沒有問題。

2. Prometheus 是隨著 Borgmon 概念而走紅的新一代監控系統，在部分設計理念上更優一些。我們也在借鑒 Prometheus~

提問3：能否介紹下 DD-falcon 如何結合 cmdb 使用？

聶安: DD 內部有服務樹，兩者通過服務單元在數據採集、展示、報警燈方面緊密結合。特別的，我們的部署系統已經將服務樹規範推廣到各個服務和業務，監控系統基本可以拿來主義~

提問4：falcon 是否支持進程監控？比如從 /proc 目錄下面獲取數據

聶安: falcon支持進程監控，方式即為 從 /proc 獲取信息。詳情，可以參見 https://github.com/open-falcon/falcon-plus/tree/master/modules/agent

提問5：DD Falcon 目前有多少人在開發維護？

聶安: 3人（目前正在補強到5人）

提問6：falcon 支持按星期和月份做同比和環比嗎？

聶安: 支持 1 周的同比，不支持 1 月的 環比。因為滴滴的業務大部分是以7天為周期的，沒有以月為周期的。產品形態，服務於業務特點~

提問7：DD-Falcon 的新特性會提交到開源版的 Falcon 中嗎？

聶安: 會，我們會主動推進這件事。另外，服務樹也可能在開源考慮範圍內

提問8：Falcon 支持簡訊、郵件和微信報警嗎？

聶安: 支持。微信報警 可能要根據公司內部情況，做一下定製

提問9：小型公司，業務訪問量小，人手少，應用還是單體，有必要使用DF嗎，或者更輕量級監控推薦一下

聶安: Open-Falcon v0.2 非常輕量級，很適合 10-100 人左右的公司，可以考慮下: https://github.com/open-falcon

提問10：問個問題，這套系統適合多大的系統使用，比如說十幾台機器的小項目適合嗎？本身需要多少台機器可以部署？

聶安: DD-Falcon 和 Open-Falcon 都是可擴展的，單機部署也沒問題。DD-Falcon 的監控比，大概是 1: 1000，後續做完高可用可能會降低一些

提問11：能和攜程開源的 cat 對比一下嗎？

聶安: cat 是基於日誌的、Java 友好的監控系統，提供了通用監控、trace 等能力，對於 Java 系的公司可能會更好（抱歉 沒有詳細了解過）。Open-Falcon 是通用監控系統，未針對語言做優化，可以通過各個擴展來快速搭建服務能力

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！