This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Akil, I'd like to schedule a time where we can meet via WebEx/Zoom/etc., to review this use case so that I can better understand the request. I'll work with your CSM, Scott Giles, to set that up if you're interested.
Hi Ryan, I believe its not help in this situation as the there are no fixed count for this device up down ( as an example) . In any threshold condition it will trigger alarm when the condition met and will send without any delay to netcool or SNOW. So I am looking forward in that direction to avoid this ticketing count. If any alarm triggered and wait for 5 minutes delay to send it over to netcool. Hence Netcool will get only genuine alarms.
Hi Akhil, this sounds similar in behavior to a flapping interface. In this case it sounds like the device isn't responding through. But it was only down for a few minutes and came back online. You don't want to trigger the alert unless the device has been down for a longer duration, right?
If so, we have new threshold aggregation types called count over threshold and time over threshold to help reduce noise in situations like this. Have you tried to see if this addresses the problem?
Hi Ryan, this is threshold based alerts . as an example we kept the device is not responding to 2 polls trigger alert soon as it triggered it will send to netcool ( no delay option) as a trap , might be on 3rd poll cycle device will be reachable and it will clear the alarm and it also send to netcool soon as triggered.
if Sevone have the ability to hold the alarm and wait for 5 more minutes in the next poll it will get cleared from sevone and not send to netcool for incident creation and the incident count will be reduced . Hope this clarifies.
Hello. Is the issue you're facing that trap based alerts open and close quickly, and that you'd rather not be notified at all if they're open for < 5 minutes? Can you give us some examples of these alerts?