<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: It&#8217;s bound to happen: How to handle alert storms</title>
	<atom:link href="http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/feed/" rel="self" type="application/rss+xml" />
	<link>http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/</link>
	<description>Monitoring, Scripting, and other Technologies</description>
	<pubDate>Tue, 06 Jan 2009 23:23:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Stefan Stranger's Weblog - Manage your IT Infrastructure : New OpsMgr Tool: OpsMgr Alert Closer</title>
		<link>http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/comment-page-1/#comment-83</link>
		<dc:creator>Stefan Stranger's Weblog - Manage your IT Infrastructure : New OpsMgr Tool: OpsMgr Alert Closer</dc:creator>
		<pubDate>Tue, 04 Nov 2008 08:40:20 +0000</pubDate>
		<guid isPermaLink="false">http://pavleck.net/?p=101#comment-83</guid>
		<description>[...] beta, so Jeremy would love it if you all could test it out for him. This is a perfect solution to handle those pesky alert storms and another tool in the [...]</description>
		<content:encoded><![CDATA[<p>[...] beta, so Jeremy would love it if you all could test it out for him. This is a perfect solution to handle those pesky alert storms and another tool in the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pavleck.Net &#187; Blog Archive &#187; New Contest and a new utility: SCOM-CloseAll</title>
		<link>http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/comment-page-1/#comment-82</link>
		<dc:creator>Pavleck.Net &#187; Blog Archive &#187; New Contest and a new utility: SCOM-CloseAll</dc:creator>
		<pubDate>Mon, 03 Nov 2008 22:05:11 +0000</pubDate>
		<guid isPermaLink="false">http://pavleck.net/?p=101#comment-82</guid>
		<description>[...] It&#8217;s bound to happen: How to handle alert storms [...]</description>
		<content:encoded><![CDATA[<p>[...] It&#8217;s bound to happen: How to handle alert storms [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeremy D. Pavleck</title>
		<link>http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/comment-page-1/#comment-77</link>
		<dc:creator>Jeremy D. Pavleck</dc:creator>
		<pubDate>Mon, 20 Oct 2008 21:17:11 +0000</pubDate>
		<guid isPermaLink="false">http://pavleck.net/?p=101#comment-77</guid>
		<description>Ah, good point AJ! 
If you want the same alert information in a more 'OpsMgr MS acceptable' method, you can also run the "Most Common Alerts" report under the Reporting tab.</description>
		<content:encoded><![CDATA[<p>Ah, good point AJ!<br />
If you want the same alert information in a more &#8216;OpsMgr MS acceptable&#8217; method, you can also run the &#8220;Most Common Alerts&#8221; report under the Reporting tab.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AJ</title>
		<link>http://pavleck.net/2008/10/06/its-bound-to-happen-how-to-handle-alert-storms/comment-page-1/#comment-74</link>
		<dc:creator>AJ</dc:creator>
		<pubDate>Fri, 17 Oct 2008 06:29:38 +0000</pubDate>
		<guid isPermaLink="false">http://pavleck.net/?p=101#comment-74</guid>
		<description>Thanks for posting this, handy escape route if the console's throwing a wobbly. 

I notice that "SELECT Count(*) FROM Alert" you suggested here shows all alerts that haven't been groomed regardless of open/closed state.  The result of that query came out around the 6 million alert mark for me (99.99% were closed).

I've manually kicked off the grooming stored proc to see whether it permanently cuts the numbers there and something just went awry in the nightly cleanup.

To figure out what to tune I've ended up running "select alertname, count(*)as x from alert(nolock) group by alertname order by x" to locate the worst offenders.</description>
		<content:encoded><![CDATA[<p>Thanks for posting this, handy escape route if the console&#8217;s throwing a wobbly. </p>
<p>I notice that &#8220;SELECT Count(*) FROM Alert&#8221; you suggested here shows all alerts that haven&#8217;t been groomed regardless of open/closed state.  The result of that query came out around the 6 million alert mark for me (99.99% were closed).</p>
<p>I&#8217;ve manually kicked off the grooming stored proc to see whether it permanently cuts the numbers there and something just went awry in the nightly cleanup.</p>
<p>To figure out what to tune I&#8217;ve ended up running &#8220;select alertname, count(*)as x from alert(nolock) group by alertname order by x&#8221; to locate the worst offenders.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
