創業公司如何快速構建高效的監控系統？

12 月 7 日，在 2018 ArchSummit 全球架構師峯會·運維與監控專場，七牛雲資深運維開發工程師賀強帶來了主題爲《如何快速構建高效的監控系統》的內容分享。

本文是對演講內容的實錄整理。

你們好，今天給你們帶來的分享是如何在創業公司去搭建一套高效快速的運維繫統。我演講的主要內容有：談到高效，咱們如何來定義所謂的高效的監控系統；如何作好一個監控系統的選型和設計；七牛雲內部的監控系統介紹；最後會和你們一塊兒來探討監控的發展趨勢以及將來展望。

如何定義「高效」的監控系統？

在我認爲，高效的系統應該包含如下幾個特性：高可靠、易擴展、自適應、開放性。

01 高可靠

全部的可以體現高可靠的幾點信息，第一是整個系統沒有單點的模塊，無單點的風險，這是咱們平常作系統或者作運維、作系統設計的時候須要首先考慮的問題。第二是自己會提供一個豐富的自採集系統層面的監控項，包括系統內核、設備、應用的一些資源消耗等信息。第三是它所支持的監控種類比較豐富，由於咱們如今的應用的類型也比較多，像常見的對應用監控的需求，好比日誌監控、端口監控、RPC 監控等等，這些可以很方便的進行添加和管理。第三點是比較基礎的，高效、延時低，不管是數據採集、上報、計算處理、再到通知，以及到用戶收到這個通知，整個效率是比較高的，這也是和高效可以對應起來的。最後是易於 debug，若是開發人員說監控沒有報警或者誤報警，如何 debug 這個信息，快速修復問題。這是我對高可靠的一些認識。

02 易擴展

它實際上是咱們系統的開發過程當中，對於運維側以及部署和擴容方面的考慮，這個系統很容易擴容和部署，它的依賴比較小。其次，它可以達到快速部署的基礎是它的數據存儲是要集羣化管理，而不是數據和單機綁定，它的服務邏輯層須要去可水平擴展，隨着業務對監控的需求不斷增長，監控的壓力變大的時候，可以快速地進行服務層面的水平擴展。

03 自適應

我認爲這點比較重要。咱們不少傳統的監控系統都是比較機械一點，爲何說機械？就是說它監控的添加、修改之類的，都是須要咱們人工手動的作一些不少冗餘的操做，而不能隨着服務器服務，咱們監控對象的生命週期的運轉，好比說服務器上線、下線、運維、維修、新添加的服務或者服務下線，可以進行動態關聯，監控也隨着這些對象的生命週期進行變化。還有是人員流轉，咱們常常會遇到公司內部的員工入職、轉崗、離職等方面，還會隨着他的崗位狀態運轉可以自動匹配，是否對它進行報警發送以及刪除。

04 開放性

首先是要對外提供 SDK 或者 API ，除了咱們本身運維側採集一些監控，提供一些既有的監控，還容許第三方開發和其餘的人員對監控人員 push 一些數據，以及對這些數據的讀取、處理。

這樣幾個特徵，我認爲是構成高效監控系統的必要因素。

如何作好監控系統的選型和設計？

談這點須要基於公司的現狀去談這個選型和設計。由於在創業初期，最開始可能對運維和監控的關注度並不高，咱們在這塊用於很粗粒度的方式去解決。拿七牛雲來講，從如今往前推一年的時間，用的監控有 32 套單機版的 Prometheus。

具體說說它的問題。首先單機 Prometheus，它是一個開源很強大的單機版監控，它的問題也是它的特色，有一套很牛逼的查詢語法，支持強大的數據查詢功能，可以知足各類方位、各類姿式對數據的需求，經過它的語句組合。這樣也致使了一個問題，運維人員若是沒有深刻研究這套語法的話，就很難掌握靈活的語句去配置你的報警，存在的問題是少數人可以掌握這個問題，學習成本比較高，而精通的人更少。

目前這個 Prometheus 沒有比較好的分佈式解決方案，因此出現了 32 套 Prometheus分業務去構建它的監控，並且可能一個業務裏面還存在多套 Prometheus，由於受到單機性能的影響，隨着監控指標數據量不斷增長，出現了這個瓶頸，出現以後咱們還要再進行擴容。這樣長時間下來，會出現多套集羣套用，數據和配置分佈雜亂，無統一入口。

