Re: svlog processing

From: Laurent Bercot <>
Date: Wed, 23 Jul 2014 00:50:44 +0100

On 22/07/2014 23:17, Joe M wrote:
> I find svlogd log files hard to read as the lines have a UTC timestamp(-tt)
> and the filenames with _at_....s are hard to understand. I read that
> svlog files are meant to be processed by a post-processor.
> I use logrotate for other log files.
> Just wanted to check if anyone could please share some insight on how
> they manage/post-process svlogd generated logs.

  This is all policy, so my answer is by no means authoritative, YMMV, etc.

  The logging directory, since it's automatically rotated, is a good place to
store logs if you are limited by storage space, but a bad place to store them
if you're not and your policy is to keep all logs for a certain amount of time.
In that case, it's a good idea to have a processor that moves all your archived
log files to your bigger storage space every N rotations (you can count N with
the state file). That processor can rename the archive files to any format you
  The TAI64N format for the archive file name is a way of easily keeping track of
all the archive files in the logging directory without parsing human-readable
dates: it's practical for machine processing. You can take advantage of this by
handling them via automation all the way to the point where they need to be read
by a human.

> In the runit documentation, I saw multilog and svlogd both being
> used. When do you use multilog over svlogd?

  I think the part of the documentation where multilog is mentioned, i.e. the
runit index page, predates the addition of svlogd to the runit package. I'm not
aware of a situation where multilog is better than svlogd.
  s6-log offers full regex pattern matching, but does not provide network logging.

Received on Tue Jul 22 2014 - 23:50:44 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC