公司的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的阈值，例如监控流量异常，可以由用户定义流量增长几倍才算异常

参考资料

---