Add spec for tracing Azure Functions

[z1c0]

This is a first specification draft for tracing Azure Functions.
The scope of this PR is generic instrumentation and the HTTP trigger type.
Please also take a lot at the related draft PR regarding Azure Functions metadata: #712

• Create PR as draft
• Approval by at least one other agent
• Mark as Ready for Review (automatically requests reviews from all agents and PM via CODEOWNERS)
  • Remove PM from reviewers if impact on product is negligible
  • Remove agents from reviewers if the change is not relevant for them
• Approved by at least 2 agents + PM (if relevant)
• Merge after 7 days passed without objections
  To auto-merge the PR, add /schedule YYYY-MM-DD to the PR description.
• Create implementation issues through the meta issue template (this will automate issue creation for individual agents)

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-01-12T18:42:49.934+0000

• Duration: 3 min 2 sec

[gregkalapos]

Looks nice overall 👍

Some comments below.

[trentm]

Added another suggestion for transaction.name for an HTTP-triggered function after some playing with a custom routePrefix in "host.json".

• If one specifies routePrefix='foo', then routes are /foo/MyFuncName as expected.
• If one specifies routePrefix='/foo', then routes are //foo/MyFuncName. However GET /foo/MyFuncName works, so I think we should normalize the transaction name to just have a single leading slash.
• If one specifies routePrefix='' (the empty string), then routes are /MyFuncName.
• If one specifies routePrefix='foo/' (i.e. with a trailing slash), then routes are /foo//MyFuncName are the Azure Function host code blows up with:

2023-01-03T22:39:04.082 [Error] A host error has occurred during startup operation '513902a7-f0bb-4586-8da2-1ce9c223e8bc'.Microsoft.AspNetCore.Routing.RouteCreationException : An error occurred while creating the route with name 'HttpFn1' and template '/foo//HttpFn1'. ---> System.ArgumentException : The route template separator character '/' cannot appear consecutively. It must be separated by either a parameter or a literal value. (Parameter 'routeTemplate') ---> Microsoft.AspNetCore.Routing.Patterns.RoutePatternException : The route template separator character '/' cannot appear consecutively. It must be separated by either a parameter or a literal value.at Microsoft.AspNetCore.Routing.Patterns.RoutePatternParser.Parse(String pattern)at Microsoft.AspNetCore.Routing.Patterns.RoutePatternFactory.Parse(String pattern)at Microsoft.AspNetCore.Routing.Template.TemplateParser.Parse(String routeTemplate)End of inner exceptionat
...

The last point shows that we don't need to worry about normalizing the number of slashes other than at the start of the URL path.

[trentm]

For reference: One of the lingering concerns with APM agents running in Azure Functions had been whether the asynchronous intake requests to APM server would have an adverse impact on the billing/cost of those Azure Functions. I did some experiments around this and came to the conclusion that: no, there is no impact on cost from the regular background intake requests. My write-up is here: elastic/apm-agent-nodejs#3071 (comment)

[trentm]

LGTM. Just one more suggestion to add the config var name.