I guess the logic behind this is that the "Alert After N Times" is often used to prevent alerting when a parameter "moves" up and down a little erratically, and you don't want an alert to be triggered because of a short spike on Processor Time, for example.
The same is true for closure: you don't want the alarm to be reset because of a short drop in Processor Time (being steadily at 100%, except for some time where it drops to 75%, and then goes back to 100%). In such a case, if you would close the event immediately, the monitor would appear as "ok" while the problem is still actually on. And then, you get a new event after a little while, and therefore get spammed again with multiple alerts for the same problem.
But I totally understand your use case: when the parameter is not expected to have spikes, there is no point in waiting before closing the event.
I don't fully agree with the scenario you describe: if you want to be alarmed after 3 hours of 100% cpu you won't be spammed if closure happens instantly because cpu decreases to 75% because it would take another 3 hours to get a new alarm.
What is really wrong here is the strong and unreasonable assumption that if you want delayed alarms then you also want delayed closures with no chances to configure it.
Besides, im not familiar with patrol agents anymore so I'm not sure but i think that when you configured a parameter to send alarm after n times above threshold the ok state was triggered as soon as the metric was back below. If things were working that way, why changing this basic behaviour? I can hardly recognize this as an improvement.
Inviato dal mio dispositivo Huawei
I wish it were easily configurable to turn this behavior off, if not desired. Does anyone know if this is the case in TrueSight 11.0 as well?
When engaged on this matter, BMC support told me that it has always been like that since bppm v8 and that i'm the first to request a different behaviour, they suggest to open an idea....so i don't think that TS11 behaves differently.