Add possibility for alert & recover in syslog alerting

Hey Adam,

Circling back on that, is there a roadmap for that feature?

Indeed, second regex looks more appealing for now. Does Mike or yourself have a priority for that feature? It seems like a relatively quick change, yet resulting in a substantial improvement in Syslog alerting.

I think it would be trivial to send "recover" emails using a second regexp, but trying to keep track of state is probably asking for trouble, except in very simple cases, it seems far too easy for things to be unreliable/unpredictable.

Hi Adam and Mike,

I'm currently interested in that feature, and to me it looks like a user-defined Alert/Recovery option could work well for now.

I.e. given the following Syslog Rules as an example (in "Name" -> "Regex" mapping syntax):
     "Interface Down Rule" -> "/(Line protocol.+down)/"
     "Interface Up Rule" -> "/(Line protocol.+up)/"

Static mapping in the Web GUI will look like (in "Name" -> "Event Type" mapping syntax):
     "Interface Down Rule" -> "Alert"
     "Interface Up Rule" -> "Recovery"

What do you think on that? While that's a very manual approach to solve the problem, it would already be much better than not classifying at all.

Ahh, hmm. With there being multiple possible concurrent states related to a single syslog rule?

I mean 2 syslog regexp in single syslog rule..

I already have experiments with this

2 syslog rules (first is mandatory/alert), second is recovery, ie BGP neighbor:

/neighbor (?<entity>\S+) Down/i

/neighbor (?<entity>\S+) Up/i

and associated syslog entries:

001858: Jun 1 21:57:22.628: %BGP-5-ADJCHANGE: neighbor 80.93.51.14 Down BGP Notification sent

032701: Jun 1 21:58:35.358: %BGP-5-ADJCHANGE: neighbor 80.93.51.14 Up

in preg_match will compare $matches['entity'] (or $matches[1])..

I don't think this is really possible how you think, because how do we know which OSPF session has gone up and down?