On Thu, Mar 30, 2017 at 10:15:07AM +0300, Dmitry Bogatov wrote:
> > > > I'm using socklog and svlogd to manage logs coming in from several
> > > > boxes via
> > > > UDP.
> > > >
> > > > Configuration would be a lot easier if I could have a "hierarchical"
> > > > setup where I have a directory tree for each syslog client and can
> > > > select
> > > > only lines coming from that client in the root of that tree.
> > > >
> > > > For example, assuming I have box1 at 1.2.3.4 and box2 at 2.3.4.5, I'd
> > > > like
> > > > to be able to have the following directory tree:
> > > > [...]
> > >
> > > Unless I am very wrong, it belongs to socklog, not runit.
> >
> > I'm afraid you _are_ wrong -- the request is for new functionality in svlogd
> > (which is part of the runit package), not socklog.
>
> Then I am not sure I properly understand your wishes (sorry, I use
> neither socklog, nor sending logs over UDP). Glance over svlogd(8)
> revealed following:
>
> pprefix
> tells svlogd to prefix each line to be written to the
> log directory, to standard error, or through UDP, with
> prefix.
>
> Isn't it enough to provide sufficent meta-information to be handled on
> accepting side?
Not in itself.
Let me explain.
svlogd currently has the +/- mechanism to select/deselect lines for logging
into a particular directory. It can also log to several directories.
What I would like is a hierarchical filtering arrangement with a matching
directory hierarchy. That is, if the configuration in dirA/config
_deselects_ a line, then that line shouldn't even be considered by the
filters in dirA/dir1/config.
Example:
Let's say I have a log dir called "log", with subdirectories "log/1.1.1.1",
"log/1.2.3.4"; and further "log/1.1.1.1/mail", "log/1.1.1.1/daemon",
"log/1.2.3.4/mail" and so on, and so forth.
Now let's consider the incoming line
1.2.3.4: mail: some message here
I would like the line to be logged into log/1.2.3.4/mail/current, and only
there.
Currently, I can do this by creating the following config files:
log/1.1.1.1/mail/config: -*
log/1.1.1.1/mail/config: +1.1.1.1: mail:*
log/1.1.1.1/daemon/config: -*
log/1.1.1.1/daemon/config: +1.1.1.1: daemon:*
[...]
log/1.2.3.4/mail/config: -*
log/1.2.3.4/mail/config: +1.2.3.4: mail:*
log/1.2.3.4/daemon/config: -*
log/1.2.3.4/daemon/config: +1.2.3.4: daemon:*
[...]
Very repetitive, lots of duplication (ip addresses must be specified
everywhere); if there are hundreds of client IPs, the command line for
svlogd can become unmanageably long.
Instead, I would like to be able to do the following:
log/1.1.1.1/config: -*
log/1.1.1.1/config: +1.1.1.1:*
This configuration would then cause lines that don't match "1.1.1.1:*" to
not even be considered for logging into subdirectories of log/1.1.1.1,
simplifying configuration files there:
log/1.1.1.1/mail/config: -*
log/1.1.1.1/mail/config: +*: mail:*
log/1.1.1.1/daemon/config: -*
log/1.1.1.1/daemon/config: +*: daemon:*
And in a similar vein for 1.2.3.4:
log/1.2.3.4/config: -*
log/1.2.3.4/config: +1.2.3.4:*
Notice how log/1.2.3.4/foo/config is now identical to log/1.1.1.1/foo/config:
log/1.2.3.4/mail/config: -*
log/1.2.3.4/mail/config: +*: mail:*
log/1.2.3.4/daemon/config: -*
log/1.2.3.4/daemon/config: +*: daemon:*
They could even be hardlinked together and always be edited as a unit (in
reality, filtering rules are often more complex than these, so this would
help quite a bit).
I think logging performance could also improve because fewer rules would
have to be matched for each line.
We'd need a way to tell svlogd to handle a directory recursively; e.g. make
the directory setuid, or pass a command line switch, or extend the config
syntax with e.g. "r" to make the current directory the root of a recursively
configured hierarchy.
I realize it's a big change, but it's backwards compatible; I'm hoping
someone will like the idea and implement it. :)
Andras
--
Ha van valami, amit egy keselyu mindennel jobban utal, az az uvegszem.
