Q: adding an auto-instrumentation from a different monorepo

[maorleger]

Hiya friends, apologies in advance if this is documented somewhere but I maintain the @azure/opentelemetry-instrumentation-azure-sdk client library and would love to add Azure instrumentation to the auto-instrumentation-node metapackage.

The library is currently hosted in our monorepo where we can absorb any core changes and release independently - are there options or existing libraries that contribute to the auto-instrumentation-node metapackage from a separate repository?

If not, any guidance or ideas y'all can share?

Finally, as a last resort I can move the logic here and deprecate the instrumentation package under the @azure namespace but would prefer not to. I'm very interested in adding support for Azure so would love to hear from y'all!

• This only affects the JavaScript OpenTelemetry library

[hectorhdzg]

In my opinion main benefit of having an instrumentation in this repo would be about visibility and maintainability making it fully open source, Azure Functions team is in the process of adding an instrumentation in this repo, we also have Azure specific resource detectors available here.
We also have several Azure specific packages, like Azure Monitor Exporter and Azure Monitor Distro, that live outside of this repository, that is actually same Azure SDK repo as your instrumentation, these being our main products, we need to have bigger control of updates and releases, hot fixes being a possibility :) To solve discoverability issue, OpenTelemetry offers a registry of external components so users can find them, our Azure packages are currently available there.
https://opentelemetry.io/ecosystem/registry/?language=js

[lmolkova]

The benefit of having Azure SDK instrumentation here would be that default-distro would provide it and save users from explicitly adding a dependency.

In this sense Azure exporter is different because it's an exporter to a specific backend, while Azure SDK instrumentation is similar to AWS , Mongo, or Redis and should be part of the default distro.

In case of Java, Azure SDK instrumentation is part of the vanilla otel Java agent - https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/azure-core (as a thin wrapper over com.azure:azure-core-tracing-opentelemetry)

So I think it's not a question of a repository, but more of a default distro content.
It can be probably solved by adding a thin wrapper over @azure/opentelemetry-instrumentation-azure-sdk in this repo or some other mechanism that'd pull @azure/opentelemetry-instrumentation-azure-sdk and register the instrumentation in the default distro/metapackage.

[pichlermarc]

With the changes from #2259 it is possible to add the package here in this repo as a vendor component.

Keep in mind though: with the future developments that I proposed in #2259 (comment), the autoinstrumentations-node package (and therefore your reason to add the package here) might soon be no-more. The metapackage is part of the issue we're trying to address with the changes in #2259. It simply provides too much incentive for contributors to prefer adding more instrumentations here over hosting it in a seperate repo closer to the community that knows the instrumented package.