Azure Monitor

Connection string

The exporter needs the resource's connection string: the instrumentation key and the regional IngestionEndpoint (records go to {IngestionEndpoint}/v2.1/track; without one, to https://dc.services.visualstudio.com), plus the LiveEndpoint for Live Metrics. Outside the browser, with options.UseEnvironmentVariables on, an unset connection string is read from APPLICATIONINSIGHTS_CONNECTION_STRING - and that variable alone adds the exporter when none is configured, which is what App Service and Container Apps set.

builder.Services.AddBitBelemetryServices(options =>
{
    options.ServiceName = "MyApp";            // ai.cloud.role
    options.ServiceNamespace = "Shop";        // ai.cloud.role = "[Shop]/MyApp"

    options.AddAzureMonitorExporter(builder.Configuration["ApplicationInsights:ConnectionString"]!);
});

The browser script exports to Application Insights too (IncludeInBrowser, on by default) - the same arrangement as Microsoft's JavaScript SDK, whose connection string is in every page it runs on. The instrumentation key identifies the resource; it does not authorize reading anything. Turn IncludeInBrowser off to keep the browser away from it, and use the Relay transport to send browser records through .NET instead.

Microsoft Entra ID

A resource with local authentication disabled only accepts telemetry with an Entra ID token. AccessTokenProvider supplies one, sent as Authorization: Bearer, for the scope https://monitor.azure.com//.default. Belemetry takes no dependency on Azure.Identity: the provider is a plain delegate, so any credential - managed identity, workload identity, a client secret - plugs in.

An exporter with a token provider is never handed to the browser script, which could not hold the token safely. On Blazor Server and Hybrid, browser records reach such a resource through the Relay transport. In WebAssembly the .NET pipeline runs in the browser too, so it is no place for a credential either: there, send telemetry to a server of yours (an OpenTelemetry Collector with the Azure Monitor exporter, for example) and let that server authenticate.

using Azure.Core;
using Azure.Identity;

var credential = new DefaultAzureCredential();

builder.Services.AddBitBelemetryServices(options =>
{
    options.AddAzureMonitorExporter(builder.Configuration["ApplicationInsights:ConnectionString"]!, azure =>
    {
        azure.AccessTokenProvider = async cancellationToken =>
            (await credential.GetTokenAsync(
                new TokenRequestContext(["https://monitor.azure.com//.default"]), cancellationToken)).Token;
    });
});

MaskIp

Application Insights derives each record's city and country from the client IP address it was sent from. With MaskIp (on by default) Belemetry sends ai.location.ip = 0.0.0.0, so no location is derived and the user's address is not part of the record. Belemetry never adds the client IP itself. Turn it off only if you need the geography and your privacy notice covers it.

Live Metrics

With EnableLiveMetrics the .NET side streams requests, dependencies, exceptions, CPU and memory to the portal's Live Metrics blade once per second while someone is watching it - following the Application Insights QuickPulse protocol, so treat it as a preview feature. It is not available in the browser, and in WebAssembly it reports the app running in that one browser, so it is most useful with the server pipeline and in Hybrid apps.

Compression, timeout and signals

Compression = BelemetryCompression.Gzip compresses the envelope array (Content-Encoding: gzip), in the browser too. Timeout bounds one request (30 s). Signals restricts what is sent, by the browser script as well - for example metrics only, while traces and logs go to an OTLP backend. Throttling (429, 439), transient failures (408, 500, 502, 503, 504) and the items of a partial success (206) are retried, and kept by the offline persistence while the network is down. Metrics are always sent as deltas, which is what customMetrics expects, whatever Metrics.Temporality says. MinimumLogLevel is the per-exporter counterpart of a logging provider's level: Application Insights gets the plain log records at or above it while an OTLP backend gets everything, from one pipeline; events (page views, custom events, web vitals, exceptions), spans and metrics always pass.

How each record becomes an envelope - the types, tags and properties - is on the Azure mapping page.

API