咱們作的更可能是添加監控、修改閾值和條件，原生的 Prometheus 是經過配置文件的方式，Prometheus 啓動的時候加載，而後會出現的配置文件大概有好幾千行，一行表明一個監控，一行是一個很是複雜的查詢語句，天天有好多監控的需求，須要重複的修改這些配置文件，無界面化管理，操做效率很是低。

最後一個問題，我認爲比較重要的是監控和咱們的業務服務器，還有業務服務之間沒有一個動態關聯關係。由於都是靜態的，有任何一方的改動均可能出現誤報的狀況，咱們調整了機器擴容或者下線機器，須要徹底手動修改配置和 Prometheus。

基於這樣的狀況，咱們指望改善這個現狀，由於這樣的規模只會讓狀況變的愈來愈糟，不符合高效運維的定義。

首先設立幾個目標，第一個是如何把這 32 套 Prometheus 進行統一化、統一入口，做爲一個運維的統一監控平臺，來知足咱們全部業務對於平常監控和數據處理、查詢、報警的需求，第一個目標是化簡爲繁。第二是可視化，包括監控配置可視化和數據展現可視化。第三是動態關聯，保持監控對象的動態感知能力。

第四個也比較重要，咱們作一套新的監控，必需要考慮老的監控的東西須要往新的東西遷移，在遷移的時候，必需要考慮成本。若是作一套徹底和新的結構遷移出東西，成本會很是高，還有歷史數據的遷移，咱們用了監控數據作一些東西，它的數據確定還會遷移到新的數據上來，讓它繼續發揮做用。它如何遷移、如何進行兼容，咱們首先定義了一個目標。

基於這個目標，咱們作一個方案選型，首先仍是考慮 Prometheus，由於咱們之前用的是 Prometheus，它也很強大，咱們不肯意放棄。

優勢是組件少、部署很方便；PromQL 強大的數據查詢語法。它有很是強大的查詢數據的方法，好比說一般會對數據進行打標籤，對這個數據的標籤進行一些組合，而後查詢到你須要的這些數據，在這些組合基礎上，它還能夠提供一些很方便的函數，好比說求和、求平均值、求方差、求最大最小、求分位數，咱們一般須要寫一些代碼或者寫一些腳原本知足這些函數可以簡單達到的效果。

第三，它是一個很是高可靠的時序數庫，相似於一些優秀的數據庫，很是符合咱們監控時序數據的存儲和展現。第四，它具備很是豐富的開源社區 exporter。Prometheus 社區裏面會有一些針對各類開源軟件的數據收集的一些組件，都能找到對應的 exporter 組件，只要把它跑起來，不用做爲一個 DBA 或者專業的運營人員，你也能夠很方便的拿到數據庫應該關注的指標，而後這些指標的數據表現形式是什麼樣的，並且配套的在平臺上已經有不少開源的東西，甚至能夠一鍵導入，能夠很方便的生成數據庫的大盤數據。

說完優勢，咱們直面它的缺點。主要是數據集羣多、配置管理低下、配置報警起來沒有界面，很是痛苦。

咱們會調研下一個監控方案，就是 Falcon，這也是一套國內比較優秀的監控系統。它有如下幾個優勢：首先組件都是分佈式的，沒有單點模塊，這符合咱們高可靠的要求，每一個穩定性都很高，由於它在設計的時候徹底考慮到了用戶的使用策略，因此全部的操做都是基於頁面完成，這點比較人性化，並且支持了很豐富的監控方式和方法。

可是基於基於咱們公司的原有監控，也有一些缺點。咱們考慮遷移的時候，原有的監控都須要廢棄，須要作兩種格式的兼容，成本很高，歷史數據也不能很方便的一鍵導入，這也是須要直面的兩個問題。

咱們怎麼作呢？咱們的選擇方案是 Prometheus 分佈式化，再加上 Falcon 高可用，但願可以打造一款既知足高可靠、兼容性好、配置比較簡單的一套系統來解決咱們監控的痛點，作到取長補短。

七牛雲內部監控系統介紹

首先說一下咱們監控系統在解決上面幾個問題的時候，最終作出的一些比較有特點的地方。第一是聯動服務樹，不少公司裏面都會擁有本身的監控平臺，其中服務樹是一個很核心的組件，聯動服務樹是剛纔提到的一個動態關聯的基石。第二個是分佈式 Prometheus，能夠進行數據存儲和告警功能。還有一點是咱們的監控是具備自動故障處理的特徵功能。還有一個是監控自動添加。除了咱們提供人工添加的途徑外，還能夠自動添加。

