On Monday, 1 September 2014 at 10:43:34 UTC, Ola Fosheim Grøstad
wrote:
I guess the most robust solution is to use shared memory and
fork, when the child dies you soup up the log and upload it to
a logging-server.
I'm used to a centralized system taking logs on a continuous
basis, with "normal, I'm happy" messages coming through in a
regular interval. When the application dies, it already has had
its messages emitted and sucked up by the collection system, and
if its heartbeat messages aren't seen then people are prompted to
investigate anyway. It's on the main server (e.g. syslog or
LogStash) to handle storage space issues like log rotation.
I am also interested in lazy formatting, meaning you log a
reference to the immutable formatting string and the
parameters, but wait with the formatting until the result is
needed.
log4d does this, it saves the Logger+LogEntry references and only
applies PatternLayouts at the end, BUT it does so with the risk
that additional fields specified in the conversionPattern might
be wrong since they were not generated/evaluated in the context
of the original log call. Thread ID (%t) is the main culprit
(since it is not in LogEntry, PatternLayout has to get it), but
also time between log calls and time since application startup
(%r/%R).
But it sounds like you want std.logger to not apply formatting
even in its infof/errorf/etc functions. That might be a problem
for things like the number of rows in a result set, the current
time, or the remote system hostname. For example, by the time
the logging infrastructure evaluates the number of rows, the
result set is long gone and could throw an exception. I would
argue that this kind of lazy evaluation would be fine if it was
not enabled by default.
