HostingScope gets decomposed and not rendered in {Scope} format about serilog-extensions-logging

[nblumhardt]

That's interesting - thanks for the info.

For file output this makes sense; for other back-ends having properties like RequestId at the top level is a more useful.

There's nothing to prevent us having both: pushing the scope object onto the stack and decomposing it, so you'd get:

2017-02-15 15:28:34 [Information] [{RequestId: "0HL2LV9E249UM", RequestPath: "/"}, "Main", "Main2"] Waiting for user input

(Or something pretty similar, if we use the formatter to convert the value into its string form.)

The down-side would be the extra weight in the Scope payload, duplicating info we've already attached to the event. In some situations I can see this making a pretty substantial impact on event size, it's not unusual to have quite a lot of scope data:

Not all properties above are coming in via BeginScope(), but a lot are (ActionId, ActionName, ...) and I don't know how usable this would be when rendered out into a log file. Serilog.Extensions.Logging.File gets around this by picking a few key properties like RequestId and giving them special treatment.

The current scheme manages to preserve all of the available information fairly efficiently. FWIW, I wrote up the scheme we're using a little while ago - https://nblumhardt.com/2016/11/ilogger-beginscope/ - I don't think there's much more detail in that post than you already have, though.

Thoughts?

[pakrym]

@nblumhardt what if we only add .ToString() representation of scope value to Scope property?

[nblumhardt]

@pakrym I don't think it would make much difference - the text wo

[nblumhardt]

(Keyboard fumble..)

The text would still be long, and the amount of data attached to the event would be similar. That ActionName property for example would still push the rest of the event information far out into the right column.

How does the console provider end up looking when scope gets heavy use? Is it still readable? I haven't had any experience with the built-in providers yet, personally.

[nblumhardt]

Now that it's possible to include {Properties} in Serilog console output templates, I think this is a reasonable alternative to including everything in the rendering of {Scope}; although it's a strong suggestion, I don't think we're likely to tackle this in the near future. Thanks @pakrym !

[wzuqui]

In my case, I had to make a easy.

Here's the code on github:
https://github.com/wzuqui/Serilog.Enrichers.ActionName/blob/master/ActionName.cs