接下來具體介紹一下架構。

左側綠色是咱們內部的運維平臺，裏面的兩個小塊 Portal 和服務樹是兩個和監控有密切交互的組件。右側是整個監控系統，監控系統裏面核心是分佈式 Prometheus，底下是咱們的服務器集羣，這是咱們機房的業務機器，上面有一個 agent。具體它們之間工做的流程：咱們的分佈式 Prometheus 主要提供 API 層的一些策略管理、一些監控添加，還有一些數據的存儲、告警觸發。這邊是把咱們的操做進行界面化，以及 API 層面存儲的工做。服務樹是管理咱們整個運維體系中這些對象的一個工具，它和分佈式 Prometheus 之間會有一個同步的機制。Alarm 會負責告警處理、告警消息的處理，包括合併、分級、優先級調整等工做。還有咱們的告警自動處理模塊、數據聚合模塊，用來計算出咱們整個告警處理的效率和長尾統計分析的模塊。還有 agent，它是系統數據收集模塊。

接下來詳細介紹如下幾個主要的內容。

首先是服務樹。左側這一列能夠看出它是樹狀結構的東西，它是一組基於惟一 id 和 pid 生成的樹狀結構組織，能夠將運維的對象和樹節點關聯起來，包括平常的服務器、服務、初始化策略、監控策略、部署任務等等，能夠稱之爲它的運維對象。它和某一個節點關聯起來，就變成了某一個服務上面有哪些機器，以及它有哪些初始化策略、有哪些監控策略、有哪些部署任務，這些均可以和服務樹關聯起來。只要咱們維護好這個服務樹，就能夠管理好平常的監控、發佈、初始化等一切需求，包括服務署下面的服務器擴容、縮容，也能夠在這個服務樹上來管理，它是這樣一個組織關係。

Portal 這塊有不少功能，首先說一下監控性的功能，它是一套帶 UI 的配置功能，對於監控，配置的監控項是配置監控策略、配置自定義腳本、配置值班信息、查看告警信息和歷史數據。

咱們配置的一些條件，多是咱們上報上來的東西，裏面有一些 Tags，咱們設置它的一些值，匹配好以後，能夠對這個數據進行求和、求平均、求最大、求最小，基於此會生成一條查詢語句，這樣構成了一個監控策略，其實是一條模板化的查詢語句，而後在這邊修改。還有告警級別、告警間隔、最大告警次數等信息。

還有自定義插件，由於如今監控的需求比較多，不少需求很難經過監控系統自己來實現，因此咱們提供了插件的功能，只須要任意用腳本去寫，而後按照咱們的格式輸出，就能把你的格式收集上來，配置對應的監控項就能夠，它是綁定在某一個服務上面的腳本，針對這些服務作某些監控。

上圖有一些告警數據的告警截圖。咱們分不一樣的顏色展現不一樣的告警級別，多是一些微信的發送、以及對應的短信的分級通知機制。

最重要的一點是分佈式 Prometheus，由於 Prometheus 目前沒有開源的集羣化解決方案，咱們是和第三方的公司進行合做開發的，用它們對原生分佈式 Prometheus 進行改造，同時歸入咱們服務樹的一些核心的點，進行考慮合做開發一套適合公司使用的分佈式 Prometheus。對於原生 Prometheus 的原生改動，主要就是把它對存儲進行分離，而後把它的查詢層和告警計算進行拆分，進行了多級的高可用素質，存儲方面進行了存儲分片、查詢調動。其次是設計一些API，可以把 Prometheus的查詢語句進行模板化，監控策略配置的時候，把它升級爲一條條的存儲語句存儲起來，就是把原生 Prometheus 一萬多條的配置文件進行系統化、界面化的過程。

由於模板語句比較複雜，因此咱們提供了一個自動生成模板語句的功能，凡是用戶本身配置的自定義腳本，好比要生成監控的某一個東西，只要這個監控腳本提交了這個系統，系統會自動調用它，而後給它生成模板語句，不須要關心就能夠看到模板語句，有他要求的 Tags，有一些對應的約束值。

下面介紹咱們的 alarm，基於 Open-Falcon 的 alarm，首先改形成分佈式的，進行告警合併、告警優先級的策略，咱們一般會遇到某些機器異構的狀況，咱們對一批機器加一個優先級告警，可能有一些機器滿一兩塊都沒有關係，咱們對它進行一些特殊的策略設置。好比說告警的監控加在這塊和子節點上，咱們但願看到 95% 的告警進行告警，告警發生過來的時候，會有一些優先級策略的判斷，會對它進行默認的屏蔽，不會通知到用戶。

