False Alerts

We have seen some times that some of the alerts we recieve are false.

Here is one that happened this morning. We have two services setup to monitor the event logs on servers for event ID 20 and another one to monitor for event id 15. These are to see if the drive goes away or fails. This morning uptime reported an error with those two services on two different servers on two different parts of the nextwork, 10.49.10.x and 10.10.20.x. One error set was at 4:45am and the other was at 7:23am. During this time the servers were not down, they were reachable by ping, and no event logs were created on them that would match the requirments. These services monoitor about 50 different servers. Any help would be greatful. Below are screenshots of the Service setups.

  • Hey James!

    I'm going to hazard an assumption here that the false alarms you're talking about had to do with response time? Were these alert emails? Can you post the content of them so I can see the message? Your service monitors shown here are going to alert on either of two conditions currently. One, if the criteria is met for the event ID being seen in the logs, the other based on how long it takes to complete the call and response mechanism of the service monitor. There are lots of factors that can impact te response time from monitoring station performance, network or server latency, typically... This is true of our PING service monitors as well. One of the alertable criteria is the response time. In my personal opinion, monitoring response time of a service monitor has very limited value except for uncovering what service monitors are performing poorly and to tell us if perhaps we need better resources (if many perform poorly, reliably) on our monitoring station, or some performance tweaks. There are tons of setting in Uptime to tweak its operation for different setups and monitoring scenarios, some of which are covered in documentation and some of which are just "standard" practices for JVM tuning (as both monitoring services are running in JVMs).

    Thanks,

    Robert