micrometer-metrics
Azure Registry: Change implementation to use `azure-monitor-opentelemetry-exporter`
Please describe the feature request.
The currently used com.microsoft.azure:applicationinsights-core dependency is nearly 7 MiB in size. While the new 3.x versions of the Application Insights SDK promote using a Java agent (in which case no specific Micrometer registry implementation is required), there may still be use cases for using an explicit Micrometer registry and working without the Java agent.
Apart from the mentioned fact that the dependency is very heavy, I also think I've understood that the 2.x version is end-of-life and probably won't receive support for connection strings instead of instrumentation keys. Using connection strings will become mandatory by 2025-03-31 (see https://learn.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent and https://learn.microsoft.com/en-us/azure/azure-monitor/app/migrate-from-instrumentation-keys-to-connection-strings).
There is a new OpenTelemetry Exporter under development (current version is 1.0.0-beta6), which is a standard OpenTelemetry exporter capable of sending metrics to Azure Monitor. This could be used by the Micrometer Azure Registry to send metrics.
Rationale See description.
Additional context
The currently used com.microsoft.azure:applicationinsights-core dependency is nearly 7 MiB in size
You might want to open an issue for applicationinsights-core to mitigate this.
Application Insights SDK promote using a Java agent
I'm not sure we can do anything with this, except let people know about the trade-offs:
- Java agents won't work with aot-compiled apps (i.e.: GraalVM Native image)
- They don't have access to all the data that "hardcoded" instrumentation can
- Theoretically they are slower
2.x version is end-of-life
So as far as I understand, there will be no path forward for metrics libraries to migrate to 3.x (as you said, it is agent based). On the other hand I'm not sure how can we use the azure-monitor-opentelemetry-exporter since it was created to work with the OTel SDK not with Micrometer.
I'm not sure if they support any other formats than their own, but if so, maybe that could work too, e.g.: if they support OTLP, micrometer could work with that since we also have OTLP support.
Wouldn't it be possible for the Azure Monitor registry implementation to use the OpenTelemetry SDK to export the metrics? I would have thought the OTLP support already has those dependencies. I would however also need to check that the exporter I mention also supports metrics and not just tracing.
It doesn't, the OTLP registry uses opentelemetry-proto which is basically the domain classes, while the exporter depends on the opentelemetry-sdk which is the full implementation of OTel. I still not see how could the exporter be reused but I did not dig deep into its code.
If Azure Monitor can ingest OTLP format metrics directly, you can use the micrometer-registry-otlp dependency to publish OTLP format metrics to Azure Monitor. Otherwise, you would need an OTLP Collector in between to translate from OTLP format to Azure Monitor's format.
A registry similar to the azure-monitor-opentelemetry-exporter one that is for Micrometer could be made also. It seems the code there uses azure-core and azure-core-http-netty to send metrics directly to Azure Monitor given a connection string. The questions would be whether to maintain it here or in the azure repo, and especially if the answer is to maintain it here, how stable is the API we would need to use.
