1. 根据不同时间段的不同情况报警
({asterisk-71:dd_KC.calls.max(2m)} <10 and {asterisk-71:dd_KC.calls.time(0)}>060000 and {asterisk-71:dd_KC.calls.time(0)} < 240000)
or ({asterisk-71:dd_KC.calls.max(5m)} < 2 and {asterisk-71:dd_KC.calls.time(0)}> 000000 and {asterisk-71:dd_KC.calls.time(0)} < 060000)
表达式说明：
- 前半段表示6:00-24:00之间，每2分钟内取到的最大值小于10则报警。
- 后半段表示0:00-6:00之间，每5分钟内取到的最大值小于2则报警。
2. 匹配日志关键字报警与恢复机制
{asterisk90-voip:log[/var/log/asterisk/messages,"many open"].regexp("many open files")}=1 and {asterisk90-voip:log[/var/log/asterisk/messages,"many open"].nodata(300)}=0
表达式说明：
- log[/var/log/asterisk/messages,"many open"]表示先过滤出匹配"many open"的行，再交由下一个regexp函数处理，这样的好处是只处理我们关注的数据。我将key[logpath,regexp]和key[logpath]两者作比较发现最明显的差别可能就是当日志故障恢复后的报警信息不同。
key[logpath,regexp]
当前状态：OK：asterisk90-voip Too many open files：elisun3 many open files
key[logpath]
当前状态：OK：asterisk90-voip Too many open files：[May 3 13:18:13] CYNA[27890][C-00003a0b] channel.c: CYNA begin ‘1‘ received on SIP/siptrunkofold-01022411
- 如果只是前半段条件的话，那么这个报警好像没有了恢复正常的状态，一直处于异常状态，因为正则过滤到的最后的值一直都是包含关键字段的，所以加了时间条件来打破这个尴尬。整体描述为当出现“many open files”字段时并且是最近300秒内产生的数据则异常报警。反之恢复报警描述为最近300秒内没有“many open files”字段出现则恢复正常状态。
?