OK, I'll certainly try that... But sometimes the interface is slow slow making changes while it's running is brutal. And other times you just can't help it if the box needs to be rebooted, or the service stopped for whatever the reason......
Troy --- Troy Bruder, Manager - Hosting and Microsoft Services APT Information Technology Consultants 7540 Windsor Dr. STE 204 Allentown, PA 18195 Phone 610.366.1100 -or- 888.2.GET.APT http://www.aptconsulting.com "Dirk Bulinckx" <[EMAIL PROTECTED] To: <[EMAIL PROTECTED]> u> cc: Sent by: Subject: RE: [5] RE: [SA-list] change in state [EMAIL PROTECTED] stone.nu 09/04/2003 10:14 AM Please respond to salive Don't stop the service, just logon localy to the host running Servers Alive, right click on the tray icon and open the GUI from it and make the needed changes... dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Thu Sep 04 4:08 PM To: [EMAIL PROTECTED] Subject: RE: [5] RE: [SA-list] change in state I hear ya... But who said you would be "suppressing alerts"?? I'm not asking for that, I'm asking that duplicate alerts, based on SA being stopped for whatever reason (good, bad, ugly, or indifferent), shouldn't re-generate alerts that have already been sent. Here was my situation... Maybe my lack of product experience with SA causes some trouble.. A customer of mine is running SA with over 100 alerts. They have 20-30 Internet based checks all of which failed during an internet outage. Their firewall is outsourced, so we cannot ping it to check its availability so therefore perform bunches of direct internet based checks.... When the internet line failed, we got all the alerts for Internet checks. No problem. In the mean time, I had to change some SQL passwords, and add a bunch of new monitors... Since we run as a service, I like to stop the service, run the app, and make my changes.. I find that if the app starts running, I need to stop it immediately cause the interface is too slow... I like making changes via the app since the interface is very pleasant to work with. Once I made my changes, and restarted the services, I was treated to 20-30 "duplicate" alerts I had already received... If SA tracked state change/alert status in a file, it would have know that it already alerted for the problem, and not sent out a duplicate alert... See my point? Troy --- Troy Bruder, Manager - Hosting and Microsoft Services APT Information Technology Consultants 7540 Windsor Dr. STE 204 Allentown, PA 18195 Phone 610.366.1100 -or- 888.2.GET.APT http://www.aptconsulting.com "Brent Ozar" <[EMAIL PROTECTED] To: <[EMAIL PROTECTED]> .com> cc: Sent by: Subject: RE: [5] RE: [SA-list] change in state [EMAIL PROTECTED] stone.nu 09/04/2003 09:51 AM Please respond to salive You hit the nail on the head: you wouldn't stop a "big boy" product just to make configuration changes, so why stop SA? I don't understand why people are restarting SA all the time. The only time a user should stop SA is when: - The machine is rebooted - SA is upgraded Other than that, restarting SA is like restarting my SQL server. Anybody does it, I'm going to break their fingers. I'll give you a real-world example: last weekend, we had a power outage in the office. One by one, the UPS's gracefully shut down the servers, and as I hoped, the SA machine was one of the last ones to die. When we brought the machines back up, I brought the SA machine up last, because I needed to know which boxes weren't responding correctly. If SA suppressed alerts, I wouldn't have known which boxes were down - because SA would have thought everything was supposed to be down, and that it was okay. A down box is NOT okay. I know this sounds like a dodgy answer, but the day I suppress 20-30 alerts is the day I get a pink slip from my boss. The last thing I want is SA suppressing alerts. Brent -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 8:28 AM To: [EMAIL PROTECTED] Subject: RE: [5] RE: [SA-list] change in state That's a good idea, but I don't think the "right" way to fix the problem... I'm just trying to suggest "big boy" features for the SA product.... Imaging if a Tivoli or Network Node Manager from HP ran like this.... I know SA wasn't designed as a competitor to the big guns... but, I think it's such a great tool I can't help but offer suggestions to make it better! Troy --- Troy Bruder, Manager - Hosting and Microsoft Services APT Information Technology Consultants 7540 Windsor Dr. STE 204 Allentown, PA 18195 Phone 610.366.1100 -or- 888.2.GET.APT http://www.aptconsulting.com "Brent Ozar" <[EMAIL PROTECTED] To: <[EMAIL PROTECTED]> .com> cc: Sent by: Subject: RE: [5] RE: [SA-list] change in state [EMAIL PROTECTED] stone.nu 09/04/2003 09:20 AM Please respond to salive Let me toss out an alternate suggestion: how about a command line switch that will disregard all errors for the first check cycle? So if you ran it with salive /skipfirst, let's say, it wouldn't send any alerts during the first run of checks? Would that make people happy? Then, have an option where you can start ServersAlive as a service that way by default? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 8:09 AM To: [EMAIL PROTECTED] Subject: RE: [5] RE: [SA-list] change in state But your suggestion is almost impossible when you run as a service.... If an alert has been generated, the app should assume it was received.. --- Troy Bruder, Manager - Hosting and Microsoft Services APT Information Technology Consultants 7540 Windsor Dr. STE 204 Allentown, PA 18195 Phone 610.366.1100 -or- 888.2.GET.APT http://www.aptconsulting.com "Jason Passow" <[EMAIL PROTECTED] To: <[EMAIL PROTECTED]> > cc: Sent by: Subject: RE: [5] RE: [SA-list] change in state [EMAIL PROTECTED] stone.nu 09/03/2003 04:56 PM Please respond to salive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive
