Since the Alerts and Notifications are mingled in the sense that you can’t be notified of an event unless it triggers an alert I’ll address both at the same time.
1. There needs to be a “!” (not) operator in at least the Define Alert -> Criteria -> Element Type field similiar to the Element Attribte Field.
This would make a twenty step process a one step process. Let me explain. We have hundreds of SM’s that we monitor. But, we don’t want to be alerted about RF threshold values outside of our normal tech support hours for those SM’s. On the other hand, every AP/BH/CMM we monitor we want to know immediately if there is an issue. The only way to set this situation up currently is to setup seperate alerts for each element type and then manually deactivate the SM alert every evening and reactivate it every afternoon. Most other monitoring/alerting platforms have this (nagios,opennms,cisco works, hp openview, among others for example).
2. Notifications have no concept of groups.
Users should be able to be placed into groups and then notifications sent to groups instead of individual email addresses. The current method requires dozens of changes anytime a single email address changes.
3. Notifications/Alerts/Groups(if there were any) have no concept of time.
Either Alerts, Notifications, or user groups should have a time concept where notifications are only of X severity or above are sent notifications or even no notifications are sent if configured as such. Again, see nagios. Some of this is partially available now by setting some alerts to differing severities and then configuring notifications accordingly but there is still no concept of time.
4. Alerts, and subsequently notifications have no way to both continue alerting, then be acknowledged.
The current alert paradigm enforces a concept that alerts will either require clearing or be manually cleared. If manually cleared, an alert and subsequently a notification is sent only once as the alert logic shows an existing alert with a status of new has been logged preventing further alerting. Once the alert is acknowledged, another notification is sent stating such and the same goes for when the status is changed from acknowledged to clear. Once the status is changed to cleared, further alerts will be generated if another new alert condition is seen. Although this method is fine for SM’s higher tier backbone equipment should be notified on any new alert (matching an already registered alert or not) until it is acknowledged. This method has a greater chance of garnering attention and still notifying someone in the event a failure in the communication chain stops that first alert.
On the other hand, if “automatically cleared” is selected, there is no way to stop prizm from notifying you that a problem existes, even if you acknowledge it. The automatically cleared action has the desired affect to continue alerting but once the issue is addressed and is known, the only way to stop notifications is to disable the alert or change it to “required clearing” so you may then acknowledge it. As a result, a known issue that might have a planned solution in the next two days will drive you completely insane with notifications even though you know full well about the issue.