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

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

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

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

在我認為，高效的系統應該包含以下幾個特性：高可靠、易擴充套件、自適應、開放性。

所有的能夠體現高可靠的幾點資訊，第一是整個系統沒有單點的模組，無單點的風險，這是我們日常做系統或者做運維、做系統設計的時候需要首先考慮的問題。第二是本身會提供一個豐富的自採集系統層面的監控項，包括系統核心、裝置、應用的一些資源消耗等資訊。第三是它所支援的監控種類比較豐富，因為我們現在的應用的型別也比較多，像常見的對應用監控的需求，比如日誌監控、埠監控、RPC 監控等等，這些能夠很方便的進行新增和管理。第三點是比較基礎的，高效、延時低，無論是資料採集、上報、計算處理、再到通知，以及到使用者收到這個通知，整個效率是比較高的，這也是和高效能夠對應起來的。最後是易於 debug，如果開發人員說監控沒有報警或者誤報警，如何 debug 這個資訊，快速修復問題。這是我對高可靠的一些認識。

它其實是我們系統的開發過程中，對於運維側以及部署和擴容方面的考慮，這個系統很容易擴容和部署，它的依賴比較小。其次，它能夠達到快速部署的基礎是它的資料儲存是要叢集化管理，而不是資料和單機繫結，它的服務邏輯層需要去可水平擴充套件，隨著業務對監控的需求不斷增加，監控的壓力變大的時候，能夠快速地進行服務層面的水平擴充套件。

我認為這點比較重要。我們很多傳統的監控系統都是比較機械一點，為什麼說機械？就是說它監控的新增、修改之類的，都是需要我們人工手動的做一些很多冗餘的操作，而不能隨著伺服器服務，我們監控物件的生命週期的運轉，比如說伺服器上線、下線、運維、維修、新新增的服務或者服務下線，能夠進行動態關聯，監控也隨著這些物件的生命週期進行變化。還有是人員流轉，我們經常會遇到公司內部的員工入職、轉崗、離職等方面，還會隨著他的崗位狀態運轉能夠自動匹配，是否對它進行報警傳送以及刪除。

首先是要對外提供 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，它是系統資料收集模組。

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

Portal 這塊有很多功能，首先說一下監控性的功能，它是一套帶 UI 的配置功能，對於監控，配置的監控項是配置監控策略、配置自定義指令碼、配置值班資訊、檢視告警資訊和歷史資料。

我們配置的一些條件，可能是我們上報上來的東西，裡面有一些 Tags，我們設定它的一些值，匹配好之後，可以對這個資料進行求和、求平均、求最大、求最小，基於此會生成一條查詢語句，這樣構成了一個監控策略，實際上是一條模板化的查詢語句，然後在這邊修改。還有告警級別、告警間隔、最大告警次數等資訊。

還有自定義外掛，因為現在監控的需求比較多，很多需求很難透過監控系統本身來實現，所以我們提供了外掛的功能，只需要任意用指令碼去寫，然後按照我們的格式輸出，就能把你的格式收集上來，配置對應的監控項就可以，它是繫結在某一個服務上面的指令碼，針對這些服務做某些監控。

上圖有一些告警資料的告警截圖。我們分不同的顏色展示不同的告警級別，可能是一些微信的傳送、以及對應的簡訊的分級通知機制。

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

因為模板語句比較複雜，所以我們提供了一個自動生成模板語句的功能，凡是使用者自己配置的自定義指令碼，比如要生成監控的某一個東西，只要這個監控指令碼提交了這個系統，系統會自動呼叫它，然後給它生成模板語句，不需要關心就可以看到模板語句，有他要求的 Tags，有一些對應的約束值。

這個告警接入公司統一的資訊通告平臺，它支援我們幾種使用者的通知方式，重要的告警直接打電話，不重要的分別有簡訊、微信這些方式去通知。 

Auto-recovery 是我們做的監控自愈的模組。我們要針對某一個監控設定一定的處理機制，如果它滿足某些條件，我們就對它進行自動處理。自動處理的東西是人工處理好，主要的工作流程是：在告警那邊收到訊息，但這個告警訊息是分告警策略的，這個資訊屬於哪條策略，然後這個策略會對應一些規則，匹配到這些規則再去看，規定了這些告警在什麼情況下滿足我定義的條件，多長時間執行了多少次，然後進行 action。因為在每臺機器上都會有伺服器，我們有執行器，然後執行到對應的伺服器，執行完之後，會把對應的結果推到微信群，歷史記錄和日誌之類的可以去檢視，這是監控自愈的情況。

然後再說一下我們的 agent。我們這個 agent 的特點是除了收集常見的幾百項監控指標之外，凡是繫結了埠的服務，這個服務程式所佔用的系統資源、程式級別的，都會收集到。還有一些協議級別的，比如說我這個機器上有透過一些網路請求調動另外一個協議，這個開關比較耗資源，在某些部門才會用，開啟之後它就會生成一些 Tags，然後在繪圖的過程中可以看到兩個服務之間消耗情況的一些指標。

還有外掛執行器，我要在這個機器上執行某指令碼，只要是可執行檔案就行，符合我們監控系統的格式要求。

然後是 push-gateway，本地有一個 API，業務方希望把服務執行過程中的一些指標實時上報監控進行報警繪圖，只要我有了 agent，就可以往 API 上面 push 資料，程式上面直接呼叫，就可以把資料推送到監控系統中來，進行對應的告警。

最後是探活，我們 agent 的存活保證了所有資料的可用性，可能我們 agent 已經掛掉了，如果沒有收到告警就覺得一切都正常，可以探活每個 agent 的資料上報，如果有一段時間內沒有收到 agent 的探活上報，說明所有的告警已經失效了，這是作為內部監控的資料。

以上就是我們內部監控的整體介紹。總結一下，目前這套系統首先已經代替了 32 套單機的 Prometheus 監控，所有的操作都在介面上進行完成，所有的監控都是具有一定的自動處理機制。在我們釋出的時候，也會去自動新增這個服務相關的伺服器基礎建構和服務的程式埠、重要介面的一些監控。

監控的展望

第一個是說我們也比較想做好，因為現在的系統微服務比較多，相互呼叫的鏈比較複雜且比較長，現在在單機的告警情況下，客戶報一個故障上來之後，我們很難快速的定位到底是哪個環節、甚至哪個函式出現了問題，而是需要人肉篩選在整個鏈路中到底哪個環節出了問題。這是我們下一步跟蹤的方向。

第二個是基於大資料的智慧化監控。現在大家都提 AIOps，我覺得 AI 要落地的話，首先要把基礎的資料收集基本功做好，在這個基礎上，積累一些現有的歷史資料，分析一些趨勢，做一些自動化的排程和自動化的處理，實現無人值守的目標。

以上是我的全部演講內容，謝謝大家！