Open CodeBlanch opened 2 years ago
@pdonovan Yes sorry about the internals. Some of the stuff the extensions rely on is still experimental in the OTel spec so we can't make it public yet. As far as release date, I don't have an exact answer for you but it will be soon. Defer to @cijothomas but I think we were talking about releasing it once we get to beta for the next release.
If you just want to evaluate it, there are nightly packages on MyGet you can take for a spin.
In your NuGet.config do [something like] this...
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="MyGet" value="https://www.myget.org/F/opentelemetry/api/v3/index.json" />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
[Usually I have to restart VS to get the tooling to update.]
Once you have that source added you should be able to find the package there:
If you do get it up and running, I am very interested in any feedback. Does this package meet your needs? Currently we don't fully support Serilog destructuring of complex types into OTel logs, is that an important feature for you?
Regd. release - as discussed in yesterdays SIG meeting, we plan to include the Serilog/EventSource in the next release. ~1-2 weeks.
We heavily make use of both Serilog and NLog. Any plan to add NLog support?
If not, will the internals be made public in the next release (~1-2 weeks)? That way we can at least create our own NLog Targets.
The LogEmitter spec is not stable. And the SDK is expected to have next stable release by Nov 1st week. We'd definitely be making the LogEmitter parts public eventually, but this is likely after the Nov stable release, though this is not a fixed plan, and could change (move earlier/later).
Part of the process to get LogEmitter API stable in the spec is for different languages to try and implement it and gather feedback. So think of this Serilog package as part of that effort 😄 There is a different log API also being worked on so LogEmitter could even go away in which case we'll use the other thing.
I do expect NLog and others to come. I don't have plans to do it personally at the moment but I can down the road or anyone can contribute it once things go stable/public.
If you do get it up and running, I am very interested in any feedback. Does this package meet your needs? Currently we don't fully support Serilog destructuring of complex types into OTel logs, is that an important feature for you?
I'm a bit tied up with other work now, but will definitely try out the MyGet package early next month. Edit: No, we don't use Serilog's structured logging so it won't bother us.
Some initial feedback...
We do all of our Serilog configuration in appsettings.json, including which sinks to make use of. This isn't possible with the current OpenTelemetrySerilogExtensions.OpenTelemetry()
method as it expects to be passed an instance of OpenTelemetryLoggerProvider.
Given I had to register a singleton of OpenTelemetryLoggerProvider in our services collection to solve another issue (DRY), it would be handy if there was a way for the Serilog extension to be added purely through configuration, and to look in services for an OpenTelemetryLoggerProvider to use.
@CodeBlanch Any updates on when this will be available? I was using the builds on myget, but the ones that has the support for Serilog seem to have "aged out" and are no longer available. I had to take our local copies and move them to a private nuget feed.
I see that milestone 1.6 has talk of logging changes? I hope that it's not waiting until then - there are 684M downloads of Serilog, that's a lot of projects that can't easily adopt Otel wholesale without re-writing their logging code to remove Serilog!
@CodeBlanch lets check and make sure to get a preview release to nuget.org itself, if feasible, without waiting for 1.6 season begins.
Is there any reference with Serilog team itself? Their sink is marked stable ( in the readme ) https://github.com/serilog/serilog-sinks-opentelemetry
If possible, maybe these two efforts can be consolidated. cc @nblumhardt
Thanks for the ping @cecilphillip!
The goal driving Serilog.Sinks.OpenTelemetry is to stay largely dependency-free and implement the protocol direcly. This has a different set of trade-offs to the sink being developed here, which is a thin wrapper over the OpenTelemetry SDK.
Neither project involves a massive amount of code, so there's probably more to lose by trying to combine them than we'd gain right now. Happy to help anywhere I can though - always just an @
away :-)
Any update on this? Serilog has some very good filtering and routing support for logging, which my project needs. The sink in its current state wasn't very usable.
Question posted on #3546 by @pdonovan: