Normaly the first cycle (using the below URLs!!) it will set the recordnumber and the next cycle it will check from the point on.
Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, July 30, 2004 3:50 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions In reply to my own question installed latest salive and beta comchecks below. Every check cycle I get an entire list of errors in my application and system logs and the checks of these logs take about 5 minutes each every cycle. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, July 30, 2004 8:37 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions After installing the first check cycle reports all results (not those since the last alert). Is this by design then future restarts will remember the last entry? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Wednesday, July 28, 2004 3:39 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Any feedback? Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Tuesday, July 20, 2004 1:13 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Download links http://beta.woodstone.nu/soft/salive4.exe http://beta.woodstone.nu/soft/setup_eventlogcom.exe http://beta.woodstone.nu/soft/setupSMTP2POP3com.EXE Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Friday, July 09, 2004 10:26 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions I've problably found a way to handle it. BUT this will have to be tested by several people before it can realy be released. This change affects Servers Alive and the COM checks, to start with the eventlog and the SMTP2POP3 com check. The others currently don't have any data that changes with the cycles. BUT I don't want to start a beta test for it before end of next week and this because I'll be on holiday from Sunday until Wednesday evening. So after that I can start with some beta testers for it. So if you want to beta test this let me know :-) Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Friday, July 09, 2004 9:03 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Thanks for the nice words :-) The problem that is pointed out for the eventlog check is basicly a problem for each check were not each cycle is exactly the same. With the eventlog the "only" change is were we start to look, for the SMTP2POP3 COM based addon it's knowing if the next thing to do is SMTP or POP3. I'm aware that in that case we do have a problem. And as Michael points it out correctly I don't want to rewrite it just to fix, I have to come up with a long term solution and that's not something I will be able to do in 2 seconds. I have to think this one over to see how to handle this "problem". Give me some time on this and I'll come up with 'something' that should be able to fix this correctly. Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael D. Shook Sent: Friday, July 09, 2004 4:50 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Just to point out the logical (and VERY annoying and unrealistic) end of this particular line of thought: SA would need to have a SEPARATE host file for EACH check. This is the only way SA could easily track changes to a single host's info without having to re-calculate and write the entire host file. This would, however, be a real pain in the ^$* to use and program. It would essentially force the creation of a new product from a coding point of view. Because SA has an EXTREMELY rich assortment of user options (I mean really, I've seen fortune 100 companies use less capable accounting software) there have to be compromises on how those user options are stored and modified. Clearly a flat database would have to have upwards of 100 fields (most empty) to handle all of the options. The method Dirk & Co. chose is vastly more compact and easier to handle. But there are trade offs. This is one reason why SA's competition doesn't have as many options or as much flexibility, their db structure can't handle it. While I don't always understand why Dirk can't or won't implement my pet need, I am learning that he is VERY willing to stretch what he has in SA to it's limit. He has almost always been able to come up with a compromise or work around. Since I've been using SA I keep seeing these same argument progressions (and I admit that I've been the cause of a few) where user makes a request, Dirk denies and offers other option, User re-explains, Dirk denies and points out other option again, User 2 says they want it, Dirk re-explains, and offers other options...... I think that once we have clearly established that Dirk understands our request, that he'll do what he can, but he's not going to re-write the entire code base just to "fix" one issue. Sorry for the diatribe, but it just seems like all we ever have for Dirk is requests to fix things that we consider broken. Personally, I think that SA is the only piece of software I run across that has this level of dedication to the end user and to the ever changing world we work in. Even if Dirk never added another feature, changes in the way networks are used and designed would force him to keep updating and adjusting. Three cheers for a wonderful product and the best user experience I have ever (and will probably ever) known. Michael Shook Technical Analyst Saddle Creek Corporation 723 Joe Tamplin Industrial Blvd Macon GA 31217 478 742 8740 ext. 105 (work) 478 256 9318 (mobile) 478 742 7917 (fax) [EMAIL PROTECTED] http://www.saddlecrk.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx Sent: Friday, July 09, 2004 9:59 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions That can already be done Dirk. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, July 09, 2004 3:36 PM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions Why not have servers alive write the new number then after every cycle? Forcing the users to save the file to maintain that cached number is an issue. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Bradshaw Sent: Friday, July 09, 2004 8:05 AM To: [EMAIL PROTECTED] Subject: RE: [SA-list] Event Log COM check questions I actually prefer Dirk's method. If I were rewriting that script I'd cache the number too. I'd suggest having the COM check just disregard the cached ID number on first check, and just start reading at the end of the log. Basically, ignore any down conditions BEFORE the start of checking. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, Andy > Sent: Friday, July 09, 2004 3: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 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004 -------------- [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 -------------- [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 ------------------------- [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
