Any plans to support subloggers?

[furyd]

Hi, I've spotted that using ".Destructure.UsingAttributes()" on sublogger LoggerConfigurations doesn't work, just on the top level LoggerConfiguration. Are there any plans to change that?

My use case is that I'm splitting the logs into a 'logger' and an 'auditor', the logger needing to have all personally identifiable data removed, whilst retaining it for audit purposes.

[sungam3r]

Can you provide an example ?

[furyd]

Hi @sungam3r , thank you for responding:

code:

builder.Host.UseSerilog((hostBuilderContext, loggerConfiguration) =>
        {
            loggerConfiguration
                .WriteTo.Logger(x =>
                {
                    x.WriteTo.ApplicationInsights("{{guid1}}", new Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter())
                        .Destructure.UsingAttributes();
                })
                .WriteTo.Logger(x =>
                {
                    x.WriteTo.ApplicationInsights("{{guid2}}", new Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter());
                })
                ;
        }
    );

Expected behaviour: a model property, when decorated with [LogMasked(PreserveLength = true)], will have its value replaced with *s equal to its length in the first App Insights, but not in the second.

Actual behaviour: unmasked property value logged in both AI instances

Whereas:

code:

builder.Host.UseSerilog((hostBuilderContext, loggerConfiguration) =>
        {
            loggerConfiguration
                .WriteTo.Logger(x =>
                {
                    x.WriteTo.ApplicationInsights("{{guid1}}", new Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter());
                })
                .WriteTo.Logger(x =>
                {
                    x.WriteTo.ApplicationInsights("{{guid2}}", new Serilog.Sinks.ApplicationInsights.Sinks.ApplicationInsights.TelemetryConverters.TraceTelemetryConverter());
                })
                .Destructure.UsingAttributes()
                ;
        }
    );

Expected behaviour: a model property, when decorated with [LogMasked(PreserveLength = true)], will have its value replaced with *s equal to its length in both AI instances.

Actual behaviour: As expected

As I said in my initial one, I'm looking to remove PII in the logger (as devs will use them for debugging) but retain it in the audit log (where devs may not tread) for legal and regulatory purposes.

[sungam3r]

Well, this behavior is by design (Serilog itself). See Write method. LogEvent is created first by message processor. Message processor calls all configured destructuring policies undercover and a lot of other stuff to build LogEvent. Only after that this event object is dispathed down to the loggers pipeline, I mean to the sinks. Sublogger is implemented as SecondarySink. SecondarySink just passes LogEvent further.

Ping @nblumhardt . I think that one/both suggestions may interest you:

1. Note in the Subloggers documentation that subloggers don't support destructuring policies.
2. Throw exception from LoggerSinkConfiguration.Logger methods if logger has any policies though I think it's too hard to implement in the current design and of course it will be a breaking change.

[nblumhardt]

@sungam3r 👍 to both suggestions, although for (2) we tend not to throw when Serilog.Settings.Configuration is misconfigured 🤔 (JSON configuration problems are considered a "runtime" failure, while any misconfiguration via the C# API should be picked up at development time, so throwing is reasonable there)... Probably a 3.0 change, in any case.

[furyd]

Thanks for the explanation @sungam3r , I'll have to figure out another way to achieve this - always many ways around a problem! 😁

[sungam3r]

@nblumhardt How can I edit wiki page? I want to add

Note that destructuring policies will not have an effect if they are specified inside Logger extension since sub-loggers work with already created LogEvent.