Only send notification when a NEW BGP sessions goes down or up

I am using the default Alert Template for sending notification when one or multiple BGP sessions go down.
Now, when a new BGP session goes down, I get a notification e-mail titled ‘BGP session down - got worse’. When a BGP session goes up, I get a notification e-mail titled ‘BGP session down - got better’.
While this is very confusing, the biggest problem I have it is hard to distinguish what is the latest session that went down or up after the previous alert.
Would I need to code this myself or is there an easier way already built in LibreNMS?

So the real question would be: “How would I have LibreNMS only sent a notification when, after a new poll, one or multiple BGP sessions went up or down?”.
Sessions that have been down for a while are also sent in the notification mail, which pollutes the entire message because I have to distinguish them now.

Basically, this is not possible in the current LibreNMS implementation. You would have to shut a bgp session that is down (and explected to be down). This is usually a good practice anyway, but this is in fact mandatory if you want to have a “clean” alert window in LibreNMS.

I would have thought this would be the case :frowning:

We are all open to contributions in order to change that. But as this is a structural design of the alert template to avoid duplication, this would be a lot of work (and probably not appropriate) to change this.

Again, I would suggest to look at this on another angle : It is never a good idea to keep an alert in the Alert tab forever. If a BGP peer is down, then I would rather shut it properly, so the alert goes.
You can also make 2 different alerts (one for your transits, usually a low amount) and one for your peers (in IX, usually a lot, but usually not a problem to loose one or 2). That would give you the critical alerts (when a transit is down, which should never happen) and peers can be only warnings, which will get worse or better, but will at least be separated from the critical ones).

Thanks for your clear answer @PipoCanaja !
I’m already looking at SNMP traps, which might be a more specific type of monitoring that we can use.