The record number is stored as MXR (if memory serves me well). We have to store that dynamic data somewere and the hostfile is the most appropriate way. Other option is (as you said it) to not store it at all and to restart the check for the last record each time SA restarts. Big issue with that is that this means that SA needs to know the structure of the data of the external COM check. Since it's the external COM check that is making the change within it's own parameters.
Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 09, 2004 12:58 AM 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.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
