On Mon, 19 Dec 2011, Kaushal Shriyan wrote: > On Mon, Dec 19, 2011 at 5:18 AM, Kaushal Shriyan
>> On Mon, Dec 19, 2011 at 4:55 AM, Ryan Kelly <email@example.com> 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
>> Please suggest.
> 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
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
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
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
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
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)
rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/