Azure Function with Open Telemetry enabled creates unwanted system metrics

Question

I have an Azure Function using Java 17 running on the Flex Consumption plan.
After turning on Open Telemetry using documentation found here:
https://learn.microsoft.com/en-us/azure/azure-functions/opentelemetry-howto?tabs=app-insights%2Cihostapplicationbuilder%2Cmaven&pivots=programming-language-java

I get unwanted system/process metrics related to dotnet which were not present before:

Following has been tried:

• Setting environment variable OTEL_DOTNET_AUTO_METRICS_ENABLED to false does not turn them off
• Setting environment variable OTEL_METRICS_EXPORTER to None turned off only my apps OTEL metrics but kept outputting unwanted system ones.
• Setting log level to Warning on Host.Aggregator and OpenTelemetry

Host.json:

{
    "version": "2.0",
    "telemetryMode": "OpenTelemetry",
    "logging": {
        "logLevel": {
            "default": "Warning",
            "Host.Aggregator": "Warning"
        },
        "OpenTelemetry": {
            "logLevel": {
                "default": "Warning"
            }
        }
    },
    "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
    }
}

Any way to suppress these logs or turn them off?

Answer 1

Hey Michal Czuper! It sounds like you're running into an issue with unwanted system metrics showing up after enabling OpenTelemetry in your Azure Function. Here are some suggestions you can try to suppress or control those unwanted metrics:

1. Check Environment Variables: Ensure that the following environment variables are set correctly:
   • For disabling .NET metrics, you've already tried setting OTEL_DOTNET_AUTO_METRICS_ENABLED to false, which is good. Just to double-check, make sure it's correctly set and recognized by the Azure Function.
   • Make sure OTEL_METRICS_EXPORTER is set to None, as you've mentioned, to ensure that application-specific metrics are not outputting while retaining system ones.
2. Log Configuration in host.json: You’ve set log levels for Host.Aggregator and OpenTelemetry to Warning. However, make sure that the settings are correctly formatted like this:

   
      {
   
          "version": "2.0",
   
          "telemetryMode": "OpenTelemetry",
   
          "logging": {
   
              "logLevel": {
   
                  "default": "Warning",
   
                  "Host.Aggregator": "Warning",
   
                  "OpenTelemetry": {
   
                      "logLevel": {
   
                          "default": "Warning"
   
                      }
   
                  }
   
              }
   
          }
   
      }
   
   

3. Host vs Worker Process: It's important to note that filters defined in host.json apply only to logs generated by the host process. For issues related to OpenTelemetry in the worker process (which might be generating the unwanted metrics), ensure you're using OpenTelemetry settings tailored for Java if available.
4. Check for Duplicate Instruments: Since you're observing metrics related to .NET, consider whether you're using any libraries that could be instrumenting your function in a way that conflicts with your OpenTelemetry configuration.
5. Diagnostics and Troubleshooting: You might want to explore the Diagnose and solve problems blade in the Azure portal for your Function App. This tool can help check for misconfigurations or issues with your function's deployment.
6. Review OpenTelemetry Documentation: Make sure that you have the correct and most up-to-date guidance on configuring OpenTelemetry for your use case, especially focusing on Java.

If these suggestions do not resolve the issue, here are some follow-up questions to narrow down the root cause:

• Are you using any additional libraries or frameworks that might conflict with OpenTelemetry?
• Have you checked if any other logs related to the metrics are being emitted in the Azure portal?
• Can you confirm the specific metrics that are being logged that you consider "unwanted"? Is it possible they are essential for system monitoring?
• Is this behavior observed consistently across all deployments, or is it isolated to a particular environment?

Hope this helps! Let me know if you have any more details to share or if you need further assistance!

Note: This content was drafted with the help of an AI system.