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

前言

監(jiān)控系統(tǒng)的話題很大，隨著業(yè)務(wù)的復(fù)雜，也會衍生出各種各樣不同的形態(tài)。但總體上繞不開三個部分：采集、存儲、報警。
本文跟大家談?wù)劦谝徊糠郑?strong>數(shù)據(jù)采集。

哪些數(shù)據(jù)需要采集

說到采集，首先我們應(yīng)該了解，哪些數(shù)據(jù)需要被采集。
監(jiān)控系統(tǒng)可能是為了滿足實時的數(shù)據(jù)查看、可能是用作歷史狀態(tài)回顧、或者用來做異常告警等。這些都需要收集到準(zhǔn)確的數(shù)據(jù)。
而數(shù)據(jù)采集，其實就是為了收集足夠的數(shù)據(jù)，來滿足各種各樣的業(yè)務(wù)需求。

• 基礎(chǔ)數(shù)據(jù)
  基礎(chǔ)數(shù)據(jù)，觀察服務(wù)器狀態(tài)的基礎(chǔ)指標(biāo)。
  包括CPU、內(nèi)存、網(wǎng)絡(luò)、IO等等類別，這里就不一一列舉了。
  另外，類似core、OOM等信息，也可以考慮采集，算作基礎(chǔ)指標(biāo)。
  

  open-falcon的一些基礎(chǔ)指標(biāo)

• 應(yīng)用數(shù)據(jù)
  應(yīng)用數(shù)據(jù)，指的是在服務(wù)器上運行的應(yīng)用的狀態(tài)數(shù)據(jù)。
  例如端口存活、進程存活、進程資源消耗等。
  這部分?jǐn)?shù)據(jù)最大的用處可以對自己的服務(wù)添加存活告警，追溯進程資源的歷史占用情況。

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

數(shù)據(jù)模型

要講采集的方式，必須要從監(jiān)控的數(shù)據(jù)模型講起。
監(jiān)控的數(shù)據(jù)，其實是最純粹的時間序列數(shù)據(jù)。那么，在建設(shè)一個監(jiān)控系統(tǒng)的時候，抽象出統(tǒng)一的數(shù)據(jù)模型，應(yīng)該是設(shè)計和架構(gòu)的第一步。

一般的時間序列數(shù)據(jù)包括四部分：

• 數(shù)據(jù)名稱（指標(biāo)名 / metric）
• 標(biāo)簽（標(biāo)簽 / tags）
• 時間戳（timestamp）
• 值 （value）

open-falcon的數(shù)據(jù)模型

采集的方式

采集的方式根據(jù)我們的監(jiān)控數(shù)據(jù)來源的不同而不同。主要分為默認(rèn)采集、插件、探測、日志、埋點幾種。

• 默認(rèn)采集
  默認(rèn)采集一般是在默認(rèn)的agent內(nèi)做采集，比如cpu、內(nèi)存、IO等機器的基礎(chǔ)指標(biāo)，進程監(jiān)控的相關(guān)指標(biāo)，都算在此類。
  這類指標(biāo)一般是在agent里預(yù)定義好的，指標(biāo)量不會增長太多。

• 探測式采集
  顧名思義，外部探測式的采集都屬于這一類。
  比如端口監(jiān)控、Ping監(jiān)控、HTTP監(jiān)控、網(wǎng)絡(luò)監(jiān)控等等。

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

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

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

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

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

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

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

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

數(shù)據(jù)的收集方式

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

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

拉取式數(shù)據(jù)收集

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

上報式數(shù)據(jù)收集

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

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

后記

本篇文章為《運維監(jiān)控系統(tǒng)專題》的第一篇，后續(xù)會持續(xù)更新，列表如下：

• 《淺談數(shù)據(jù)采集》
• 《監(jiān)控臟數(shù)據(jù)的治理》
• 《淺談監(jiān)控存儲的選型與建設(shè)》
• 《如何建設(shè)監(jiān)控系統(tǒng)強大的繪圖功能》
• 《異常檢測能力的架構(gòu)與實踐》
• 《報警風(fēng)暴的治理》