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 監控報警任務
* 選擇時序數據
* 設置報警條件
* 設置報警信息
