Email immediately on recept of syslog messages configured in alert

Help
1

I’m going to guess this is based on how process driven Libre seems to be.

I’m starting to consume syslog within Libre as I want more device specific events to be consumed. As such, I’m trying to leverage Libre to email configured alerts on these syslog events. However, I want to increase the interval in which Libre looks for said events and email out as near real time as possible. I’m going to guess this isn’t designed for that.

eg, I have a device that sends a syslog message on a down BGP peer. I don’t want to have to wait for up to five minutes for Libre to process the last five minutes of messages, determine whether something matches an alert rule, and then kick off an email with a collation of the last five minutes of said events. The alert timers would then take care of repeat alerts accordingly.

Is this something that’s possible? Normally snmp traps would be used, but I’ve not seen anything solid yet in handling traps (though I see recent work in getting something integrated…hopefully soon).

2

Most of us just use Graylog or E.L.K.

3

Thanks! We use ELK, though that has its own issues at the moment.

But to the task at hand, can this do it?

4

syslog is not snmp.

Your devices are continuously sending syslog to LibreNMS,
#https://docs.librenms.org/#Extensions/Syslog/

I checked on mine and the syslog message is instantly recieved, so by setting delay 0 in alerting it should be what you want?

5

The other thing you have to keep in mind is polling done in 5 min cycles. So you are gonna have a little delay.
Post your alert rule and we can help you out.

6

@Chas I know syslog isn’t SNMP. I wasn’t suggesting it was. Further it’s possible my testing methodology is flawed. I’m setting up some other test criteria.

@Kevin_Krumm the polling interval shouldn’t apply I’d think as syslog is being received constantly. As such, I’m keying on a specific syslog message for my rule, not a state change discovered from a poll. Our polling interval has been reduced to two minutes anyway to better improve some things, but I don’t like the event log.

Let me setup another test and should that have the same issue, I’ll fire up the rule in question.

Thanks!

7

Polling dose apply because that’s when the alert rules are being ran against the devices and syslog.

8

Ahh…ok. That more answers my question and what I was looking for. if it’s directly related to polling interval, then I’m limited in that regard.

At best, I’ll only ever get whatever my interval is.

I assume there’s no effort to better improve that? Again, it goes back to my OP in that work is being done to better integrate trap handling, which I would hope would separate some processes out and cause some immediate action upon receipt of a trap. But that’s neither here nor there.

Thanks!