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 @....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
