esm module

[kamaz]

No description provided.

[wboumans]

Also see README.md in this branch:

This is an ESM version of the OTel node function, that fails to report outgoing spans in Azure monitor

[RohitRanjanMS]

Thanks @wboumans and @kamaz, I will engage our node language worker team to get help on this.

[wboumans]

@RohitRanjanMS Hello Rohit, thank you for taking this forward. I was wondering if the node language worker team were able to have a look at this?

[RohitRanjanMS]

Hi @wboumans , I reached out to the Azure Monitor team, and they said that they have an ESM updated release coming soon, but it should be possible to collect telemetry if you follow the steps here opentelemetry-js/doc/esm-support.md at main · open-telemetry/opentelemetry-js since OpenTelemetry doesn't work with ESM out-of-the-box period.

[RohitRanjanMS]

Hi @wboumans , following up on this, were you able to make it work?

[wboumans]

@RohitRanjanMS sorry about the delay, I was off for a few days.

We got something working (at least from the function on local) using this approach:

1. Include the @azure/functions-opentelemetry-instrumentation source code into our codebase, so that CJS package is no longer used until upgraded to ESM
2. Start up OTEL by splitting the initialise function into its own ESM module (azure-open-telemetry.esm next to the main index.esm).
3. Change package.json:main to run both the telemetry and index files. Note: This is not the approach with the experimental loader for ESM that the OTEL team and @RohitRanjanMS suggested. But it works, and using the loader did not, possibly because the next issue...
4. Dynamically load the @azure/functions package, so that the functions package loads after the instrumentation happened. This prevents the message: "@azure/functions-opentelemetry-instrumentation Module @azure/functions has been loaded before @azure/functions-opentelemetry-instrumentation so it might not work, please initialize it before requiring @azure/functions" that the OTEL DiagConsoleLogger spits out when logging fails. This may be ESM specific, as module loading happens async (and in the background)? Dynamically requiring the package works around that.

Further testing needs to be done, but I suspect that indeed ESM module loading is causing the issue here. I'll continue on Tuesday (Fr/Mo are public holidays in the UK)