Syntrony.Logging 1.1.0

Syntrony.Logging

Unified logging and telemetry package for Syntrony services: a single UseLogging entry point to configure the sink (Log4Net today, Serilog planned) and backend-agnostic OpenTelemetry-based telemetry. No sink is pulled in unless its own package is referenced and its Use* extension is called.

builder.Services.AddSyntrony(options =>
{
    options.UseLogging(log => log
        .SetMinimumLevel(LogLevel.Information)
        .WithEnrichment(p => p["service.name"] = "my-service")
        .UseLog4Net()
        .UseOpenTelemetry(otel =>
        {
            otel.ServiceName = "my-service";
            otel.Endpoint    = builder.Configuration["Telemetry:OtlpEndpoint"];
        }));
});

What's in this package

• UseLogging(this SyntronyOptions, Action<ISyntronyLoggingBuilder>? configure = null) — the entry point. Calling it more than once on the same SyntronyOptions reuses the same builder, so the calls compose instead of replacing each other's configuration. Calling it without a sink keeps the host's own providers (console, debug, event source); it does still install the default filter rules described in Default output.
• ISyntronyLoggingBuilder — what sink packages (Syntrony.Logging.Log4Net, Syntrony.Logging.OpenTelemetry) build their Use* extension on top of:
  • Logging (ILoggingBuilder) / Services (IServiceCollection) — the host's logging builder and DI container, for anything a sink needs directly.
  • SetMinimumLevel(LogLevel) — no-ops if the host already has an explicit Logging:LogLevel configuration; this package never overrides what the host already set.
  • WithEnrichment(Action<IDictionary<string, object>>) — accumulates properties a sink applies to every log entry (service name, version, environment). Callbacks run in registration order.
  • RegisterStructuredSink(string) — called by a structured sink (UseLog4Net, eventually UseSerilog) to claim the sink slot. Throws if a different sink already claimed it — they're mutually exclusive, pick one. The first time it is called it removes the host's default providers (console, debug, event source, event log), so every entry is written once, by the sink. Other packages' providers are left alone. Telemetry sinks (UseOpenTelemetry) don't call this; they compose with whichever structured sink is active.
• GetRegisteredInstance<T>() (internal helper, ServiceCollectionInstanceExtensions) — resolves a singleton the host already registered as an instance (IConfiguration, IHostEnvironment) without building the container, since sink packages need it at registration time, before the app has a built IServiceProvider.

Default output

UseLogging installs these filter rules. They sit first in the rule list, so any rule the host (Logging:LogLevel in appsettings.json) or your code (AddFilter) sets for the same category wins.

The longest matching category wins, so to silence the SQL you need the category itself:

{ "Logging": { "LogLevel": { "Microsoft.EntityFrameworkCore.Database.Command": "Warning" } } }

Microsoft.EntityFrameworkCore: Warning is not enough: it is shorter than the default for the SQL category. Parameter values are printed as @p0='?'; they only appear if you call EnableSensitiveDataLogging(), which you should not do in production.

One entry, one line

With UseLog4Net() the host's console provider is removed, so each entry is written once, in the log4net layout. If you also want the console provider, add it after the sink:

options.UseLogging(log =>
{
    log.UseLog4Net();
    log.Logging.AddConsole();   // after UseLog4Net — before it, it would be removed
});

Settings keyed by provider, such as Logging:Console:LogLevel, no longer apply once the console provider is gone.

No IHostedService involved: the only asynchronous piece — initializing the core's LogHelper once the container is built — runs through SyntronyOptions.AddInitializer, the same deferred-initialization pipeline every other Syntrony package uses.