I'm facing some issues with our PI and his alarm notification policies.
They never worked. We were one month ago in PI 3.1 and then, we configured our alarm notification policies but they were not effective. So we opened a TAC and we were advised to upgrade in 3.2.
So we went to the PI 3.2, and we couldn't configure the policies no more. The option Alarm Notification Policies was here, but was empty and we couldn't add any configuration. It was a known bug in the PI 3.2. So we wait for the PI 3.3.
We upgraded last week in PI 3.3. The configuration are now available. Now, we are receiving notifications. But not the one we want to.
We want to receive only the critical and major alarm. And for the "Port up or down", we want to receive the notification ONLY for the trunk ports between switch.
Find below how we configure the alarm policy :
We add a rule that suppress all the alarms for the user defined port groups "NO MONITOR". We defined the group as follow : "Every port that doesn't contain "MONITOR" in his description." We put in every port we want a monitoring the description MONITOR.
And it works, we don't see any alarm in the "alarm and events" page for these ports.
So now; here is how we configure our alarm notification policy :
- We choose the ROOT-DOMAIN for the notification policy
- We checked only the "Critical" and "Major" alarms.
- We choose all device groups
- We set our mail adresses in the destination
We are now receiving mail notification. We do not receive any "minor, warning or informational" alarm by mail, as wanted. So we know our notification policy is working. But we're receiving mail notifications for ALL the ports that are down. As if the notification policy was not matching our alarm policy.
And we can't choose a port group in the alarm notification policy. I read many subjects about this, and often, the solution was the one we are already using.
So, in brief : Although we configured our alarm policies to not receive any alarm for the ports we don't want to, we receive mail notification for all the ports when they are down. But these alarm we are notified of, they do not exist in the "alarms and event" page in PI. Because they are well supress by the alarm policy.
Do you know how we could manage to receive mail notification only for what we really want ?
Thank you for your help...
So just to confirm that you're looking at your ports that are alarming that are down both access and trunk ports.
We're having the same issue here, but I think I know what the issue is.
Check if the following command lines are on your interfaces you DO NOT want to monitor.
no snmp trap link-status
no logging event link-status
If you want everything else included in your syslog/traps being sent to prime under informational, these lines are critical as they will stop the switch from sending linkup/linkdown events to Prime or to the syslog where Prime processes it.
Prime monitors your switches in 3 ways.
SNMP polling (validates the switch interfaces are active with an active SNMP poll)
Trap Messages (Switch sends traps to Prime indicating that the interface is down)
Syslog Message (Switch sends a message to the log, which then forwards to Prime for analyzing)
If you eliminate the trap and logging options Prime will only poll the interfaces for status, but should not alarm as indicated by a syslog/trap message. I've noticed that once I stopped that, Prime didn't get the log message or the trap so it doesn't trigger the alarm notification for LINKUP/LINKDOWN alerts.
Try it on an interface you can bring up and down quickly and look at the Syslog page on Prime. If you don't see the LINKUP/LINKDOWN log message, then check your Alerts/Events page and see if Prime creates a notification.
Thank you for your answer.
I already thought about this solution, but it will not indeed solve my problem. Not in the way I want it.
Because, if I disable snmp trap and logging event, Prime will not be able to show me the interfaces' status on Device Management and I need to continue to see the status of the interface because Prime is our principal tool of monitoring. Maybe I'm wrong and it's not how Prime is checking the status of the interfaces. Don't hesitate to tell me if I'm mistaken.
Furthermore, I really hope that Prime is able to manage his alarm without cut the event at the source... It is one of his most useful feature, but as time goes by, I began to think that the alarm policies are just not functionnal.
Does anyone managed to bring this functionnality up ?
What I want to say: "Get Solar Winds and use prime for wireless heat maps." I'm having similar issues too. Haven't been happy with PI for a while. Every 3.x update breaks something else. I hope you find the fix and hope the solution is not upgrading to 3.4