Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 88044 - Tenshi feature request: email rate limiting per log line..
Summary: Tenshi feature request: email rate limiting per log line..
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Tenshi (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: rob holland (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-05 08:58 UTC by Eric Brown
Modified: 2005-07-06 11:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Brown 2005-04-05 08:58:57 UTC
I might be using Tenshi the wrong way, but I have it setup to report/trash stuff that I expect (and which is not critical), and send emails for everything else.  This has mainly helped me determine if a service dies or has some problems.

The problem I have is that some services are really noisy.  Barnyard for example (part of snort), kept dumping errors to the log when it couldn't read the snort log.  The next day I checked my mail, I had almost overstepped by quota.

What I propose is a limiting option for emails sent out per log line.  This way, If barnyard starts dumping critical information every 10 seconds, I could only get say, 10 emails at first, and then perhaps a notification from Tenshi that it will suppress output for that line.. maybe only outputting a summary email every N times it happens afterwards (or perhaps every N units of time in case a service gets REALLY noisy).

I'm not sure if this just means i'm using Tenshi in the wrong way, but if anyone has some ideas to help me correct this behavior, just let me know.





Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Andrea Barisani (RETIRED) gentoo-dev 2005-04-05 11:16:43 UTC
I don't think you really need that feature, here are 3 suggestions on how making things work without that:  - summarize as much as possible, this way messages will be consolidated - don't use [now] in queue specifications, have periodic burts (especially for   the alerts that you know will annoy you) and tune the crontab specifications   accordingly - use the 'set limit' option in order to prevent huge warnings  In my experience on all kind of servers I've found that tuning accordingly the regexp list and the queue timing solves this kind of problems and there's no need of complicating stuff with some thresholding feature.  Please let us know what you think, I'll be happy to assist you in getting a good setup.
Comment 2 Andrea Barisani (RETIRED) gentoo-dev 2005-06-08 06:53:22 UTC
Eric, any thoughts about my comment?
Comment 3 Andrea Barisani (RETIRED) gentoo-dev 2005-06-16 05:41:51 UTC
closing as NEEDINFO for now.
Comment 4 Eric Brown 2005-07-06 11:06:38 UTC
Sorry for taking so long to get back to you.

about your suggestions:

1) summarize as much as possible
I do this, it's fantastic!

2) don't use [now]
I still need to use [now] mostly because I don't know what output to expect from
certain programs (also the kernel has very diverse output).  Mostly though,
[now] is my catchall because if something out of the ordinary happens, I really
want to know.

3) set limit
I haven't set this yet because the length of the emails hasn't been a problem
yet, just the frequency.


Recently I just haven't had any more unexpectedly noisy daemons, so I haven't
done anything to combat this problem.  I suppose I could have an hourly queue
for the catchall with a limit set, but it might hamper my response time if there
was a real emergency.

Anyway, thanks for the ideas.