Why not store the record number in the registry? Each different comcheck would have a
different host ID (based on the hosts file), yes? A simple structure of something like:
[HKLM].......\
comcheck\
DWORD:HIDnn, Value: {recno}
DWORD:HIDnnn, Value: {recno}
DWORD:HIDnnnn, Value: {recno}
Wouldn't this work? The overhead on a registry update of a single key can't be that
much, can it?
--
Jon Freivald ( [EMAIL PROTECTED] -- http://www.netmindconsulting.com )
( phone: 516.794.7696 x101 / fax: 516.794.7811 )
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, July 08, 2004 6:58 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [SA-list] Event Log COM check questions
>
>
>
>
>
> 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.Nfw~ïz
> %×Nryèb Öj)fzh+-Å 'z{mZ0x"^nrazg {.n+X
>
