Migrating from OpenTracing.NET to OpenTelemetry.NET

[object]

We have been using Phobos with OpenTelemetry where trace exporter is typically configured like this (in F#):

        let configureTracing (serviceProvider: IServiceProvider) =

            let settings = connectionString "JaegerPhobos" |> DbUtils.parseConnectionString
            let host = settings.["Host"]
            let port = settings.["Port"] |> Int32.Parse
            let loggerFactory = serviceProvider.GetRequiredService<ILoggerFactory>()
            let logReporter = LoggingReporter(loggerFactory)

            let remoteReporter =
                RemoteReporter
                    .Builder()
                    .WithLoggerFactory(loggerFactory)
                    .WithMaxQueueSize(100)
                    .WithFlushInterval(TimeSpan.FromSeconds(1.))
                    .WithSender(UdpSender(host, port, 0))
                    .Build()

            let assemblyName =
                Reflection.Assembly.GetEntryAssembly().GetName()
                    .Name
            let tracer =
                Tracer
                    .Builder(assemblyName)
                    .WithReporter(CompositeReporter(remoteReporter, logReporter))
                    .WithSampler(ConstSampler(true))
                    .WithScopeManager(ActorScopeManager())
                    .Build()

            tracer :> ITracer

The ITracer object is then passed to Phobos bootstrapper.

This is not how OpenTelemetry exporters are configured in .NET 6, here's a new sampe code (in C#):

services.AddOpenTelemetryTracing(builder => {
    builder
        .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("MyServiceName"))
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddSqlClientInstrumentation(o => {
            o.SetDbStatementForText = true;
            o.RecordException = true;
        })
        .AddJaegerExporter(o => {
            o.AgentHost = openTracingConfiguration?.Host ?? "localhost";
            o.AgentPort = openTracingConfiguration?.Port ?? 6831;
        });
});

I've found this post that suggests using TracerShim from OpenTelemetry.Shims.OpenTracing, and this workaround works. However it would be great if Phobos supported OpenTelemetry DI out of the box, without using TracerShim.

[Aaronontheweb]

Hi @object - the new Phobos 2.0 binaries should support this without using the shim.

An example from the OTel branch of https://github.com/petabridge/Petabridge.Phobos.Web/tree/otel

Configure OTel itself:

https://github.com/petabridge/Petabridge.Phobos.Web/blob/2faa71d5634554d50ae55c0b6cbb04ff66ffa37e/src/Petabridge.Phobos.Web/Startup.cs#L53-L78

Consume in Phobos:

https://github.com/petabridge/Petabridge.Phobos.Web/blob/2faa71d5634554d50ae55c0b6cbb04ff66ffa37e/src/Petabridge.Phobos.Web/Startup.cs#L88-L104

We are probably going to be able to get rid of the PhobosSetup to some extent as we continue working on Phobos 2.0 - but you don't need any of the OpenTracing shims with this.

[object]

Thank you. So I need to upgrade to Phobos 2.0, right? What is the state of the 2.0 version? Do you recommend upgrading now or there is some remaining work to be done?

[Aaronontheweb]

Phobos 2.0 is a mature beta - all of the big stuff on the tracing side has been figured out; still have some outstanding issues around metrics (mailbox depth is the only real question mark there, since OTel doesn't have a performant stand-alone Gauge structure), and we're working on chasing down some bugs related to trace correlation. You can follow our progress here https://github.com/petabridge/phobos-issues/milestone/8

We've been promising our sales guy that we'll have Phobos 2.0 code-complete by end of March - we can't get it all the way out of an RC state because OpenTelemetry itself is also in RC, but that's the rough deadline.

[object]

Thank you very much for a quick reponse. I will look into Phobos 2.0.

[Aaronontheweb]

No problem - we also don't have any built-in Phobos dashboards for Phobos 2.0 other than Prometheus, FYI. We're waiting until we get the metrics piece universally resolved before we embark on that.