Custom metrics in Application Insights are not published to azure.applicationinsights namespace when using OpenTelemetry Azure Monitor exporter

Question

Custom metrics in Application Insights are not published to azure.applicationinsights namespace when using OpenTelemetry Azure Monitor exporter

Yaroslav Vasko 20

I am using OpenTelemetry Metrics together with Azure.Monitor.OpenTelemetry.Exporter to export custom metrics to Application Insights.

According to the documentation:

When you send metrics by using OpenTelemetry, the system automatically stores these metrics in both the metrics store and logs. You can find these metrics in the customMetrics table in Application Insights and in Metrics Explorer under the Custom Metric Namespace called azure.applicationinsights.

In my case, the metrics are successfully ingested into the customMetrics table, but they do not appear in Metrics Explorer under the azure.applicationinsights namespace.

Expected behavior

Custom metrics should:

be available in the customMetrics table (this works), and
appear in Metrics Explorer under the azure.applicationinsights namespace (this does not work).

Actual behavior:

Metrics are present in the customMetrics table.
Metrics are not available in Metrics Explorer under the azure.applicationinsights namespace.

Configuration

services
    .AddMetrics()
    .AddOpenTelemetry()
    .ConfigureResource(resource =>
    {
        resource.AddService(serviceName: environment.Name);
    })
    .WithMetrics(metrics => metrics
        .AddMeter(meterName)
        .AddAzureMonitorMetricExporter(options =>
        {
            options.ConnectionString = connectionString;
        }));

Usage

var histogram = _meter.CreateHistogram<double>(name, unit);
histogram.Record(value, new TagList { ... });

Could you help determine why these metrics are exported to the customMetrics table but are not being promoted to the azure.applicationinsights metric namespace in Metrics Explorer? Is there any additional configuration or limitation that would cause this behavior?

**
Library name and version**

Azure.Monitor.OpenTelemetry.Exporter 1.6.0

Environment

.NET SDK 10.0.300

Runtime: Microsoft.AspNetCore.App 10.0.8

OS Platform: Windows

Application Insights: workspace-based, Custom metrics with dimensions enabled

Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-06-30T13:39:57.1433333+00:00

Hello Yaroslav Vasko, thank you for posting your query on Microsoft Q&A platform.

We are looking into your issue and will keep you posted updates.

Thanks
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-06-30T16:55:51.5433333+00:00
Hello Yaroslav Vasko, You are using Azure.Monitor.OpenTelemetry.Exporter (1.6.0) to send custom metrics. Metrics are successfully ingested into customMetrics (Log Analytics) but are not visible in Metrics Explorer under azure.applicationinsights.

Azure Monitor stores custom metrics via two different pipelines:

Logs > customMetrics (Full-fidelity log record, all dimensions retained)

Metrics Store > Metrics Explorer (Pre-aggregated time series, no dimensions by default)

Based on the information provided, your exporter configuration appears to be correct. Since the metrics are successfully ingested into the customMetrics table, the OpenTelemetry SDK and Azure Monitor exporter are functioning as expected.

The missing behavior is the promotion of those ingested metrics into the Azure Monitor Metrics store, which is what populates the azure.applicationinsights namespace in Metrics Explorer. This promotion is handled by the Azure Monitor backend rather than by the exporter itself.

The issue might occurs because OpenTelemetry metrics are often ingested as log-based metrics and are NOT automatically promoted to the Metrics Store, which is required for Metrics Explorer visibility.

Metrics store requires pre-aggregated metrics: Azure Monitor Metrics (used by Metrics Explorer) is optimized for pre-aggregated time-series data. https://docs.azure.cn/en-us/azure-monitor/app/metrics-overview?tabs=standard

OTel metrics (especially Histograms, dimensions, and raw streams):

Are treated more like log-based telemetry

Hence they remain in logs instead of metrics store

Unsupported / partially supported metric types Histogram (used in your code) and typically not promoted to Metrics Store (remain log-based)

High cardinality (tags/dimensions)

