[Spike] Azure functions support

[kmudduluru]

See Feature ticket for more details. Waiting on the Agent spec on this feature. This spike is to determine and implement the changes needed to support Node.js apm in Azure functions.
Reached out to get access to Azure test environment and test apps

[workato-integration]

https://new-relic.atlassian.net/browse/NR-359396

[mrickard]

Azure Functions are Azure's serverless computing offering.

Supporting Azure functions requires instrumenting the @azure/functions Node.js library. Azure Functions applications rely on this library for access to the Functions runtime environment. Function applications also rely on it for code and file structure in place of other application frameworks.

Azure Functions applications can be triggered by different events, which our spec abstracts into these categories:

• timer
• datasource
• http
• pubsub
• other

A typical function will import app from @azure/functions, and invoke one of its trigger methods:

const { app } = require('@azure/functions');

app.http('HttpExample', {
    methods: ['GET'],
    authLevel: 'anonymous',
    handler: async (request, context) => {
        const name = request.query.get('name') || await request.text() || 'world';
        return { body: JSON.stringify(r.body) };
    }
});

We'll want to instrument the handler, request, and aspects of the context. The context argument includes properties we can use for instrumentation: functionName, invocationId, traceContext, and others.

The @azure/functions Node library exposes several app methods in /src/app.ts, which all call a generic function. We should focus on instrumenting that and the arguments supplied to it. As trigger types are added, they should be recognized automatically.

Context is present with each handler, while the properties of the first argument are different, depending on the trigger type.

We have the option of instrumenting this library similarly to the way we instrument other libraries, or we can now use the Node diagnostics channel. (We considered leveraging the otel instrumentation for Azure Functions via the otel bridge, but only emits logs and doesn't produce spans.)

Requirements:

The Node agent should not be in serverless mode for Azure Function instrumentation. Normal APM mode lets the agent deliver telemetry to the standard collector, so data is surfaced in the normal APM view.

See agent specs for expected trace and span properties, as well as for utilization properties.

Concerns:

Latency: in testing with the current production agent, I haven't seen unusual latency from function apps.

Telemetry transport: the current production agent does deliver telemetry based on its instrumentation of core Node libraries. This shows that preconnect/connect and calls to the collector work as expected.

V4-vs-V3: the @azure/functions library offers two different syntaxes, depending on the version. I'd recommend focusing on the current V4 syntax.

Installation:

For this feature, we should concentrate on deploying the agent with the function application. Future stories can focus on installation via Azure Site Extension (Windows) or via container (Linux). Most Azure Functions subscription levels allow for deploy-as-code, with the exception of the Container App for Functions (Linux only).

Individual stories:

• Instrumentation of @azure/functions generic trigger
• Azure Functions utilization detection
• Verification by deploying a function app with different supported triggers