這個告警接入公司統一的信息通告平臺，它支持咱們幾種用戶的通知方式，重要的告警直接打電話，不重要的分別有短信、微信這些方式去通知。

還有一個是 task，它是一個同步的模塊。主要涉及到服務樹上面關聯的信息，經過異步的方式通知給服務器那邊。就是咱們服務上有哪些機器、端口是什麼、進程名是什麼、機器是否發生了變更、它的值班人員是什麼，都會異步去通知給 Prometheus 那邊，Prometheus 那邊知道我這個服務上面加了哪些監控，而後從用戶配置的監控策略去查詢到這些數據以後去匹配這些閾值，接到告警以後，推送給值班人員，是這樣一個過程，這是 task 模塊起到數據同步的過程。

Auto-recovery 是咱們作的監控自愈的模塊。咱們要針對某一個監控設定必定的處理機制，若是它知足某些條件，咱們就對它進行自動處理。自動處理的東西是人工處理好，主要的工做流程是：在告警那邊收到消息，但這個告警消息是分告警策略的，這個信息屬於哪條策略，而後這個策略會對應一些規則，匹配到這些規則再去看，規定了這些告警在什麼狀況下知足我定義的條件，多長時間執行了多少次，而後進行 action。由於在每臺機器上都會有服務器，咱們有執行器，而後執行到對應的服務器，執行完以後，會把對應的結果推到微信羣，歷史記錄和日誌之類的能夠去查看，這是監控自愈的狀況。

這是監控自動聚合統計的內容，告警發生了認領的過程，體現了故障處理的效率；還有一個是從認領到故障恢復，故障處理用了多長時間，它來體現咱們的值班效率；還有一些告警，可能它發生的頻次會比較多，咱們去經過一些大數據計算的方法，而後提煉出在零散的告警裏面體現不出來的一些問題，最後經過這個中心去把它發掘出來，並進行一個個的處理和追蹤。

而後再說一下咱們的 agent。咱們這個 agent 的特色是除了收集常見的幾百項監控指標以外，凡是綁定了端口的服務，這個服務進程所佔用的系統資源、進程級別的，都會收集到。還有一些協議級別的，好比說我這個機器上有經過一些網絡請求調動另一個協議，這個開關比較耗資源，在某些部門纔會用，打開以後它就會生成一些 Tags，而後在繪圖的過程當中能夠看到兩個服務之間消耗狀況的一些指標。

還有插件執行器，我要在這個機器上執行某腳本，只要是可執行文件就行，符合咱們監控系統的格式要求。

而後是 push-gateway，本地有一個 API，業務方但願把服務運行過程當中的一些指標實時上報監控進行報警繪圖，只要我有了 agent，就能夠往 API 上面 push 數據，程序上面直接調用，就能夠把數據推送到監控系統中來，進行對應的告警。

最後是探活，咱們 agent 的存活保證了全部數據的可用性，可能咱們 agent 已經掛掉了，若是沒有收到告警就以爲一切都正常，能夠探活每一個 agent 的數據上報，若是有一段時間內沒有收到 agent 的探活上報，說明全部的告警已經失效了，這是做爲內部監控的數據。

以上就是咱們內部監控的總體介紹。總結一下，目前這套系統首先已經代替了 32 套單機的 Prometheus 監控，全部的操做都在界面上進行完成，全部的監控都是具備必定的自動處理機制。在咱們發佈的時候，也會去自動添加這個服務相關的服務器基礎建構和服務的進程端口、重要接口的一些監控。

監控的展望

第一個是說咱們也比較想作好，由於如今的系統微服務比較多，相互調用的鏈比較複雜且比較長，如今在單機的告警狀況下，客戶報一個故障上來以後，咱們很難快速的定位究竟是哪一個環節、甚至哪一個函數出現了問題，而是須要人肉篩選在整個鏈路中到底哪一個環節出了問題。這是咱們下一步跟蹤的方向。

第二個是基於大數據的智能化監控。如今你們都提 AIOps，我以爲 AI 要落地的話，首先要把基礎的數據收集基本功作好，在這個基礎上，積累一些現有的歷史數據，分析一些趨勢，作一些自動化的調度和自動化的處理，實現無人值守的目標。

以上是個人所有演講內容，謝謝你們！