How grooming and auto-resolution work in the OpsMgr 2007 Operational database
<!--[if lt IE 9]>
<![endif]-->
Comments
Anonymous
January 01, 2003
@Keithk2 - On monitors - these get autoresolved just like rules (30 days) - except if the alert source (the monitor state) is healthy, then 7 days. You are correct - in that it creates a problem if a monitor based alert is resolved after 30 days - and the alert source (the monitor) is still unhealthy. I suppose, if you haven't fixed to the root cause of the monitor state after 30 days.... the shame is on you, no the autoresolution. :-) Yes - sometimes changes to what generates notifications will be modified in a service pack, R2 update, or even a CU. I know that based on customer feedback and requests, there have been some changes made here. However, if you dont subscribe to closed alerts, then you wont get alert notifications about them being closed.Anonymous
January 01, 2003
Kevin, most of the monitors have a parameter called "Auto-Resolve Alert". When it's set to False, the monitor in New state should NOT be automatically resloved after the source becomes healthy or resloved after 30 days when the source remains unhealthy, should it? I assume the parameter overrides the system "Auto-Resolve Alerts" settings. Thanks for your feedback.Anonymous
January 01, 2003
This appears to be present up to RC-SP1 version, build 6.0.6246.0   In the Task Status console viewAnonymous
January 01, 2003
One other thing. We just started getting email notifications from alerts resolved by "auto-resolve" only in the last few weeks. A few weeks prior to that we went to CU5 from CU1. I know you have pretty good knowledge of these updates in CU5, therefore can you confirm any connections?Anonymous
January 01, 2003
Auto-resolve setting of a monitor has no bearing. These stored procs will modify the alerts as designed based on the criteria specified above.Anonymous
January 01, 2003
Kevin, Sounds good for rules, but monitors? Correct me if I am wrong, but if a monitor's alert get's resolved while the state of the monitor is still unhealthy, then the alert won't get raised even though it is still a unhealthy. This sounds like a problem for the same reason we should never manually close an alert for a monitor since the health state is not reset. Appreciate clarification on this. Thanks in advance Kevin, KeithAnonymous
January 01, 2003
@Suresh - No - you misunderstand. We never groom alerts in any active resolution state. We ONLY groom alerts in resolution state 255 (closed). That should be CRYSTAL clear from the first half of this article. We RESOLVE alerts alerts (set the alert to 255) based on the crtieria in the article. THEN, the grooming will groom it out based on your alert retention setting in the console (7 days by default).Anonymous
January 01, 2003
@shashikanth - This is one of the ley difference between monitors and rules. Monitors have a health state, and when the state goes back to healthy - there is a link between the monitor state and any alert generated - where the default behavior is to auto-close the alert if the monitor that generated it returns to healthy. However, there is no "auto-close" of alerts from rules. Since there is no health state association.... alerts from rules are generated by a write action within the rule definition. We do EVENTUALLY auto-resolve alerts from rules, as long as they meet the retention criteria and have not been modified since that time. Our default for rules is to autoresolve them after 30 days of zero attention/modification, which is described above. This is also configurable. The idea is, that if you have done anything about the issue after a month, then you probably aren't going to, so we will close the alert in order to free up resources and de-clutter the console.Anonymous
January 01, 2003
This is a continuation of my other post, on general alert grooming: How grooming and auto-resolutionAnonymous
January 01, 2003
Thanks Kevin for the clarification. Agreed on the first point, but how nice would it be if it could reset health as well or even have auto resolution settings for rules and monitors seperatly. Good to know what to expect though at this point and appreciate your timely feedback!Anonymous
January 01, 2003
Well, I don't know of any reasons that you couldn't change the time on that workflow... auto-resolution isn't really a big deal. That need makes perfect sense.Anonymous
January 01, 2003
What would be the reason you'd want to change that? In general, auto-resolving alerts should be a relatively quick SQL operation, and I am not sure under what context one would need to change this.Anonymous
January 01, 2003
Thanks for educating me Kevin!!! Need some clarification on your statement "Resolve all alerts where the object has returned to a healthy state in “N” days". Do you mean the Agent health for particular server (or) Health of a monitor or rule for that alert? I am asking this bcoz, if the agent is healthy, then monitors will change the state automatically to closed if the issue resolved. At the same time, this is not possible with Rules. Could you please clarify this statement? Thanks, SureshAnonymous
December 17, 2011
Kevin, Good Day!!! Can you confirm if this document is applicable for SCOM 2007 R2? From the doc(as per above screenshot), I understand 1. Any alert which is set to Resolution State (0, 255 and custom states(e.g,55,56)) will be groomed after 30 days and 2. Any alert which is set to Resolution State (0, 255 and custom states(e.g,55,56)) and if the particular agent is healthy then it will be groomed in 7 days. Is my understanding correct? Please help me. Thanks in Advance!!!Anonymous
March 20, 2013
Hi I am able to find "Auto-Resolve Alert" override settings of a Monitor but not in RULE Alerts, how to change the settings of a RULE that should not close automatically,, requirement is ------Alerts generated by a RULE should not AUTOCLOSE, ShashikanthAnonymous
August 04, 2014
Hi
Can we change scheduled synchronise time of 4:00AM of rule "AlertAutoResolveExecuteAll"?Anonymous
August 07, 2014
Hi Kevin, first of all thank you for the above article. I just saw your answer to Vikas question and I have to say, that I want to change the time from 4:00 AM to 11:00 AM too. The reason for this is our Incident Manager gets woken up at night by these closed alert messages.Anonymous
April 25, 2016
Kevin,What is the support ability if the "auto resolve" stored proc is edited to not auto resolve alerts generated by a specific rule with a specific resolution state?As example, I have a custom scripted monitor that generates an alert based on an event. It can be 3+ days before another event comes in, and the issue is still active. This same script closes the alert if the next received event passes the criteria for it to be resolved. As I have a resolution method for these specific alerts, I need them to be ignored by the Auto-Resolve sproc.- Anonymous
April 25, 2016
We do not support any customer modifications to our stored procedures. You'd have to understand any update we make would also overwrite your custom sproc.For something like this - I recommend a different approach. A custom script that runs once per day - and updates some field in the alerts.... therefore their lastmodified time will be bumped and they will never auto-resolve.
- Anonymous
Anonymous
May 25, 2017
Hi Kevin,We have a setting for the Resolve all active Alerts in the new resolution state after : 7 days AND Resolve all active alerts when the alert source is healthy after : 1 day.We have some rule alerts from UCS management pack for which the alerts are getting auto resolved by the "resolve all the active alerts when the alert source is healthy " after 2 days at 4:00.But since these alerts are from rules so why it is getting resolved by second part?ThanksAshishAnonymous
November 13, 2017
Hi Kevin,I have question regarding closure of Healthy alerts. Is it by design that alerts are getting resolved based on Entity Health monitor and not by Alert's own monitor? Seems counterintuitive. For example - if alert was raised by monitor that not affects entity health state, it will be autoresolved, but still be unhealthy.- Anonymous
November 20, 2017
The same situation.The behaviour seems to be strange, @Kevin for SET @RootMonitorId, is it "be design" or error?IF (@AutoResolveType = 0) BEGIN SELECT @AlertResolvePeriodInDays = [SettingValue] FROM dbo.[GlobalSettings] WHERE [ManagedTypePropertyId] =dbo.fn_ManagedTypePropertyId_MicrosoftSystemCenterManagementGroup_HealthyAlertAutoResolvePeriod() SET @AutoResolveThreshold = DATEADD(dd, -@AlertResolvePeriodInDays, getutcdate()) SET @RootMonitorId = dbo.fn_ManagedTypeId_SystemHealthEntityState() -- We will resolve all alerts that have green state and are un-resolved -- and haven't been modified for N number of days. INSERT INTO @AlertsToBeResolved SELECT A.[AlertId] FROM dbo.[Alert] A JOIN dbo.[State] S ON A.[BaseManagedEntityId] = S.[BaseManagedEntityId] AND S.[MonitorId] = @RootMonitorId WHERE A.[LastModified] < @AutoResolveThreshold AND A.[ResolutionState] 255 AND S.[HealthState] = 1
- Anonymous