Take advantage of serilog's structured logging about nimbus HOT 7 CLOSED

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

from nimbus.

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...

from nimbus.

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 [email protected]:

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
.

from nimbus.

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...

from nimbus.

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

from nimbus.

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?

from nimbus.

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.

from nimbus.