On Tuesday, 2 September 2014 at 06:24:45 UTC, Kevin Lamonte wrote:
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.
Yes, I think we are discussing many different things at the same
time here and it would be a good idea to sort out the different
use cases since that affects functionality. I have not thought
about heartbeats/keep-alive etc as logging, but it is reasonable
to view them as such.
I see a difference between signalling state, tracing execution
and logging state. I guess one roughly can say that:
- signalling is for coordination of subsystems
- logging state is for tracking effects on the database
- tracing is for detecting logic failure after a crash
?
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).
Sounds interesting. I'll have a look at log4d later. But it is
not fully typesafe then? The way I see it you should log a tuple
of values and a reference to a type-safe formatting expression,
but only apply the formatting expression when you need to so you
don't burden the performance thread with unnecessary work.
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 think you should log the values as a tuple, but not do the
string-conversion, but it is more important for tracing execution
than for logging. I guess formatting high level info/error is
acceptable, but for tracing I am only interested in very terse
value/type info along with an indicator of context.
Performance and trouble-free type safe logging is much more
important than "nice formatting" IMO. Traced execution will
primarily be used for log analysis after a crash. You can use
this on game clients, game servers, web servers etc…
E.g.:
log configuration + trace last 50000 events -> crash -> compress
and upload for analysis.
