A tidbit on tuning some Self-Tuning threshold monitors
I wrote up a blog post long ago on loving and hating STT (Self Tuning Threshold) Monitors HERE
This is something I noticed in R2…. I don't remember seeing this in SP1 before…
I was getting some alert noise on my Windows Server 2008 Terminal Server – from the “Total Number of Active Sessions” monitor. This is a self-tuning threshold monitor that examines the active session count from perfmon, and will alert if it goes outside the calculated baseline. This is cool – however – my Terminal Server goes from having nobody connected (zero) to as many at 8 connected. Well – any counter that is often, or regularly at “zero” is not a good candidate for a self-tuning threshold monitor – because the monitor will be noisy. So – I disabled this monitor… since I don't care. If I did care – I would just create my own static threshold monitor.
Well – as soon as I did that – I started seeing this event in the agent event logs:
Log Name: Operations Manager
Source: Health Service Modules
Date: 7/31/2009 11:13:46 AM
Event ID: 10123
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: OMTERM.opsmgr.net
Description:
Duplicate Signature ID usage detected for STT Signature ID: 'SignatureID:[Microsoft.Windows.Server.2008.TerminalServicesRole.Service.TerminalServer.InactiveSessions.Sig]\{697C0377-22AB-4C10-F23D-A353A58DB35E}'. The STT Rule and monitor for this ID might differ in configuration - please reconcile the settings.
Alternately, this Signature ID may already be in use. Assign a previously unused Signature ID for this STT Rule/Monitor.
Module will be unloaded.
Signature ID: 'SignatureID:[Microsoft.Windows.Server.2008.TerminalServicesRole.Service.TerminalServer.InactiveSessions.Sig]\{697C0377-22AB-4C10-F23D-A353A58DB35E}'
Workflow name: Microsoft.Windows.Server.2008.TerminalServicesRole.Service.TerminalServer.InactiveSessions.BaselineCollection
Instance name: Terminal Server
Instance ID: {697C0377-22AB-4C10-F23D-A353A58DB35E}
Management group: PROD1
I was getting these every time there was a config update on the agent! (picture below filtered for this event ID only)
What this is saying – is basically that all Self-Tuning Threshold monitors have a corresponding rule that goes with them – and there is a mismatch between the configuration of rule and monitor.
So – in this case – I need to go find the corresponding rule (general will have the same/similar name) and set the overrids on that rule to be the same (disabled in this case) Most of the time you can search on “Baseline” or “Collection” to find them… and they will target the same class as the monitor:
Once I set this override – those events go away on my agents and all is well in OpsMgrLand again. Time to hit the Relax button.
