[syslog-ng] get destination(s) based on log facility and severity

Gergely Nagy algernon at balabit.hu
Wed Jun 8 14:51:25 CEST 2011


Dejan Muhamedagic <dejan at suse.de> writes:

>> This basically splits the messages by host, and keeps the last 3 days
>> worth of logs. Depending on where the message came from, and the current
>> date, this can go to any number of different files, and there's no way
>> to tell, until I know the message and the date.
>
> Didn't even know that this was possible. BTW, SLE11SP1 runs 2.0.9.

That's some ancient version there :)

>> It's just that the
>> information you want to extract cannot be easily extracted, since it can
>> depend on a lot of things, and vary between messages - or even vary with
>> time, as I've shown above.
>> 
>> > Would you consider such an extension? Alternatively, one could build a
>> > new binary for just this purpose which would obviously include
>> > configuration parsing. Don't know which approach of the two is less
>> > painful.
>> 
>> The least painful way would be to rethink you setup, in my opinion. It
>> sounds very awkward to me, and there _must_ be a less painful way to
>> accomplish what you wish.
>
> The setup is not mine :) It depends mainly on the distribution.
> SUSE usually sends everything to /var/log/messages, Debian (I
> think) to /var/log/syslog or .../daemon, and then there are
> shops with /var/log/ha-log. I think that these are the most
> common configurations. But nothing is stopping them to devise
> their own and it would be difficult to enforce unified logging
> configuration (I think actually impossible).

Well, if you can't enforce centralized logging, then there's not much
one can do.

If you could set up a system where the various hosts are free to do
whatever they want with their logs, as long as they forward a copy to a
central server too, then it would be easy to handle.

If you can't do that, then grepping around is your best bet. I'd try to
persuade them that this way of operation doesn't scale in the long run =)

>> >> It may be possible to add some debugging stuff to syslog-ng, that would
>> >> echo the information you need, but it's not currently present.
>> >> 
>> >> I also fail to see why this would be useful, but that might just be my
>> >> lack of imagination O:)
>> >
>> > This is for a reporting tool for clusters. It collects all the
>> > relevant information from all cluster members and that includes
>> > excerpts from log files. People use all kinds of syslog setups so
>> > the tool needs to figure out which log file is relevant.
>> 
>> Wouldn't it be possible to collect the logs with a central syslog-ng,
>> and tag them appropriately, based on source, and then filter them to the
>> appropriate files, based on that tag?
>
> See above. Whatever the user does, we should make best effort to
> find the file where the messages end. Of course, if the setup is
> really awkward, then no cigar, but we have to support
> "reasonable" configurations (for some values of reasonable :)

Well, if users want their logs to be collected, they should forward a
copy to a central server, imo. Whatever they do with the log message
afterwards, doesn't matter. Just send a copy.

With most syslog daemons, that's only a few lines, and even legacy
syslogd can do that, even on such esoteric systems as Solaris and AIX.

-- 
|8]


More information about the syslog-ng mailing list