原有系統及問題

我們原有的監控體系出于穩定和可靠性考慮，采用 mysql 存儲，再加 python 開發分析與報警邏輯。好處是技術成熟，靈活可控，少坑。隨著業務發展，這套方案逐漸難以應付更加復雜、多樣化的監控需求。
監控數據往往都帶有時間戳，其實就是一種典型時間序列數據，而這方面已經有很多專門的存儲系統，如 opentsdb，influxdb。相比 mysql 這樣的傳統數據庫，這類系統在存儲、查詢上針對時間序列數據都做了特別的優化。當然對于需要復雜查詢的報表類數據，mysql 也有它的優勢。為了支持豐富的監控指標，我們希望找到更加合理的存儲方案。
此外，監控系統存在失效問題，而且在保持監控系統足夠簡單的前提下，很難同時保證低誤報（假陽性）與不漏報（假陰性）告警。結合業務特點，比較穩妥的方式是人工與自動化監控相結合。告警與展示數據同源，所有的告警指標都能在監控頁面上反映出來，這樣一方面人工能做交叉驗證，另外一方面收到告警信息之后也能方便地查看相關數據。

需求

在系統選型前，有必要先梳理我們的需求：

• 業務指標類數據，需要表格展示，一般只關心最新狀態
• 時間序列數據，按時間軸展開分析，如各種系統延時
• 開源，易擴展，方便二次開發
• 能夠直觀展示告警數據

技術框架選型

主流方案比較

Graphite

前幾年開始流行的監控架構，由于其架構的開放性，軟件生態相當豐富，每個主功能都能找到不同的替代品，其數據協議甚至已成為事實上的監控數據協議標準。但由于其低效的存儲格式（見下文存儲部分）及簡陋的展示頁面，給我們帶來的潛在工作量可能更大。

TICK

TICK 是 influxdata 公司搞的一套開源監控軟件棧 Telegraf, InfluxDB, Chronograf, Kapacitor 的縮寫，分別與 Graphite 架構中的數據采集、存儲、展示和告警模塊對應，且與主流 Graphite 生態兼容。TICK 的核心在于 InfluxDB，一個高效且功能豐富的時間序列數據庫；而 Chronnograf 與 Kapacitor 則相對沒有那么驚艷；如果不考慮對 InfluxDB 的原生支持，Telegraf 也沒有太突出的特點。

Prometheus

一套開箱即用型系統，但生態鏈并不如 Graphite 系完備，在存儲、展示、二次開發等各方面也沒有明顯優勢。

ELK

ELK 是Elasticsearch, LogStash, Kiban 這一套日志分析軟件棧的縮寫。可對任意數據字段索引，適合多維度的數據查詢，因此在存儲時間序列數據方面與 InfluxDB 相比會有額外的性能和存儲開銷。強大的功能都是有代價的，我們暫時無此類需求。

open-falcon

小米的開源監控系統，使用者較少，且采用微服務架構，理解及部署都略顯復雜，不過文檔中提到的一些運維經驗還是值得借鑒的。

分模塊選型

為了避免綁死在一條船上，我們希望監控系統能采用開放性的架構，各個部件可以根據業務需要、開源社區發展程度進行調整。一般來說監控系統都有如下五個功能模塊，我們將分別討論。

• 收集
• 存儲
• 展示
• 告警
• 分析

存儲

首先最核心的是存儲模塊，數據的存儲基本決定了展示和分析的形態。根據之前的運維經驗，mysql 不是很適合大量的時間序列類數據的頻繁寫入存儲，所以為了監控系統的方方面面，存儲必須足夠高效。其次，由于我們人手有限，不可能在一開始就大量投入開發時間，所以要求存儲系統簡單易用，且表達能力足夠滿足基本查詢、分析需要。
influxdb 采用簡潔而高效的 TSM 文件結構，查詢語言基本與 sql 一致，而且用 go 語言實現的程序效率和易用性都挺有保障：）
<a name="graphite-cons"></a>另外一個選擇是 graphite，但由于其存儲格式是固定時間間隔都要占坑，對于稀疏數據非常浪費空間；且每個 metric 都對應于一個獨立的文件，同時寫入多個 metric 會產生很多零碎的文件 IO 操作，已經有不少關于這方面性能問題的吐槽。
所以我們最后選擇了 influxdb 作為存儲系統。

采集

采集這方面已經有很多成熟的項目，如 collectd/stats/diamond，大同小異。然而，telegraf 是 influxdata 的親兒子，它支持 influxdb 特有的 key 與 field 格式。毫無懸念的，既然上了 influxdb 的船，那就用 telegraf 唄。當然對于業務系統數據，可能會考慮直接往 influxdb 發送數據；telegraf 只負責采集系統級別的監控數據。

展示

TICK 架構里的 Chronogra 作為展示模塊，功能過于簡單，無法滿足需求。而另外一個成熟的 Grafana 項目，從 Graphite 時代就發展起來，擁有豐富的展示功能，強大而方便的可配置界面和插件系統，且可以批量創建管理展示配置，最關鍵的是與 influxdb 適配也非常成熟穩定（influxdata 的支持），讓我們別無選擇。

告警

監控系統的成敗就在于能否恰當地告警了。Grafana 自帶報警功能，報警內容能在圖標上直觀地展示，這樣出報警時可以方便查看報警情況，同時也方便運營同學平時有事沒事 double check，避免因報警渠道阻塞而造成故障不能及時處理。不過 Grafana 的報警功能比較簡單，只支持簡單的閾值檢查，所以這里還需要我們實現一些輔助分析，把復雜的報警需求轉化成可以做簡單閾值檢查的指標書數據。
雖然 TICK 架構包含了 Kapacitor 這一告警子系統，但它并不能直接支持展示，且使用的是自己的 dsl，雖然足夠強大但表達能力畢竟還是受限，學習成本過高卻沒有解決我們的問題。

分析

暫無復雜需求，沿用現有系統。

最終架構

Telegraf + Influxdb + Grafana + 二次開發，如圖所示。

+--------+    +--------+   +-------+
|Telegraf+-+-->Influxdb+--->Grafana|
+--------+ |  +-+---+--+   +---+---+
           |    |   ^  |       v
+--------+ |    |   |  |   +---+---+
|Services+-+    +---+  +-->+ Alarm |
+--------+     Analyze     +-------+

監控內容

• 基礎設施：硬件及操作系統
• 基礎軟件
  • 服務存活：如 consul / airflow
  • 服務健康度：如 apahce / mysql
• 業務系統
  • 服務存活及資源使用情況
  • 業務指標

坑（持續補充中）

influxdb

• 查詢/插入語法中引號的用法非常魔性，一定要充分測試