[經驗交流] 試用基於 influxdb+kapacitor 的監控系統

2017年10月16日：

使用中發現kapacitor的ui過於簡單，不能知足實際工做須要，現已切換到grafana

 

---------

兩個月前試用了基於 elasticsearch + xpack (watch) 的監控系統，發現了一個問題：elasticsearch 做爲時序數據庫使用時性能較差，在我目前的硬件配置下（es 主機內存 8G），使用 grafana 展現兩個月以上的數據時，在讀取數據的過程當中出現明顯卡頓，es 的資源佔用率幾乎到100%。所以，我又試用了 基於 influxdb+kapacitor 的監控系統。

 

1. 數據搜索性能

初步印象：搜索大量時序數據時 influxdb 的性能強於 es。多是 es和 influxdb的定位原本就不一樣，一個是全文搜索引擎，一個是時序數據庫，術有專攻。 

 

2. 資源佔用率

influxdb 資源佔用率顯著低於 es，可能與它用 go 語言編寫有關

 

3. 報警功能

influx 的 kapacitor 功能與 es 的 watch (在 x-pack 包中) 相似，均可以用做報警，influx 還提供了 ui 系統 chronograf 來管理 kapacitor，藉助 chronograf 能夠無障礙的編寫報警監控任務。這一點比 es 的 watch 方便多了。

 

kapacitor 支持 http post 方式發送報警信息，數據是 json 格式，其中 "message" 鍵的值能夠自定義。爲了能經過 http post  發送 短信報警，我另外編寫了一個 restful 的短信發送服務器，能夠接收包含 "message" 鍵值的 json 數據，（ "message" 的值包含手機號碼和短信內容，用 | 隔開），併發送短信：

{「message」:"138000000,156000000 | 短信報警內容"}

 

附1：kapacitor http post 發送的數據內容

{
"id":"...",
"message":"值能夠在chronograf ui上自定義",
"details":"...",
"time":"...",
"duration":..,
"level":"...",
"data":...
}

 

附2：經過 chronograf 建立 kapacitor 監控報警任務

* 選擇時序數據

 

 

* 設置報警條件

 

* 設置報警信息