Giters

DataDog / dd-trace-dotnet

.NET Client Library for Datadog APM

Home Page:https://docs.datadoghq.com/tracing/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

APM Tracing in .NET Native AOT apps

zlangner opened this issue · comments

commented

I'm using .NET8 in a custom image running on AWS Lambda. In its current state I have logs and APM traces going to datadog using Datadog.Trace v2.50.0. This has been working great so far.

In order to get faster run time, I'm exploring using Native AOT. The first and only hurdle I hit was using Datadog.Trace. After removing this package I was able to update the app to use Native AOT and the result is that it's about 10x faster. However, I do like the visibility that I get with APM so I'd like to have it back.

I did try to use Datadog.Trace.Trimming with Datadog.Trace but it didn't seem to matter. The error I got while publishing the app was:

Generating native code
/root/.nuget/packages/microsoft.identitymodel.tokens/6.35.0/lib/net6.0/Microsoft.IdentityModel.Tokens.dll : warning IL2104: Assembly 'Microsoft.IdentityModel.Tokens' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/src/MyProject.csproj]
/root/.nuget/packages/datadog.trace/2.50.0/lib/net6.0/Datadog.Trace.dll : warning IL2104: Assembly 'Datadog.Trace' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries [/src/MyProject.csproj]
EXEC : error : Failed to load assembly 'Microsoft.AspNetCore.Http.Abstractions' [/src/MyProject.csproj]

This app does not reference or use Microsoft.AspNetCore.Http.Abstractions so I suspect it's coming from Datadog.Trace.

Is there any plan to support Native AOT compiled dotnet apps in the future?

commented

There are two distinct scenarios to support:

  • Custom instrumentation, where you manually call the Datadog.Trace APIs to create spans
  • Automatic instrumentation, where we dynamically rewrite relevant methods to automatically create spans

We are actively working on supporting automatic instrumentation on NativeAOT, but it is a huge undertaking, requiring to rewrite the core of our instrumentation engine. We might reach the status of closed beta by the end of the quarter (June), but I can't make any promise at this point.

As a stop-gap measure, I believe custom instrumentation should mostly work with NativeAOT, even though we don't actively support it. I tried publishing a simple app, and interestingly I only got the Microsoft.AspNetCore.Http.Abstractions error when Datadog.Trace.Trimming is added. Without it, I managed to publish the application just fine.
If you decide to go this (unsupported) way, make sure to never set DiagnosticSourceEnabled to true if you reconfigure the tracer. This path relies on emitting IL, so it will break on NativeAOT.

commented

Thank you for the quick reply! I should have time to try it again without Datadog.Trace.Trimming later today. This particular application doesn't do anything requiring automatic instrumentation so only having custom instrumentation should be fine.

Is there any thought of splitting those up into 2 packages? Something like Datadog.Trace.Core for custom instrumentation, and Datadog.Trace referencing that and building on it to add automatic instrumentation? If it were architected that way, use cases that only need/want custom instrumentation should be leaner and easier to manage.

commented

You're correct @kevingosse, by only using Datadog.Trace it does compile using NatvieAOT but the behavior is the same as not including it. I still get logs but there are no traces appearing in APM. Nothing from custom instrumentation nor automatic instrumentation.