Improved integration for Azure Functions

Azure functions support DI.

Right now the entry point is on IWebHost. This is not expose on serverless environments. Which means users need to Init and Dispose the SDK on each execution or some other work around that at Init once but await SentrySdk.FlushAsync by hand.

This task is to improve the story so that it’s easy to plug Sentry’s SDK with Azure Functions via DI (i.e: single Hook into IFunctionsHostBuilder).

Related to #730 #529

[mattjohnsonpint]

Our initial support for Azure Functions (isolated worker) has been released. (Thanks @SeanFeldman!)

You’ll find it on Nuget as Sentry.AzureFunctions.Worker

Documentation is pending. For now, see the sample at https://github.com/getsentry/sentry-dotnet/blob/main/samples/Sentry.Samples.AzureFunctions.Worker/Program.cs.

Please leave any general feedback here on this issue, but open a new issue for any bugs or significant oversights.

Note, we do not have a version for in-process functions ready at this time, but may in the future. Thanks.

[SeanFeldman]

High-level plan

Azure Functions has undergone a significant change in the last few years. A big investment was made into Isolated Worker SDK (Out of Process). The Isolated worker SDK is the recommended way to build Azure Functions. In-Process SDK is still supported but not for long. More about the Azure Functions roadmap here.

The plan for Sentry support is to build first-class support for the Isolated Worker SDK and introduce an equivalent, if possible, for In-Process SDK. High-level objectives are:

• .UseSentry() on the Functions specific host builder API to be consistent with other .NET technologies such as ASP.NET Core.
• Setting optimal defaults
• Automatically track errors, sessions (release health), and performance
• Manage transaction names according to the trigger type in a way that makes sense (HTTP route for HTTP triggered functions vs alternative for non-HTTP triggers) --> reflection workaround. Tracking issue with Functions SDK here.
• Out-of-the-box exception processor that cleans up the data that’s getting logged
• Functions cancellation token to mark Sentry transaction as Cancelled
• Support for triggers
  • HTTP
  • Timer
  • Blob, Storage queue, Azure Service Bus, etc will follow the same pattern
• Add a sample
• Deduplication of Sentry tags (AzureFunctions_FunctionName vs functionName)
  • Replace with tag filters --> PR #2360
• Review support for In-Proc SDK support
• Usage Documentation