Hi Dirk,
How is the interface for the COM checks designed? I mean what info is provided to a check from ServersAlive (if any) and what info does ServersAlive accept in return? Does the external check only have the parameters established at the time the check is established? In other words, what are the INPUTS and OUTPUTS of any given check from a SA perspective (not from the addon perspective)? Maybe armed with that information we can better understand how to make suggestions.
Nate
From: "Dirk Bulinckx" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: RE: [SA-list] Event Log COM check questions Date: Fri, 9 Jul 2004 21:02:31 +0200
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
