Component is up, component is down

I'm getting the same error, but we're working on getting our website to monitor properly.  So far it's never been "UP".  I'm assuming it's a website programming issue.

Does the website show the correct status when you remove the Search String defined in the HTTP component monitor?

Our programmer made some changes and now mine is working.  I don't know yet exactly what was corrected.  When I would personally try to access the page (from a different domain than where it is hosted; yet the same domain as the Orion server), I was getting an error:  'Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.' 

The stack trace contained:

[NullReferenceException: Object reference not set to an instance of an object.]

   OQTR.Objects.oSecurity.getEmailAddress(String _username) in C:\Documents and Settings\dm0\my documents\visual studio 2010\Projects\OQTR\OQTR\Objects\oSecurity.cs:207

   OQTR.SiteMaster.Page_Init(Object sender, EventArgs e) in C:\Documents and Settings\dm0\my documents\visual studio 2010\Projects\OQTR\OQTR\Site.Master.cs:24

   System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +24

   System.Web.UI.Control.InitRecursive(Control namingContainer) +132

   System.Web.UI.Control.InitRecursive(Control namingContainer) +420

   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1969

Hope that helps!!  I will try to find out what was changed.

One more thing, when I was getting the 200 error, the page displayed OK for me from IE, but I found 2 links/tabs on the page that would throw an error.  I think at least one of them was the same error as above.

The problem resolved itself after about 12 hrs. While I was seeing the issue I could navigate there in a browser just fine and could see the text that the Search String was configured to look for. Didn't try removing the test to see what would happen.

Hasn't reoccurred since, but if it does I'll try that test.

I realize now this is unrelated to the original request, although we were getting the same error.  Anyways, here is what our programmer did to correct the error.

I would guess that if other people are getting the same error then to try placing a try{} catch{} around their code where the program is making active directory calls.  Also, I was requesting an email address in my call to AD.  I doubt the service account you are using has an email address assigned in AD. "

I am have had the same issue. Once a week ago, and once last night.

Last week when we had the issue I tried to force a clear which did not resolve the issue. One of our techs disabled and reenabled the monitor in Solarwinds resolving the issue.

Yesterday it was noticed that we had one of these alerts that did not clear but 4 or 5 would come in and disappear from other servers. From a report on alerts I created it was identified that all of these "Alerts" for

Component is up. HTTP 200. Request succeeded

were being received on the same polling engine. Originally I restarted all services in Orion Solarwinds Manager both on our main Solarwinds Server as well as the affected polling engine. This made things worse causing a flood of bogus alerts from that polling engine. Rebooting the affected polling engine resolved the issue.

So from what Ive seen I would recommend either trying to disable and reenable the monitor, or rebooting the affected polling engine.

What I would like to know is

Why is this happening and how can this be avoided or identified? What does Solarwinds have in the way of identifying monitoring failures?

When this happens and we seem to be getting alerts for something good and that tests good from the monitor itself, are we also missing alerts due to this Solarwinds glitch?

Are there any patches/fixes or otherwise that address this?

Thanks

We have identified bug causing that component status changes could get lost under rare conditions which I believe can be related to this issue. This bug has been fixed for 6.1 which is currently in RC phase.

I would be interested whether restart of "SolarWinds Collector Data Processor" service instead of rebooting whole machine would be sufficient to resolve this issue.

We just saw this again on a http monitor. I restarted the SolarWinds Collector Data Processor via the Orion Service Manager and the problem cleared. So that appears to be a working fix for it until we can upgrade to 6.1.