I guess the question then is knowing precisely what data will be in the %e
variable returned?
I'd be keen to use this feature as I often have NT process checks on
servers on remote sites "fail" due to network timeouts or the server
timeout. The process checks are dependent on a ping check which has not
failed in these circumstances so what I'd need to find out is what the %e
variable will contain
1. when the process check has failed (in my case, 1 instance of the
nominated process detected for some systems and less than 1 instance on
other systems)
2. when the check failed "failed" due to server/network timeout or being
unreachable (in which case the dependent ping check will fail)
Anthony
"Dirk Bulinckx"
<[EMAIL PROTECTED]
u> To
Sent by: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] cc
stone.nu
Subject
RE: [SA-list] Question re: type of
06/01/2004 08:40 alert...
AM
Please respond to
[EMAIL PROTECTED]
nu
No I mean using the option as explained below of Servers Alive.
Dirk.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Michael Shook
Sent: Monday, January 05, 2004 10:37 PM
To: [EMAIL PROTECTED]
Subject: RE: [SA-list] Question re: type of alert...
I think you mean to create a rule in my email to filter out unwanted
messages? Thats a great idea, and will work for those alerts.
Unfortunately,
most of the people use text messaging to get the alerts. I don't believe
any
of our phone allow for rules of this type. This brings me back to SA being
able to send alerts based on the %e parameter as well as the UP/DOWN
condition.
Mike
>>> [EMAIL PROTECTED] 01/05/04 04:23PM >>>
IF it's possible to filter on the message that is within the %e parameter
then you can do this by using the
[ ]When host is down the "Extra info field" should contain
Option
This is NOT in 4.0.1376 but in the later beta's (http://beta.woodstone.nu)
Dirk.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Michael Shook
Sent: Monday, January 05, 2004 10:16 PM
To: [EMAIL PROTECTED]
Subject: [SA-list] Question re: type of alert...
Is it possible to have 2 different types of alert responses?
Here's what has been asked:
If the check fails due to a communication, time-out or other error = Alert
type #1 for net admins
If the check is sucessful in connecting, but fails the alert rule = Alert
type #2 for others
What I've been asked is essentialy to somehow prevent the people who are
responsible as Alert group #2 from getting alerts that they can't do
anything about (alert group #1 stuff). The DBA's can't fix ODBC failures or
Com. errors and the Network Admins are getting tired of all the errors that
the DBAs fix. Even being able to send alerts only when the check connects
sucessfully, but fails the rule would help.
Dependecies are only partially able to adjust for this, but it looks like
the individual checks would need this capability.
Any ideas?
Michael Shook
Technical Support Analyst - Corporate
Saddle Creek Corporation
723 Joe Tamplin Industrial Blvd
Macon GA 31217
478 742 8740 ext. 105 (work)
478 256 9318 (mobile)
478 742 7917 (fax)
[EMAIL PROTECTED]
http://www.saddlecrk.com
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
The information contained in this email message and any attachment is for
intended recipients only. It may contain confidential, privileged or
copyright material. If you receive this email in error please delete it
and any attachments and notify the sender immediately by reply email. Any
use, reading, copying, distributing or disclosure of the information in
this email is strictly prohibited if you are not the intended recipient.
Any views expressed in this email are not necessarily those of TNT. TNT
does not warrant that this email is free from viruses or other defects.
TNT is not liable for loss, damage or other consequences that may arise
from opening or using this email or any attachments.
âTNTâ means TNT Australia Pty Limited, its related companies and
subsidiaries and includes McPhee Transport Pty Ltd, Riteway Transport Pty
Limited, TNT Materials Handling Pty Ltd and TNT Logistics (Australia) Pty
Limited.èº{.nÇ+‰·Ÿ®‰š–+-±éÝjf¢–g¬±¨ ¶‰b²Ü(¡Û-¢w§¹h†Ø^~‰e£§‚)í…æèw* ¶¦zËëæìr¸›y
%Š÷
