Kapacitor行为测试

公司的Url监控需求之前是用zabbix的web scenarios来做的,优点是zabbix的触发器功能很好用,缺点是:

  • 和其他系统的结合有些不够方便灵活
  • item名称长度有限制,不能显示完整的url
  • 无法记录请求失败时的网页内容(只告诉你匹配失败了)

因此决定尝试使用telegraf,写一个Url监控插件 来做这个事情。因为是向influxdb提交数据,支持push任意tags和fields(指标),因此可以很方便的记录url,url归属的app,失败时的返回数据,甚至阈值匹配结果。

报警使用TickStack里的kapacitor,但是这个工具没有zabbix的trigger简单直观,理解起来有点费劲,设置不好会导致报警频繁。下面是我一开始约遇到的问题:

  1. 不用滑动窗口的情况下(window),报警很频繁
  2. 用滑动窗口,窗口里有一个监控点失败,立即报警,单要等窗口里全是正常point之后才会触发OK
  3. 如果使用.all(),可以改善第2条的问题,但是一旦有正常point进入窗口,立即触发OK状态(在zabbix里有Hysterisis功能,可以设置连续n次都成功才能从Problem转到OK)
  4. 使用influxqlnode,计算平均值,,会丢弃原始的fields

需要实现的报警效果:窗口中所有的point都异常,触发Problem状态,窗口中所有point都恢复,触发OK状态。

下面是我最近几天的测试结果(基于0.13.1版本和1.0-rc2版本)以及目前的解决方案。

测试数据

简单序列测试

tickscript:

测试数据

结果

结论:

  1. 每个点顺序匹配,状态频繁变更。

加windows测试

tickscript:

测试数据

结果

结论:

  1. 可以看到,如果有一个0进入win,那么就保持crit状态,并且duration直到这个0出了win之后才会变化
  2. win全部为1时才触发OK状态
  3. 故障时间为7s,从第一个0开始算起。实际故障时间可能认为只有 0 1 0 这个序列的3s。故实际故障时间可能是 7-win+1

all()测试

tickscript:

测试数据

结果

结论:

  1. 一个win里面全部数据都满足条件才能触发

测试数据2

结果

结论:

  1. 一个win里面全部数据都满足条件才能触发
  2. 报警之后如果有一个1进入win,那么立即离开crit状态
  3. duration为1s,少于实际故障时间。实际应为 1s + win - 1

influxql测试

tickscript:

结论:

  1. 原始fileds被丢弃,不能满足需求,放弃

kapacitor 1.0 reset表达式

github上提issue:#863,得到答复后尝试了 reset表达式(感觉跟flapping很像),然而还是要用influxqlnode,原始的Fields还是会消失。

joinNode

继续自己试验探索,最后通过joinNode,终于实现了既使用influxqlnode的计算node,又保留Fields的需求。

测试数据

结果可以看到,Fields没有少,而且duration也更准确了,完美

使用Fields作为变量

tickscript:

测试数据及脚本:

结果:

结论:

  1. 可以实现Fields之间的数值比较
  2. 可以用来自定义不同tags的阈值,例如监控流量异常,可以由用户定义流量增长几倍才算异常

参考资料




本文遵从CC版权协定,转载请以链接形式注明出处。
本文链接地址: http://www.annhe.net/article-3580.html

5 thoughts on “Kapacitor行为测试

  1. 需要注意kapacitor show 里显示的dot源码,可以生成图片看一下,对调试很有用。多个alertNode在一个stream下面时,有依赖关系 alert1->alert2->alert3...,即alert1触发,alert2才能触发,alert2不能单独触发

发表评论

电子邮件地址不会被公开。 必填项已用*标注