Take advantage of serilog's structured logging

[droyad]

It would be nice if, when using the serilog sink, it destructured things like the message objects. I had a bit of a play with trying it in the SerilogLogger or within Serilog, however it didn't seem right.

I best solution I can think of is some way of specifying a different message format for serilog than for the console logger: 1) Using a key that then looks it up out of a dictionary of formats depending on the logger 2) In the console logger, reformatting the serilog style format into a string.format format: regex replace "{@?[^}]}"

[DamianMac]

What if we had an internal "simple logger" and "deep logger", with the internals calling deep logger with an object and it deconstructing it and passing to the simple logger.

Then as a logging implementor you could choose which one you use....

Just pondering out loud here... thoughts ? @uglybugger

[uglybugger]

Hmm... sounds like we'd be taking an implicit dependency on Serilog's format strings without an explicit reference to it. We may actually be better off taking an explicit dependency on Serilog and gracefully degrading to a string.Format(...) logger via a Serilog sink.

Still mulling over this one...

[DamianMac]

I'm going to say it again.......

I don't want to take an explicit dependency on Serilog.

On Wed, Dec 18, 2013 at 3:03 PM, uglybugger notifications@github.comwrote:

Hmm... sounds like we'd be taking an implicit dependency on Serilog's format strings without an explicit reference to it. We may actually be better off taking an explicit dependency on Serilog and gracefully degrading to a string.Format(...) logger via a Serilog sink.

Still mulling over this one...

— Reply to this email directly or view it on GitHubhttps://github.com/DamianMac/Nimbus/issues/23#issuecomment-30817437 .

[uglybugger]

Neither do I, hence "Still mulling over this one" - there must be a better way to keep it implementation-agnostic but also expose better-structured log messages.

I really don't want to be writing a Serilog-style parser or anything that strips out Serilog format strings and downsamples them to standard string.Format(...) ones - that's too far removed from the point of the project.

Hmm...

[droyad]

What about a wrapper. I'm using this at the moment: https://gist.github.com/droyad/6649ce7377cfe57cef0f

[uglybugger]

Hmm... That wrapper looks like it takes a low-priority concern and wraps the entire bus in it.

I wonder if we're solving the wrong problem here. If we want structured logging of what the bus itself is doing, I think we have enough. If the real problem we're solving is that we want structured logging of all the messages crossing the bus then we're probably better off implementing audit queues/topics sooner rather than later.

Thoughts?

[uglybugger]

Closed in favour of #39. We're probably always going to want more internal logging but IMO it's better to consume the event stream if we want to have structured logging of the messages themselves - this way, we get access to the complete message content in its original form and can do with it what we wish.