作者：宜信大資料創新中心LAIN團隊

在系統的開發及運維中，監控報警始終是非常重要的環節。監控報警系統能夠幫助開發運維人員及時理解系統的狀況，便於出現問題時及時定位，同時可以根據整個監控指標的趨勢圖規劃後續的開發運維計劃。本文希望通過介紹宜信大資料創新中心的監控報警系統，給大家快速搭建一套監控報警系統提供一些參考。

基本架構

在宜信大資料創新中心，我們使用了自研開源的基於 Docker 的 PaaS 平臺 LAIN 幫助業務快速開發迭代。為了使得整個平臺更加穩定，我們也基於一些開源元件構建了一套方便可用的監控報警系統。

通常一套監控報警系統會包括這麼幾個模組：

1. 指標資料收集
2. 指標資料儲存
3. 指標資料展示
4. 監控報警

我們在進行技術選型時主要考慮的是希望各元件專注做一件事情並把它做好。基於這點，我們選擇了 collectd 進行資料收集，Graphite 進行資料儲存， Grafana 進行資料展示，icinga2 進行監控報警。基本的架構如圖所示：

下面我們通過一個例子介紹下各個元件的基本情況：假設我們需要監控某臺伺服器上8080埠的連線數，並對其設定報警閾值。

資料收集

監控報警系統最基礎的一環就是如何對監控指標的相關資料進行收集。我們選用collectd 進行收集。 collectd 的優勢包括：

1. 使用 C 編寫，效能以及可移植行都非常棒；
2. 外掛豐富，支援超過一百種以上外掛，各種常見的指標如機器 load、disk usage 等等都能夠非常輕鬆的通過配置相應外掛進行收集；
3. 拓展性好，可以通過自定義外掛的形式進行一些其他資料收集，比如我們自己也寫了一些外掛來監控 LAIN 中執行容器的基本狀態；

那如果我們想通過 collectd 收集機器 8080 埠的連線數，並將相應資料傳送給Graphite。在安裝好 collectd 之後只需要在 /etc/collectd.conf 配置檔案中加入下列語句即可：

整個配置檔案比較好理解，首先聲明瞭機器的主機名，載入 tcpconns 以及 write_graphite 兩個外掛。

tcpconns配置成了會收集本機的 8080 埠的相關連線資訊，如果申明其中的 ListeningPorts 變數為 true 意味著外掛會收集本機上所有被 socket 監聽的埠，設定為 false 則只會收集指定的埠。

write_graphite配置成使用 tcp 協議將訊息傳送給 localhost 的 2003 Port，此處 Host 和 Port 指的就是 Graphite 的資料收集模組 carbon-cache 所在的機器的 Hostname 或者 IP 地址以及相應監聽的埠。

配置檔案中具體配置項的含義以及支援的外掛的配置項都可以在 collectd.conf 的 Manpage 中看到。

資料儲存

Graphite是一個很受歡迎的指標收集平臺。其主要元件包括：

• carbon: 監控資料接收元件
• whisper: 監控資料儲存元件
• Graphite     Web: 監控資料查詢及展示元件

Carbon

Carbon主要包括三個元件：carbon-cache、carbon-relay 以及 carbon-aggregator。

carbon-cache主要負責接收指標資料，然後定期將接收到的資料寫入到磁碟中。同時它還停供了查詢介面，可以直接查詢位於記憶體中的還未被寫入磁碟的相關熱點資料。

給 carbon-cache 傳送資料非常簡單，如果不用 collectd 的 write_graphite plugin 進行傳送，也完全可以通過非常簡單的命令給 carbon-cache 傳送資料：

echo "foo.bar 1 `date +%s`"| nc localhost 2003

其中主要包括三項：指標名、指標相關資料以及時間戳。

對於一個數據量不大的監控系統來說，其實一個簡單的 carbon-cache 例項就已經足夠了。但是隨著監控指標的增多，僅僅靠一個 carbon-cache 可能會導致 I/O 出現瓶頸。這個時候就需要考慮carbon-relay，可以通過定製相應的規則將服務按一定的規則（比如一致性雜湊）傳送給後端的多個 carbon-cache。

carbon-aggregator的作用其實與 statsd 相似，主要是起到一個數據歸集的作用。一方面可以減輕 carbon-cache 的壓力，一方面有些情況下需要進行統計工作，也可以通過 carbon-aggregator進行處理。

Whisper

carbon-cache的資料會從記憶體中落地到 whisper 中。whisper 是一種基於檔案的時間序列型資料庫，針對存入其中的每一個指標都會生成一個固定大小的基於時間序列的 .wsp 儲存檔案。固定大小的一個優勢是能夠根據需要收集的指標數粗略的估計出總共需要的磁碟空間。

對於大多數指標的監控而言，大家更加關心的是最近一段時間的詳細資料，而對於之前的監控資料，只需要能夠看到一個大致的趨勢就已經足夠了。使用者可以通過配置檔案規定存在於whisper 中的指標的資料精度，設定隨著時間的推移慢慢降低儲存精度。

比如我們可以在配置 carbon-cache 時，在配置檔案 storage-schemas.conf 中配置成如下形式：

[default]

pattern = .*

retentions = 1m:7d,10m:30d,30m:1y