Large TagList = many time series

Azure enforces limits → can block metric-store forwarding

Send custom metrics to Azure Metrics Store” setting disabled : Metrics only go to logs (expected behavior in such cases)

OpenTelemetry pipeline limitations (current platform behavior) : OTel > Azure Monitor integration still evolving (partially preview) https://learn.microsoft.com/en-us/azure/azure-monitor/containers/collect-use-observability-data

Aggregation / propagation delay : Metrics require pre-aggregation before appearing in Metrics Explorer

Quick confirm whether it ever reached the metric store: GET https://management.azure.com/<appinsights-resourceId>/providers/microsoft.insights/metricDefinitions?api-version=2018-01-01&metricnamespace=azure.applicationinsights If your metric isn't listed there, it's a forwarding/limit/setting issue (items 2–3), not a UI delay.

One related limitation to save you time: the namespace name azure.applicationinsights is hardcoded and not customizable (the OTel Meter name isn't used as the namespace) confirmed by the SDK team on GitHub. So the goal is to get the metric to appear under that namespace, not to create your own.

A need few clarifying questions to troubleshoot this:

In App Insights > Usage and estimated costs, what is "Send custom metrics to Azure Metric Store" set to Off, Without dimensions, or With dimensions?

Roughly how many distinct tag/dimension value combinations does your histogram emit (cardinality of the TagList)? Any high-cardinality keys (IDs, timestamps, user IDs)?

When you run the metricDefinitions REST call (or check Metrics Explorer after ~30 min), does the metric name appear at all under azure.applicationinsights, or never?

How long has it been emitting, and is this a long-running ASP.NET Core service or something short-lived/edge that might exit before the periodic export flush?

Does it reproduce if you switch to the Distro (UseAzureMonitor) and/or a simple Counter instead of a Histogram? That isolates instrument-type vs. exporter-config vs. runtime issues.

References: Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python, and Java applications

Metrics in Application Insights

Thank you.
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-01T09:15:37.5233333+00:00

Hello Yaroslav Vasko, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!
Yaroslav Vasko 20 Reputation points

2026-07-01T09:30:58.38+00:00
Hi @Bharath Y P
Thank you for checking this issue.
Please find below the answers to your questions:

With dimensions is enabled

3 tags (e.g. environment, company id) with total cardinality of several thousands. No timestamps, no user ids.

Not on the list

Local development, execution for 5 - 15 minutes

Switching to the Distro (UseAzureMonitor) does not make any difference in terms of custom metrics.
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-15T22:37:59.0766667+00:00
Hello Yaroslav,

Thank you for the additional details.

The exporter appears to be functioning correctly because the metric is successfully ingested into the customMetrics table, which indicates telemetry is reaching Application Insights.

Your implementation uses an OpenTelemetry Histogram:

var histogram = _meter.CreateHistogram<double>(name, unit); histogram.Record(value, new TagList { ... });

Since Histogram metrics can be represented using aggregations such as Count, Sum, Average, Min, and Max, could you please check whether the metric becomes visible when selecting different aggregation options in Metrics Explorer?

As a control test, could you also emit a simple Counter metric with a unique metric name and verify whether it appears in the Application Insights Metrics experience? This would help determine whether the behavior is specific to the Histogram metric type or affects all OpenTelemetry metrics.

Additionally, since custom metrics with dimensions are enabled and the metric contains several thousand dimension combinations, it would be helpful to confirm whether cardinality limits may be contributing to the behavior. The customer indicated that the metric includes multiple tags with total cardinality in the thousands.

Please share the results of the aggregation check and the Counter test, and we will continue investigating.

Reference: https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-add-modify#collect-custom-telemetry

Thank you.
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-23T00:47:48.2466667+00:00

Hello Yaroslav Vasko, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!
Yaroslav Vasko 20 Reputation points

2026-07-24T08:34:03.55+00:00

Hi @Bharath Y P
It appears that the issue has resolved itself in the meantime, or something may have changed on the application insights. At this point, everything seems to be working as expected.

Thank you for your assistance.

Answer accepted by question author

Christos Panagiotidis 3,551

Your Histogram is supported, and the exporter configuration is sufficient. A metric that reaches customMetrics but never appears in metric definitions is not an expected “histograms are log-only” limitation.

First, open Metrics from the Application Insights component, not the linked Log Analytics workspace. Use the Application Insights resource as the scope and azure.applicationinsights as the namespace. A workspace-scoped Logs query can see customMetrics, while the metric-store series belongs to the Application Insights resource.

Then emit a uniquely named Counter with no tags for at least two minutes. If it appears, the pipeline works and the dimensions are the issue. Every tag combination is a time series, with a limit of 5,000 per metric in 24 hours; a company-id dimension can reach that quickly. If the no-tag metric is present in customMetrics but still absent from the component’s metric definitions after 10–15 minutes, capture the metric name, UTC time, component resource ID, and exporter version for an Azure Monitor support case. That result points to a backend metric-store write issue, not missing SDK configuration.

0 comments

1 additional answer

Your answer

Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-06-30T13:39:57.1433333+00:00

Hello Yaroslav Vasko, thank you for posting your query on Microsoft Q&A platform.

We are looking into your issue and will keep you posted updates.

Thanks
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-01T09:15:37.5233333+00:00

Hello Yaroslav Vasko, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!
Yaroslav Vasko 20 Reputation points

2026-07-01T09:30:58.38+00:00

Hi @Bharath Y P
Thank you for checking this issue.
Please find below the answers to your questions:

With dimensions is enabled

3 tags (e.g. environment, company id) with total cardinality of several thousands. No timestamps, no user ids.

Not on the list

Local development, execution for 5 - 15 minutes

Switching to the Distro (UseAzureMonitor) does not make any difference in terms of custom metrics.
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-15T22:37:59.0766667+00:00

Hello Yaroslav,

Thank you for the additional details.

The exporter appears to be functioning correctly because the metric is successfully ingested into the customMetrics table, which indicates telemetry is reaching Application Insights.

Your implementation uses an OpenTelemetry Histogram:

var histogram = _meter.CreateHistogram<double>(name, unit); histogram.Record(value, new TagList { ... });

Since Histogram metrics can be represented using aggregations such as Count, Sum, Average, Min, and Max, could you please check whether the metric becomes visible when selecting different aggregation options in Metrics Explorer?

As a control test, could you also emit a simple Counter metric with a unique metric name and verify whether it appears in the Application Insights Metrics experience? This would help determine whether the behavior is specific to the Histogram metric type or affects all OpenTelemetry metrics.

Additionally, since custom metrics with dimensions are enabled and the metric contains several thousand dimension combinations, it would be helpful to confirm whether cardinality limits may be contributing to the behavior. The customer indicated that the metric includes multiple tags with total cardinality in the thousands.

Please share the results of the aggregation check and the Counter test, and we will continue investigating.

Reference: https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-add-modify#collect-custom-telemetry

Thank you.
Bharath Y P 10,610 Reputation points Microsoft External Staff Moderator

2026-07-23T00:47:48.2466667+00:00

Hello Yaroslav Vasko, Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thanks!
Yaroslav Vasko 20 Reputation points

2026-07-24T08:34:03.55+00:00

Hi @Bharath Y P
It appears that the issue has resolved itself in the meantime, or something may have changed on the application insights. At this point, everything seems to be working as expected.

Thank you for your assistance.

Answer 1

@Christos Panagiotidis
Thank you for your comment and the detailed guidance.

As suggested, I emitted a custom metric without any tags, and it appeared as expected. Interestingly, after that I retried emitting the original version of the custom metric with several tags, and it was also successfully stored in both the analytics and metrics namespaces.

It appears that the issue has resolved itself in the meantime, or something may have changed on the application insights since my previous tests. At this point, everything seems to be working as expected. I will keep in mind the limitation of 5,000 tags per metric.

Thank you for your assistance.