DataDog / dd-trace-dotnet

.NET Client Library for Datadog APM
https://docs.datadoghq.com/tracing/
Apache License 2.0
439 stars 138 forks source link

AWS Lambda Top Level Statement Support #3345

Closed jnordtorp-foreflight closed 11 months ago

jnordtorp-foreflight commented 1 year ago

Are you requesting automatic instrumentation for a framework or library? Please describe. In the net6 runtime for aws lambda, they added support for top level statements. See

Is your feature request related to a problem? Please describe. Using top level statements, we change the function handler to only contain the assembly, but when initializing the tracer for serverless operation, the constructor expects the function handler to be formated as A::B::C, where as now we only provide A.

Describe the solution you'd like We would like support for using lambda top level statements

andrewlock commented 1 year ago

Hi @jnordtorp-foreflight, thanks for flagging this. This is something we'd like to support, but it's unfortunately rather complex, so I can't give anytimelines. cc @purple4reina for visibility

lukeemery commented 1 year ago

@andrewlock It is something that datadog needs to support. More critically though, we need guidance on how to manually instrument lambdas while still using top level functions.

alancosta-iress commented 1 year ago

This pending change will affect anyone writing their dotnet core minimal API's with AWS' own hosting library

We are on the cusp of deciding whether to:

Understandable that you can't give any timelines, but how about a notion of how this is being prioritised? Is that possible? We would really appreciate at least a time range with which we could work with.

Thank you!

joeterlecki commented 1 year ago

We have a dozen dotnet minimal apis and are also looking for this to be implemented. To echo what others are stating, AWS library is also using top-level statements and assembly references for handlers moving forward.

jamiewinder commented 1 year ago

I've just encountered this issue. Has anyone found a workaround, or an alternative way of structuring an ASP.NET Core project that is compatible?

tristanharms-cb commented 1 year ago

Don't want to +1 this thread too much, but I'm also running into this issue. Has there been any progress on this since it's been assigned?

joeyzhao2018 commented 1 year ago

Poll +1 on 🚀 If you use ASP.NET Core Minimal APIs. i.e. like this template +1 on 👀 If you use top-level statements but NOT Asp.net core. i.e. like this template.

joeterlecki commented 1 year ago

Poll +1 on 🚀 If you use ASP.NET Core Minimal APIs. i.e. like this template +1 on 👀 If you use top-level statements but NOT Asp.net core. i.e. like this template.

We actually use top level statements in both minimal APIs and console type apps.

This feature should support Top-level statements regarding the type of project. When creating serverless API's a single use function is just a console application. So there is a function for at the minimal for each method type (Get, PUT, Delete ect) Then its not uncommon to have separate functions for Get USER vs Get USERS

joeyzhao2018 commented 11 months ago

Re-opened the issue since the layer is not released yet.

joeterlecki commented 11 months ago

This is awesome and thanks for getting the Top level statements enabled for tracing.

Any timeline on when the new lambda layer version will be released?

joeyzhao2018 commented 11 months ago

The fix is now RELEASED! It's available in dd-trace-dotnet version 2.41.0. And Datadog AWS Lambda layers version 12, i.e. arn:aws:lambda:<region>:464622532012:layer:dd-trace-dotnet:12 arn:aws:lambda:<region>:464622532012:layer:dd-trace-dotnet-ARM:12 It's also reflected in serverless-plugin-datadog version 5.51.0. We will also create a repo(WIP) in order to provide the layer release notes, which will include the underlying dd-trace-dotnet version info.