Ahhhh... OK. I guess the catch is that you're "caching" the record number
in the host file (this I did not know) which works for you with regards to
efficiency between SA restarts (as long as the host file is saved before SA
is Stopped) but against you if you don't know that it records the record
number when saving the host file and don't save your SA host file before
Stopping SA. From my perspective it's a brave assumption that people would
*always* save their host file before stopping SA to ensure the recordnumber
is updated and stored correctly.
Anyway.... options....
1. Don't store the recordnumber (or make it optional) in the host file - I
guess this would hurt the initial COM check performance big-time and would
be a horror if people were using it over WAN links and/or have large event
log files. It also wouldn't solve my particular problem since an initial
scan after SA startup would still possibly find a matching event entry
unless, as you indicated, the check or the recordnumber was coupled with a
timestamp.
2. Continue to store the recordnumber but include a timestamp as you
suggested. Looking like the best option so far....
3. Don't store the recordnumber in the host file and on SA startup only
start scanning the event log to define the most recent recordnumber from
the corresponding start time of SA. This seems to be the most logical
approach for mine but may have other implications I'm not aware of.
I still find it odd at a conceptual level that we're storing "dymanic" data
in the host file. I figure the host file should only ever contain what we
plugin via the SA GUI and not be updated by the app with dynamic data.
Maybe that's just me... ;-)
Out of curiosity, which part of the host file entry in the raw host file
designates the recordnumber?
Cheers,
Anthony
"Dirk Bulinckx"
<[EMAIL PROTECTED]
u> To
Sent by: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] cc
stone.nu
Subject
RE: [SA-list] Event Log COM check
09/07/2004 08:21 questions
AM
Please respond to
[EMAIL PROTECTED]
nu
Basicly what happens.
The check is started.
We get all the parameters from the hostfile (or from a newly created
entry).
One of the parameters is the "recordnumber" of the last eventlog entry that
was "checked".
If it's a new entry then that recordnumber is -1 and we know that we had to
set the recordnumber to the real last recordnumber within the eventlog.
Next cycle we only look at the new entries, new based on recordnumber, that
is those that have a record number above the one that we knew from the
previous check.
If you save the hostfile that entry will be in it and will have that
recordnumber too.
Then you stop Servers Alive.
Wait a couple of hours.
Start Servers Alive, load the hostfile and the first check is done and will
have a recordnumber and will give a down (if between the previous check and
the current check there was an new entry within the eventlog that matches).
Now lets presume the following situation.
You create a new entry (eventlog check), first cycle with that one running
it will set the record number. Couple of cycles later you do a save of the
hostfile (for example recordnumber = 541). SA continues to run and after
100 cycles the eventlog is at record number 1000. You stop Servers Alive.
And start it directly, load the hostfile and start checking. The
eventlogcheck will start the checking and will check the eventlog entries
with a recordnumber above 541. And will find something that happened maybe
in recordnumber 800, for which you already got an alert. Next cycle you'll
get an up. Since it will then check all new eventlogentries, meaning after
1000.
What can we do about this?
Several options.
* you have to save the hostfile before quiting SA, that way
the
counter is saved correctly.
* we add a timestamp to the recordnumber and if an "initial"
check
is done more then 15 minutes (example!!) after the timestamp then we ignore
the recordnumber and concider this as being an new entry and as such set
the
recordnumber.
* other ideas???
Dirk.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 11:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [SA-list] Event Log COM check questions
Dirk,
For point 1., I seem to be seeing a different outcome, ie. SA starts up and
COM check scans the event log but I always get a DOWN followed by an UP the
following cycle, ie. the fact that a matching event log entry exists in the
event log *somewhere* is being picked up by the COM check. I also seem to
be seeing two instance of the check being performed in the first cycle, one
at the expected time in the cycle and then again at the end as though a SK
has been invoked. It is this 2nd attempt which is then generating the DOWN.
I've sent a log extract off-list.
Cheers,
Anthony
"Dirk Bulinckx"
<[EMAIL PROTECTED]
u> To
Sent by: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] cc
stone.nu
Subject
RE: [SA-list] Event Log COM check
08/07/2004 04:37 questions
PM
Please respond to
[EMAIL PROTECTED]
nu
1. The COM check get the "recordnumber" of the newest eventlog entry and
keep that, and that is what is done in the initial check, if it's able to
do
that it will give an UP.
2. Your pointing to the exact reason why I was always opposed (and basicly
still am) to doing eventlog checks. A down is clear and up isn't. In the
eventlog most apps won't log when all is well, only when it's not ok.
Don't
think there is a good solution for it. Maybe explain that to the
non-understanding tech people.
Dirk.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 12:15 AM
To: [EMAIL PROTECTED]
Subject: [SA-list] Event Log COM check questions
I'm using the Event Log COM check v1.0.0.7 with SA 4.1.1618 and there's a
couple of issues around the way it works that I'd appreciate any advise on.
The check I have setup is a simple "Give a DOWN condition when 'at least
one' new event log entry matches".
1. When SA first starts up and the check establishes it's initial
checkpoint it usually finds a match to generate a DOWN condition that we
have previously been alerted to since our event log (in this case the
System Event log) takes weeks to roll over, ie. the event entry could be
2-3 weeks old. Is there any way of having the COM check know that SA has
just started and therefore while establishing it's initial event log
checkpoint NOT to generate a down condition? If not, could this be a
feature request (or possibly a bug submission depending on your point of
view)?
2. Because the Event Log check is going to always generate an UP condition
in the cycle after a DOWN condition *unless* the event log entry is
repeated, and for the check I'm doing there is no corresponding event entry
to indicate an UP condition after the DOWN, I have a constant problem with
other admins seeing a DOWN alert followed by an UP alert the following
cycle (as expected) and then interpreting this as a "glitch" and everything
is OK. I know this comes under "educating admins" but I'm wondering if
anyone has any creative ideas on how to prolong the DOWN condition alerts
I'd appreciate the thoughts.
Cheers,
Anthony
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.NfAw~?z
% N ry b ??j)fz?h+- 'z{?m? Z0x"^n?razg ?{.n+?X
--------------
[This E-mail scanned for viruses by Declude Virus]
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.NfAw~z
?Nry ?j)z + z{??Z?xn?zg{.n+?X
--------------
[This E-mail scanned for viruses by Declude Virus]
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¬f¢–Çžw~Šï¬zÆò
ç%¹×Š»¬N‹§²æìr¸›yúèb²Û Öj)fzËëh–+- ²Ú'z{–ŠØm…çè–Z0Šx"žØ^n‡r¡ûazg¬±¨ º{.nÇ+‰·’X¯
