Hello Laurent,
Thanks for responding. Your comments are highly appreciated.
> > 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.
I wish this was better documented in the runit documentation. So, I
could use a ready-made TAI64N processor. But, that is me being lazy, I
will try to put together something on my system and post it for feedback.
> > 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.
Thanks for clearing it up.
> s6-log offers full regex pattern matching, but does not provide network logging.
Ok, thanks for this information.
Thanks again,
Joe
--TiqCXmo5T1hvSQQg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJTz9kLAAoJENvmPC7PRKkIJX8P/ilF7xN5fDPGivhgkC5g3ifW
i9LJTprlTM1o/gIrbiI94TGxFn4mEbH6RL7rtMYGrI4Wx+Xh5fbo+L6STKWRvnqS
ZbMBaJDg3sDn0SaLaJPJx7NYqioODj+CiZCc1wM/+L/17BiT93WgCLr8zI9es0vD
FmgJ3O5v68L6LvTopK7uPS4/JhzJCGkF2+LRj0eNqkkacWUu9dEY2AucpgQjsbV+
J1PbGDEHoHhR7AC4NhIM4rDeAaIS+jku79LzWii0cbiWW1iKG00Y17eRoH70+cnl
c/6QtRoq29JPBf4hXWmlgTY2BMXjqDL9J53eVnPqcnAy51DD2gRae8ywwIk+IJvc
lhsmE+LR1DnmxK+NVIOCVxCZotAwDaYKUPn5R3lnmpUmCSGf6MjzKigWJhoGy1QH
UwFvJ2LI+AbawwoGuFOKxpgHLyDAqNsxvQSEPhxJYmK9N7spxHtgM8Ti7kEDABdt
xHJ8wFbRoUJD3XisLll8rtT5J2OfuQqxKZPItyQmdK5KL3ypcP5lIV3LGQY4g2l6
9Jj2FQrtwH9d1uC9vDVxu7q1AgHzeqzwgtwI5o9EDcb22jDW0KkJXR8uqGn41rb3
dF0RaTrQd//Cux130K23WErqPR2CZPav+EfOU68NomTmAl07TlZ27E1TDE4xHwvF
14P2ULJs9a3ev2GCWTlL
=tqu9
-----END PGP SIGNATURE-----
--TiqCXmo5T1hvSQQg--
Received on Wed Jul 23 2014 - 15:47:23 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:18 UTC