Transformations about serilog-sinks-elasticsearch

[refactorthis]

Thanks very much Nick, you validated what I was thinking. Looks like I'll have to start simplifying some of these log statements.

[nblumhardt]

Hi Brent,

I can't answer the ELK questions, but regarding the first part of 1), no, that's not really the design intention for Serilog.

It can be done, but the goal for Serilog's object graph serialization is to improve the machine readability of log events with interesting data that you'd otherwise normally format into unstructured text, not to capture large/complex object graphs.

As a rule of thumb - if you'd bother converting the data to some string format for inclusion in a traditional text log, then Serilog should handle recording that same data in structured form.

So, say, if the code records a user login and we want to log the username as well as the internal id of the user, then logging a structured User property with Name and Id seems fine to me. Likewise if we're starting up and want to log the list of configuration servers we're about to probe, then Servers structured as s list of hostnames is great. In these cases I'd historically have written the same data out to the log just by formatting it into the message, and Serilog makes the event more useful by preserving the structure.

As a counterexample, I haven't worked with many systems where it's been desirable log e.g. entire messages from a service bus, or entire web requests from clients, except in perhaps the most extreme, all-else-has-failed debugging scenario. Pumping these kinds of things out into a text log would be pretty commonly recognised as a questionable practice I think. Serilog's not much different here - the purpose of the log and the natural limitations WRT event size and so-on remain, even though the format is more modern.

Hope I've understood your question correctly and not just hit you with a wall of text :-O ... hope this helps! :-)

Nick