Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/serilog/serilog/releases below:

Releases · serilog/serilog · GitHub

Releases · serilog/serilog

• #2108 - failure listeners and fallback sinks (@nblumhardt)
• #2120 - add BatchingOptions.RetryTimeLimit and update retry scheduling algorithm (@nblumhardt)

IBatchedLogEventSink batch retry scheduling has changed in this version. The default configuration still tries failed batches for approximately ten minutes, but the BufferingTimeLimit no longer implicitly causes the retry time to be extended or reduced. If you need a specific retry time, set BatchingOptions.RetryTimeLimit, which reliably controls retry time.

• #2094 - remove boxing and string allocations in output template formatting (@epeshk)
• #2103 - don't capture properties with private get accessors (@nblumhardt)
• #2095 - remove junk file (@Numpsy)
• #2116 - fall back to IDisposable in Log.CloseAndFlushAsync() when the target logger is not IAsyncDisposable (@nblumhardt)

• #2090 — when capturing structured values, reuse HashSet instances, reduce LINQ usage, avoid reallocating string[] to improve performance and cut GC pressure (@nblumhardt)
• #2089 - allow capturing of non-anonymous structured values when trimming (@nblumhardt)
• #2083 - use Major.Minor.0.0 assembly versioning (@nblumhardt)

If you're deploying to .NET Framework, note that Serilog's assembly version number has been unpinned from the long-running historical 2.0.0 default, and now matches the package version precisely. If you encounter issues, ensure your build is generating valid assembly binding redirects.

Sinks that need batching functionality can now be easily written, without any additional package dependencies, by implementing IBatchedLogEventSink:

class MyBatchedSink: IBatchedLogEventSink
{
    public Task EmitBatchAsync(IReadOnlyCollection<LogEvent> batch)
    {
        // Send a batch of log events...
    }
}

Batched sinks can be added using WriteTo.Sink(IBatchedLogEventSink, ...) - they're given first-class consideration just like regular un-batched sinks.

The built-in batching implementation is based on System.Threading.Channels and draws on the original Serilog.Sinks.PeriodicBatching package (now in maintenance-mode), to provide a full-featured, efficient, async-native batching implementation.

By setting an experimental AppContext switch, message templates can be used to capture dotted names, which are required when using some logging schemas.

AppContext.SetSwitch("Serilog.Parsing.MessageTemplateParser.AcceptDottedPropertyNames", true);

Log.Information("Running as {user.name}", Environment.UserName);
// Captures {"user.name": "nblumhardt"}

While currently experimental and unsupported, this flag is intended to help the ecosystem evaluate and prepare for dotted name support in a future Serilog release.

• #2015 — breaking unpin assembly version (@nblumhardt)
• #2045 — breaking use case-insensitive matching for level overrides (@tillig)
• #2051 — breaking recognize UtcTimestamp as a built-in token in output templates (@MatthewHays)
• #1979 — add tests for ReusableStringWriter (@nblumhardt)
• #2016 — update TFMs (@nblumhardt, @bartelink)
• #2018 — add LogEvent.UnstableAssembleFromParts() (@nblumhardt)
• #2044 — build updates for compatibility (@tillig)
• #2027 — improve trimming annotations, compatibility switch for compiler-generated type support (@agocke)
• #2055 — introduce IBatchedLogEventSink and WriteTo.Sink(IBatchedLogEventSink) (@nblumhardt)
• #2060 — introduce LoggerSinkConfiguration.CreateSink() and redesign .Wrap() (@nblumhardt, @bartelink)
• #2063 — improve MessageTemplateParser performance, switch to allow . in captured property names (@nblumhardt)
• #2064 — make message template alignment parsing match spec (@Insomniak47)
• #2065 — allow any character except } in message template format specifiers (@Insomniak47)

• #1935 - remove CHANGES.md (@sungam3r)
• #1936, #1922 - README.md updates (@nblumhardt)
• #1942 - remove redundant GetTypeInfo() calls (@SimonCropp)
• #1947 - message template caching performance improvements (@epeshk)
• #1948 - reduce allocations in Logger.Write() (@epeshk)
• #1955 breaking - collect and propagate Activity.Current.TraceId and SpanId automatically in Logger.Write() (@nblumhardt)
• #1959 - breaking - property value converter optimizations (@epeshk)
• #1964 - don't cache reusable string writers with large buffer sizes (@Jakimar)
• #1969 - README.md updates (@bartelink)
• #1971 - drop test coverage for unsupported .NET Core versions (@bartelink)

This release adds two new first-class properties to LogEvent: TraceId and SpanId. These are set automatically in Logger.Write() to the corresponding property values from System.Diagnostics.Activity.Current.

The major benefit of this change is that sinks, once updated, can reliably propagate trace and span ids through to back-ends that support them (in much the same way that first-class timestamps, messages, levels, and exceptions are used today).

The sinks maintained under serilog/serilog, along with formatting helpers such as Serilog.Formatting.Compact and Serilog.Expressions, are already compatible with this change or have pending releases that add compatibility.

On .NET Core 2.1 and 3.0, projects targeting Serilog 3.1+ will fail to build, with:

/project/packages/system.runtime.compilerservices.unsafe/6.0.0/buildTransitive/netcoreapp2.0
/System.Runtime.CompilerServices.Unsafe.targets(4,5): error : System.Runtime.CompilerServices.Unsafe
doesn't support netcoreapp2.1. Consider updating your TargetFramework to netcoreapp3.1 or later.

Affected consumers should continue to use Serilog 3.0 or earlier. See #1983 for a discussion of this issue.

Trace and span id collection includes support for {TraceId} and {SpanId} placeholders in output templates (commonly used when formatting text log files). Where previously these names resolved to user-defined properties, they now resolve to the built-in LogEvent.TraceId and LogEvent.SpanId values, respectively.

Impact is expected to be low/zero, because the trace and span id values in any user-added properties are almost certainly identical to the built-in ones.

These integer types were previously logged as structures. They're now correctly logged as scalars.

You can’t perform that action at this time.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4