That was just a big advantage of the COM check that all info was within Servers Alive, with the external errorlevel you had a part is SA (the call) and the config in a section of an INI. Don't want to go that way with a COM check.
Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, July 09, 2004 2:03 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Just realized how disjointed that post was. Same post just edited slightly. The way the check is written (give a down when....) a down is when something BAD as you say is written to the event log. Therefore a down is a true down as far as I am concerned. As to what to do about the last record variable.. Writing a variable to the static host file does seem a bit hoaky (sp?) to me. Perhaps for the eventlog check another ini file should store this dynamic data (written after every time the check is run). Or as someone else suggested storing latest record number in the registry under the event log check. I can understand from your programming point of view not wanting to store it in the registry because then you have to get the hostfile data and then read the registry key when the check is performed (although I think it is still the best solution). Then an .ini file is the best way just as with some external error level checks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, July 09, 2004 6:54 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Writing a variable to the static host file does seem a bit hoaky (sp?) to me. Perhaps for the eventlog check another ini file should store this dynamic data. Or as someone else suggested storing latest record number in the registry under the event log check. I can understand from your programming point of view not wanting to store it in the registry because then you have to get the hostfile data and then read the registry key when the check is performed (although I think it is still the best solution). Then an .ini file is the best way just as with some external error level checks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Friday, July 09, 2004 2:47 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Checking the last abc minutes will give you more possibilities in having double downs OR missing downs. Assume check last 5 minutes and the cycle only takes 3 minutes (all was up) then you can have an entry causing 2 downs instead of 1. If that same check takes (worse case scenario) 7 minutes (all was down) then you would miss the entries in the 2 minutes that are not checked. Also from what I've seen from WMI you can't correctly do a query for the entries of the last 5 (or whatever other number) minutes. Option is then to rewrite the com check to use something else then wmi (api calls just the Perl version), but that is for me not an option. I was already opposed to having an event log check and then rewriting it is currently totally out of the question. I'm still "stuck" on the idea that an event log check can't work correctly due to the nature of the event log (or better the nature of apps writing to the event log). Most of them write bad things not good things, this means that a DOWN is mostly clear an up not. Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, Andy Sent: Friday, July 09, 2004 9:08 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Guy's, I use a number of eventlog entry checks using Mark Bradshaw's original perl script version and have never experienced this sort of problem. Using this version one of the parameters is 'time in minutes to search' which, used in conjunction with the check cycle, this means you can check only the eventlog entries that have been added in the last XX minutes where XX minutes (give or take a minute or two) is also used as the check cycle. This can take a bit of work to get operating correctly, as you will sometimes need to adjust the 'time in minutes to search' and the check cycle a little, but once you have these set correctly for your needs it should be 100% reliable (or as near as possible). Would using this perl version help solve the issue, or could this functionality be added to the COM version. (Perl version - CheckEvt 1.0 - Copyright 2002, Mark Bradshaw ([EMAIL PROTECTED])) Andy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dirk Bulinckx Sent: 08 July 2004 23:21 To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions 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.Nf To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With the following in the body of the message: unsubscribe SAlive -------------- [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 -------------- [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 -------------- [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 -------------- [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
