That would mean that the checks as such are partialy in the hostfile and partialy in the registry, that doesn't look like a good solution.
Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon A. Freivald Sent: Friday, July 09, 2004 6:58 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions 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 > N~z Nryjz²znz{.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
