On Mon, 19 Dec 2011, Kaushal Shriyan wrote:
On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan
<[email protected]>wrote:
On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <[email protected]> wrote:
Thanks for the quick reply, I have around 200 client hosts which pushes
syslog to a Remote Centralized Rsyslog server. Do i need to use
http://rsyslog.com/doc/ommail.html on all 200 client hosts or can it be
setup only on Remote Centralized Rsyslog server.
It can be setup just on the centralized server, assuming those messages
you are interested in are actually being forwarded to that server.
Thanks Ryan and any further use cases or several examples regarding
$template (*Configuration Directives*) as mentioned in
http://rsyslog.com/doc/ommail.html
Please suggest.
Regards
Kaushal
Hi,
I am referring to http://rsyslog.com/doc/ommail.html to set email or sms
alerts using email-to-sms feature
Basically i am interested in various conditions or strings which can be
captured or trapped and post it to the user
For example "if $msg contains 'hard disk fatal failure' then
:ommail:;mailBody" as per that link
so how would i know what strings i can expect if there is a hardware or
software error in the syslog ?
I mean typical error description for specific problem
Please guide me
It's not clear what you are asking.
Are you asking what error messages could indicate hardware or software
problems in your logs? if so, that is too large a list of errors for
anyone to predict (in part it will depend on what software you are
running)
or are you asking what log messages rsyslog produces if there are errors?
(this is a smaller list, but still hard to define)
as a general statement, just about any log message could potentially
indicate an error of some sort, you have to know the system to know what
it means.
Alerting on every potentially bbad message does not work well in practice
(too many messages have the potential to mean something bad)
rsyslog does have the ability to generate e-mails if you match something,
but that's not really an efficient way to do alerting. You really need to
do a lot more logic on the logs to decide if something is bad (a message
may inddicate a problem only in combination with other mesages, only if it
happens more than X times in Y minutes, only if some other message
_doesn't_ show up within X minutes, etc)
the right answer to finding bad things in the logs is very complex and
involves several tools. It's also something where there is no one True
Answer (TM)
What I like to do is to send the logs to Simple Event Correlator (SEC)
where I can program it to generate alerts on things that it sees.
Tofigure out what I need to alert on, I use the 'artificial ignorance'
method. get all your logs for a day, do some simple filtering to replace
IP addresses, pids, numbers, etc with placeholders and then run the logs
through sort |uniq -c |sort -n and look at your most common logs for the
time period.
for each log message type, decide which category it falls under
1. Something that you want to create a summary report on
this could be a list of what sites accessed a webserver for example
2. Something that is not interesting
but note that the number of times that something 'not interesting
happened' could be interesting, especially if that count changes
significantly
3. Something that you want to alert on (at least potentially)
update your reporting script to filter out the log messages that you have
classified and repeat the process. you will find that you very quickly
classify all the log messages that you have seen, and the report of these
'unknown' messages starts getting rather small. have someone review these
unknown messages each day to catch new things (which may involve creating
a report or otherwise classifying the messages using the same logic)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
