3 ms·
No, it's just a plain syslogd dating back to the 4.2 days. It aggregates at 30, 120, and 600 second intervals according to the source. Within that threshold I
by inferiorhuman 3y ago
No, it's just a plain syslogd dating back to the 4.2 days. It aggregates at 30, 120, and 600 second intervals according to the source. Within that threshold I wouldn't care too much. If I really needed timestamps with more than thirty second precision I probably wouldn't be using syslogd.
In any new-ish production system I'd probably want to use anything other than syslogd anyways.
https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/syslogd/syslogd.c https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/sy...
- TeMPOraL 3y agoThat's... good to know. I never realized anyone is doing something like this, ever. It breaks my trust in software logs in general - I'll be sure from now on to understand how any given program handles logging, before making assumptions relevant to troubleshooting.
- kaliszad 3y agoIn many cases, logs are asynchronous so depending on many factors among which are utilization of the host, you might get them with a delay and the ordering of events might not make sense because of that when read from the logs. If you need that precision you can surely engineer/ configure your system for that.
- TeMPOraL 3y agoIf I'm running my own distributed system for some business reasons, sure. If I'm dealing with equipment failures, bugs in third-party software, or other such random tech bullshit, as an individual or a team, then I don't know in advance when and what precision I'll need.
- kaliszad 3y agoIn a reasonable system, you might be able to change some function in one place, perhaps even in the running system and get the precision or detail you need. You might take out the big guns like e.g. dynamic tracing using BPF to attach probes at the right places.