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 监控报警任务

* 选择时序数据

* 设置报警条件

* 设置报警信息