隨著互聯網的發展，運維工作的復雜度成倍增加；與之關聯的，各種運維平臺的復雜程度也在成倍增加。
在此場景下，如何最大程度滿足穩定性工作需求，并保證我們的系統相對的干凈與解耦，是我們一直在追求和探討的。
監控系統的話題，很大。
本篇文章為筆者監控系列文章第一篇，僅介紹監控系統的采集環節。

前言

監控系統的話題很大，隨著業務的復雜，也會衍生出各種各樣不同的形態。但總體上繞不開三個部分：采集、存儲、報警。
本文跟大家談談第一部分：數據采集。

哪些數據需要采集

說到采集，首先我們應該了解，哪些數據需要被采集。
監控系統可能是為了滿足實時的數據查看、可能是用作歷史狀態回顧、或者用來做異常告警等。這些都需要收集到準確的數據。
而數據采集，其實就是為了收集足夠的數據，來滿足各種各樣的業務需求。

• 基礎數據
  基礎數據，觀察服務器狀態的基礎指標。
  包括CPU、內存、網絡、IO等等類別，這里就不一一列舉了。
  另外，類似core、OOM等信息，也可以考慮采集，算作基礎指標。
  

  open-falcon的一些基礎指標

• 應用數據
  應用數據，指的是在服務器上運行的應用的狀態數據。
  例如端口存活、進程存活、進程資源消耗等。
  這部分數據最大的用處可以對自己的服務添加存活告警，追溯進程資源的歷史占用情況。

• 業務數據
  以上兩類數據，都是我們需要關注的，但是在平時的穩定性工作中，我們會對硬件和業務都做出相應的冗余。因此，我們仍然需要一個確定的指標，來標示我們的業務運行狀態。
  這個指標，我們稱為業務指標。
  要判斷一個業務是否完全正常，不是說服務沒掛就沒問題了。變更造成的邏輯問題、錯誤數據造成的影響、數據量太大造成的響應超時都無法通過應用的存活狀態來發現。
  一般來講，用來判斷業務的狀態，我們習慣觀察三個黃金指標：流量、錯誤率、延遲。
  這三個指標，可以比較完善的從多個角度來判斷業務狀態。
  當然，根據業務情況的不同，也會有很多其他維度的指標，都算在業務指標的范疇之內。

數據模型

要講采集的方式，必須要從監控的數據模型講起。
監控的數據，其實是最純粹的時間序列數據。那么，在建設一個監控系統的時候，抽象出統一的數據模型，應該是設計和架構的第一步。

一般的時間序列數據包括四部分：

• 數據名稱（指標名 / metric）
• 標簽（標簽 / tags）
• 時間戳（timestamp）
• 值 （value）

open-falcon的數據模型

采集的方式

采集的方式根據我們的監控數據來源的不同而不同。主要分為默認采集、插件、探測、日志、埋點幾種。

• 默認采集
  默認采集一般是在默認的agent內做采集，比如cpu、內存、IO等機器的基礎指標，進程監控的相關指標，都算在此類。
  這類指標一般是在agent里預定義好的，指標量不會增長太多。

• 探測式采集
  顧名思義，外部探測式的采集都屬于這一類。
  比如端口監控、Ping監控、HTTP監控、網絡監控等等。

  探測式的采集，屬于外掛式的采集。這類采集比較輕量，對系統的侵入性較小，通過簡單的配置，可以快速的看到效果。
  除網絡監控本身之外，這類監控有一個顯著的特點，就是 嚴重依賴網絡，一旦網絡有抖動，極易發生誤報。因此可以采取多點探測的方式，這樣可以在一定程度上防止誤報的發生。

• 業務埋點
  沒有人，比業務的開發同學，更了解自己的系統，更知道什么情況下應該觀察哪些核心指標。
  因此對于業務采集做出標準化是非常必要的一件事情。筆者公司有一個原則： 堅持業務指標采集是代碼的一部分原則不動搖，提高指標覆蓋率 。業務的穩定性指標應該是開發的工作內容之一。模塊自身的可運維性應該是工程的開發標準之一。
  為此，運維需要給出穩定性的監控覆蓋標準：

  • 流量
  • 錯誤率
  • 延遲（99分位、95分位、90分位、avg）
    同時，可以使用tag對服務的調用雙方進行標記，如caller和callee。也可以由開發同學自定義加入一些標簽。

  所有運維標準的制定，沒有相應的工具和平臺支撐都是空談。因此監控系統同時應提供各種語言的業務埋點SDK，以及快速簡單收集數據的平臺。
  大部分開發團隊，都有自己的一套開發框架，如果能深入業務，也可以進一步考慮，將埋點SDK直接集成至業務線的統一開發框架中。

