I absolutely agree that in some circumstances, a timeout is a down. I’m sure you would also agree that in some circumstances, a timeout is not necessarily a down. My preference is that the person configuring Servers Alive decide what to do with a timeout and what to do with a down. Perhaps a checkbox on the alert screen would make configuring timeouts versus down easier?
Regards, Brett From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: Saturday, November 30, 2013 1:31 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Enhancement request - differentiate between down and timeout I understand the request, but as you already said it yoursefl the feature you want is already in the product. Also how to dfiferenciate between a timeout that is a real timeout and a timeout that is a real down? For example in some cases a ping to an host that is down will result (talking about what you would get at the commandline) Pinging x.y.z.aa with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. => is this down or a timeout? Dirk Bulinckx Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu/) StellarDNS (DNS Hosting) - http://www.stellardns.com (http://www.stellardns.com/) -------------------------------------------------------------------------------- From: Servers Alive Discussion List [mailto:[email protected] (mailto:[email protected])] On Behalf Of Hanson, Brett Sent: Friday, November 29, 2013 10:01 PM To: Servers Alive Discussion List Subject: [SA-list] Enhancement request - differentiate between down and timeout I get a fair number of false alarms due to timeouts. In my opinion, not getting a response in the allotted time window doesn’t necessarily mean the check is down, and I don’t want a service restarted just because Servers Alive had some network issues. For instance, I have two instances of Servers Alive running. The first instance does all the real work. The second instance watches the first instance. To do this, it is looking to see if the log file has changed in the last 30 minutes (file properties check looking for the youngest matching file write date being more than 30 minutes ago). Both instances are located in the same data center, the first instance is a physical machine, the second is a virtual machine. A few times a day, the second instance will alert that Servers Alive Application is DOWN (ERR: didn't stop within the given timeout). The timeout is set at 15 seconds. In this case, a timeout doesn’t mean that the first instance of Servers alive is down, it just means that the second instance couldn’t figure it out. The last thing I want is for the first instance of Serves Alive to restart and lose its state because the second instance decided “I’m not sure, so I’ll say it is down”. I am aware that you can use the “When the Extra info field” on the alerts, but it just seems messy and prevents you from using the extra info field for more interesting uses. I would like an enhancement to Servers Alive that would treat timeouts as possible down or possibly available, or as a completely different condition. Ideally, you could have alerts specifically for timeout conditions, or (what I’d really like to see) have a different check called if a timeout occurred. Thank you, Brett Hanson Systems Analyst Agrium Inc. -------------------------------------------------------------------------------- IMPORTANT NOTICE ! This E-Mail transmission and any accompanying attachments may contain confidential information intended only for the use of the individual or entity named above. Any dissemination, distribution, copying or action taken in reliance on the contents of this E-Mail by anyone other than the intended recipient is strictly prohibited and is not intended to, in anyway, waive privilege or confidentiality. If you have received this E-Mail in error please immediately delete it and notify sender at the above E-Mail address. Agrium uses state of the art anti-virus technology on all incoming and outgoing E-Mail. We encourage and promote the use of safe E-Mail management practices and recommend you check this, and all other E-Mail and attachments you receive for the presence of viruses. The sender and Agrium accept no liability for any damage caused by a virus or otherwise by the transmittal of this E-Mail. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] (mailto:[email protected]) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] (mailto:[email protected]) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
