《宜信大數據：如何快速搭建監控報警系統》要點：
本文介紹了宜信大數據：如何快速搭建監控報警系統，希望對您有用。如果有疑問，可以聯系我們。

作者：宜信大數據創新中心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. 對監控報警系統的監控也是一件非常重要的事情!

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4346.html