其中 pattern 匹配指標的名字，retentions 指定這個指標應該保留多久。此配置資訊則表示相應的符合條件的指標資料，1 分鐘精度的會保留 7 天，之後降為 10 分鐘精度，保留 30 天，再之後降為 30 分鐘精度，保留 1 年。

當然，除了 [default] 你也可以根據某些特定的指標設定合適的相應儲存方式。但是這些設定都是隻會對新建立的 wsp 檔案有效，已有的檔案的儲存策略需要通過 whisper-resize 進行更改。

Graphite-Web 與 Graphite-API

Graphite-Web主要是提供監控指標的對外查詢介面以及指標展示功能，但是因為相對來說比較臃腫，也可以選擇 Graphite-API 進行替代。

Graphite-API相對於 Graphite-Web 來說更加輕量級，不提供指標展示功能，只提供了相關的查詢介面。Graphite-API 的主要缺點是不能支援多個 carbon-cache 後端，但是對於資料量不大的監控還是足夠用了的。

配置 Graphite-API 也相當簡單，安裝好後只需配置/etc/graphite-api.yaml 檔案，指定whisper 所在的目錄以及 carbon-cache 所提供的查詢地址即可：

指標展示

Graphite-Web提供的展示功能並不是特別的方便，因此我們選用 Grafana 進行展示。大家可以在 http://play.grafana.org/ 這裡試玩下，體驗下 grafana 提供的展示能力。

Grafana主要擁有如下優勢：

1. Dashboard 配置方便，可以隨意通過拖拽方式進行變動，調換；配置好之後還能夠匯出模板分享給他人使用；
2. 支援多種後端，包括 Graphite, Elasticsearch, InfluxDB 等等，也可以通過編寫 plugin 支援一些特別的後端；
3. 支援認證，支援 LDAP、Basic Auth；

在 Grafana 中配置展示 Graphite 的資料非常簡單，我們只需在 DataSource 處選擇 Graphite，然後填好 Graphite-Web 或者 Graphite-API 所對應的 url 即可。

接下來通過一些簡單的網頁點選選擇即可展示出來相應的資料了，如圖：

Grafana在推出 4.0 的時候已經能夠配置報警了，對於一些簡單的監控報警其實也可以通過 Grafana 進行配置。

監控報警

在監控報警這方面，我們選擇的工具是 icinga，主要包括 icinga2 以及 icinga2web 兩個元件。

icinga2主要採用 C++ 編寫，旨在替代 Nagios 以及 icinga1，可以複用 Nagios 所有的外掛。它提供了非常方便的 API 供呼叫，同時拓展性、伸縮性以及效能方面也都非常的優秀。

icingaWeb2主要給 icinga2 提供了 UI，在其中我們能夠非常方便的檢視所有的監控項、報警接收人、監控的狀態等等，同時因為每次報警資訊都存入到了資料庫中，我們也能在 UI 上非常方便的去檢視所有的報警歷史。

我們開源了一個構建 icinga2 docker 映象的倉庫：github.com/laincloud/centos-lain-icinga2 其中加入了一些我們寫的拓展指令碼，包括從 graphite 中讀取資料，根據相應的閾值進行報警。我們也提供了一些常用的報警通知指令碼，包括 sms,mail, bearychat, slack 等等。

另一方面 icinga2 並沒有提供非常好的，配置報警的功能，所有的監控項需要通過配置檔案進行配置，當需要管理大量的監控項時則會顯得不那麼方便，LAIN 自研了一個元件 Hagrid 可以提供給開發人員自定義監控項，目前支援的監控項包括 Graphite 中收集的指標項，以及 TCP 連線的相關監控。使用者自定義好配置項後成功儲存後則會呼叫相應的 icinga2 API 生成 icinga2 相關配置檔案。

一些經驗總結

我們基於以上元件封裝成了兩個LAIN 應用：Hedwig 以及 Hagrid。分別提供了指標收集展示及監控報警功能，簡單搭建好 LAIN 系統後即可直接部署，歡迎大家試玩。

在整個監控系統的使用過程中，我們也積累了一些經驗，抽取幾點比較我們覺得比較有普遍性的也跟大家簡單介紹下：

1. collectd 中收集資料的時間間隔建議設定成與 whisper 的最大精度時間一致，比如都是60s。因為過於頻繁的資料收集可能會使得資料在 carbon-cache 的記憶體中產生堆積，從而大大增加記憶體佔用量。
2. 另外一個可能使得 carbon-cache 記憶體佔用量升高的原因是由於 carbon-cache 寫入 whisper 的速度過慢導致資料在     carbon-cache 中出現堆積。carbon-cache 有個配置引數 MAX_UPDATES_PER_SECOND 表示每秒更新多少指標，在實際過程中，需要根據指標數來確定該數值，數值較高雖然會減少記憶體佔用，但是磁碟 IO 會變的更高，同時這個值也會影響到新建立的監控指標落地的時間。
3. 在生產中，有可能某些服務或者機器廢棄後不會再往 carbon 中傳送指標資料，但是其所佔的 whisper 檔案大小並不會減少，長此以往還是一件挺佔磁碟空間的事情，因此建議可以定期對長期不更新的 whisper 檔案進行清除。
4. 對監控報警系統的監控也是一件非常重要的事情！

總結來說，我們通過一些非常優秀的開源元件以及自定義的配置構建了一套開箱即可用的監控報警系統，希望能給大家在構建自己的監控報警系統提供一定的參考。