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
like.
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.
--
Laurent
Received on Tue Jul 22 2014 - 23:50:44 UTC