Tim, note that the timeout window in the PairWithWindow rule is currently set to just 15 seconds -- in other words, if relevant log event has not seen during 15 seconds after the 'service_5_minute' event was generated, an alarm is raised. Although the 'service_5_minute' event is generated at 2nd, 7th, 12th, etc. minute of every hour, it's the timeout window that actually sets the length of the missing event check. I would rewrite the rule as follows (it's a quote from one of my previous posts to the list):
> Then the ruleset might look like this: > > type=Calendar > time=* * * * * > desc=CHECK FOR RADIUS MESSAGES > action=event %s > > type=PairWithWindow > ptype=SubStr > pattern=CHECK FOR RADIUS MESSAGES > desc=radius daemon has stopped working! > action=logonly %s > ptype2=RegExp > pattern2=radius\[\d+\]: > desc2=radius daemon is OK > action2=none > window=120 > > This ruleset checks for the presence of Radius > messages in the log once a minute, and if no messages > have been seen in 2 minutes, an alert is logged. You can easily modify the second rule for your task by changing the 'window' to 300 and 'pattern2' to match the messages that indicate service activity. Also note that by setting the 'time' parameter in the first rule to every minute, the service check is done by every minute -- therefore the service failure (no messages during 5 minutes) will be reported to you with a 60 second delay at most. Note that if you configure the Calendar rule to fire after 5 minute intervals and your service stops working, you could get an alarm 10 minutes later (no messages during 5 minutes + max 5 minute check delay). hope this helps! risto Tim Peiffer wrote: > I have a missing events problem that I am trying to detect and I can't > seem to resolve the reliability problem. I want to run a calendar > every 5 minutes to detect whether I have an outage. I have logs that > arrive mostly regular.. 1 transaction per minute. The regularity of the > logs are dependent upon success of many things such as collector > activity, SQL server activity, etc. as a result, the activity to remove > the 5 minute context is not reliably kicking it off. What do I do to > make the dectection a little more loose? I think that the answer is > something like make the calendar event expiration time longer.. > action=event 60 context_name > becomes > action=event 120 context_name > The configuration example I am working on is included below. > > Unrelated feature request: I would like a feature to specify a regular > repeating calendar event ala the Vixie cron style.. > every 5 minutes > time=0,5,10,15,20,25,30,35,40,45,50,55 * * * * > becomes: > time=60/12 * * * * > > every 1 minute > time=0,1,2,3,4,5,6,7,8,9,10,11,......58,59 * * * * > becomes: > time=60/60 * * * * > > Please advise, > Tim Peiffer > Networking and Telecommunications Services > University of Minnesota/NorthernLights GigaPOP > > # ----- detect missing events ----- > # missing events (no events) indicates a service failure > # When no activity within 5 minutes, declare down. > # Ref: Lisa2004 paper by John Rouillard > > # rule 1: report a missing event, or log successful detection > type=PairWithWindow > desc=%Hostname MACTrack Service failure report > ptype=regexp > pattern=service_5_minute > action=logonly %Hostname MACTrack Service run failure (missing events) > detected at %t > ptype2=regexp2 > pattern2=(\S+) MACdatabase.pl \S+ Processed > NET.(\d+)\.0?(\d+):0?(\d+):0?(\d+) at (\d+)[EMAIL > PROTECTED](\d+):0?(\d+):0?(\d+) > TUARN = \(\d+\/\d+\/\d+\/\d+\/(\d+)\) > desc2=found $1 mactrack service log trace > continue2=TakeNext > action2=logonly > window=15 > > # rule 2: trigger the detection operation at 60min/12 +120 sec > type=calendar > desc = start searching for service traces at 60min/12 + 2 min > time=0,5,10,15,20,25,30,35,40,45,50,55 * * * * > action=event 120 service_5_minute > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Simple-evcorr-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
