This is really easy to do, actually. You just add a check for a "known
good" internet service, like the first hop on your internet router, and set
all of the internet-based checks to depend on that one.
So for example, if you've got an outsourced firewall, you can't ping that,
but you can ping the first step past that. Go to a dos prompt on one of the
machines behind the hosted firewall, and type "tracert www.yahoo.com". That
will show you each step from that machine to Yahoo. Look at the second and
third entries in the list, which are the steps between the hosted firewall
and the "real world", and you'll likely see several IP's at your internet
provider.
Another thing you can do is ping a known-good internet site, like
www.yahoo.com, and use that for a dependency. Yahoo's DNS is hosted by
Akamai, so they're incredibly reliable, and they always respond to pings.
I've done that for a few years and I've never gotten a single false-down
from Yahoo.
Brent
--------------------------------
Brent Ozar - UniFocus
--------------------------------
"I could be a rambler from the Seven Dials
I don't pay taxes 'cuz I never file
I don't do bidness that don't make me smile
I like my aeroplane 'cuz she's got style...."
Jimmy Buffett, Treetop Flyer
-----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
