Voting: std.logger

[via Digitalmars-d]

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.