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 要落地的話，首先要把基礎的數據收集基本功做好，在這個基礎上，積累一些現有的歷史數據，分析一些趨勢，做一些自動化的調度和自動化的處理，實現無人值守的目標。
以上是我的全部演講內容，謝謝大家！