• 日志監控
  從穩定性角度來看，大部分情況下，日志監控與業務埋點獲取的是同樣的數據。
  只是日志監控更加靈活，當我們的服務是閉源的項目，或者短時間內無法快速對所使用開源的組件做出修改進行埋點的場景下，日志監控可以快速見效。
  一般來講，日志監控分為在線日志采集和離線日志采集。

  在線日志采集，一般來講會更靈活些，可以通過各種自定義的操作，對日志的時間、內容、量級都進行很好的篩選和計算，只需要少量的配置成本即可。但這種日志采集，侵入性較大，需要在機器上安裝agent，且實時對日志進行分析會占用CPU資源，極有可能影響線上服務穩定性，因此一定要做好資源限制。
  離線日志采集，是將日志統一收走，在中心處理計算。這種采集的優點在于不會占用太多的CPU資源，沒有日志量的瓶頸。但同時，也會占用大量的網絡資源。時效性上，跟實時分析相比，會有一些延遲；再就是大批量的日志集中處理，一定要對日志的格式進行規范，因此靈活性上可能會差一些。

• 插件采集
  基礎的指標有了，埋點、日志、探測也有了。其他的呢？
  用戶如果有自己的采集方式，但是需要將數據上報至監控系統，這種場景，可以用插件采集來實現。
  插件采集提供了一種，由監控系統控制采集周期，用戶只需要實現一個周期的采集邏輯即可完成數據收集的能力。
  插件采集更加靈活，可以提供用戶自定義的采集方式，比如說特定的收集命令，如jum等。插件只需要上報監控系統制定好的規范數據即可。
  插件采集，需要周期性的在機器上執行插件腳本，因此這個腳本的審計一定要把好關，無論是損害性動作還是資源消耗，都可能成為影響線上穩定性的隱患。

• 自定義指標上報
  除了上述的幾種采集方式之外，監控系統還應支持自定義上報的功能。
  用戶自定義的時間序列，都希望能統一使用監控系統進行數據可視化以及告警的功能。
  此時可以提供自定義數據上報的接口，無論是通過本機agent收集，還是有單獨的中央收集器都可以。
  有了自定義指標的上報，監控系統才真正成為一個穩定性基礎設施。
  open-falcon的采集agent，就提供了這樣的接口。
  不過，支持了自定義，但是用戶的上報行為卻無法很好的規范。生產環境經常出現誤上報數據或使用不規范的情況，將監控系統存儲打到瓶頸的問題。此部分我們會在《運維監控系統專題(二)：臟數據的治理》來進行討論。

數據的收集方式

一般的，有兩種收集方式：

• 中心端主動拉取（prometheus）
• 客戶端自動上報（others）

拉取式數據收集

中心端主動拉取，就是由一個中心端定時的向采集端按需拉取數據。這種模式的優點在于可以按需拉取，不會有浪費。但是在這個模型中，中心承擔了過大的壓力。理論上性能會有很大的瓶頸。

上報式數據收集

客戶端自動上報，就是所有數據一視同仁，全都上報。一般來講，會采用一個統一的proxy來收集，后邊會考慮做多級的組件，或者加一層MQ等，都是可以考量的設計。
整體來講，如果預估監控數據的量比較大。還是建議采用自采集然后集中上報的模式。

open-falcon的數據收集就是很好的客戶端自動上報模式。transfer可以無狀態伸縮、且支持級連。

后記

本篇文章為《運維監控系統專題》的第一篇，后續會持續更新，列表如下：

• 《淺談數據采集》
• 《監控臟數據的治理》
• 《淺談監控存儲的選型與建設》
• 《如何建設監控系統強大的繪圖功能》
• 《異常檢測能力的架構與實踐》
• 《報警風暴的治理》