Migrate from .NET Application Insights SDKs to Azure Monitor OpenTelemetry
This guide provides step-by-step instructions to migrate various .NET applications from using Application Insights software development kits (SDKs) to Azure Monitor OpenTelemetry.
Expect a similar experience with Azure Monitor OpenTelemetry instrumentation as with the Application Insights SDKs. For more information and a feature-by-feature comparison, see release state of features.
- ASP.NET Core migration to the Azure Monitor OpenTelemetry Distro. (
Azure.Monitor.OpenTelemetry.AspNetCore
NuGet package) - ASP.NET, console, and WorkerService migration to the Azure Monitor OpenTelemetry Exporter. (
Azure.Monitor.OpenTelemetry.Exporter
NuGet package)
If you're getting started with Application Insights and don't need to migrate from the Classic API, see Enable Azure Monitor OpenTelemetry.
Prerequisites
- An ASP.NET Core web application already instrumented with Application Insights without any customizations
- An actively supported version of .NET
Tip
Our product group is actively seeking feedback on this documentation. Provide feedback to [email protected] or see the Support section.
Remove the Application Insights SDK
Note
Before continuing with these steps, you should confirm that you have a current backup of your application.
Remove NuGet packages
Remove the
Microsoft.ApplicationInsights.AspNetCore
package from yourcsproj
.dotnet remove package Microsoft.ApplicationInsights.AspNetCore
Remove Initialization Code and customizations
Remove any references to Application Insights types in your codebase.
Tip
After removing the Application Insights package, you can re-build your application to get a list of references that need to be removed.
Remove Application Insights from your
ServiceCollection
by deleting the following line:builder.Services.AddApplicationInsightsTelemetry();
Remove the
ApplicationInsights
section from yourappsettings.json
.{ "ApplicationInsights": { "ConnectionString": "<Your Connection String>" } }
Clean and Build
Inspect your bin directory to validate that all references to
Microsoft.ApplicationInsights.*
were removed.Test your application
Verify that your application has no unexpected consequences.
Tip
Our product group is actively seeking feedback on this documentation. Provide feedback to [email protected] or see the Support section.
Enable OpenTelemetry
We recommended creating a development resource and using its connection string when following these instructions.
Plan to update the connection string to send telemetry to the original resource after confirming migration is successful.
Install the Azure Monitor Distro
Our Azure Monitor Distro enables automatic telemetry by including OpenTelemetry instrumentation libraries for collecting traces, metrics, logs, and exceptions, and allows collecting custom telemetry.
Installing the Azure Monitor Distro brings the OpenTelemetry SDK as a dependency.
dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore
Add and configure both OpenTelemetry and Azure Monitor
The OpenTelemery SDK must be configured at application startup as part of your
ServiceCollection
, typically in theProgram.cs
.OpenTelemetry has a concept of three signals; Traces, Metrics, and Logs. The Azure Monitor Distro configures each of these signals.
Program.cs
The following code sample demonstrates the basics.
using Azure.Monitor.OpenTelemetry.AspNetCore;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
public class Program
{
public static void Main(string[] args)
{
var builder = WebApplication.CreateBuilder(args);
// Call AddOpenTelemetry() to add OpenTelemetry to your ServiceCollection.
// Call UseAzureMonitor() to fully configure OpenTelemetry.
builder.Services.AddOpenTelemetry().UseAzureMonitor();
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
}
}
We recommend setting your Connection String in an environment variable:
APPLICATIONINSIGHTS_CONNECTION_STRING=<Your Connection String>
More options to configure the Connection String are detailed here: Configure the Application Insights Connection String.
Tip
Our product group is actively seeking feedback on this documentation. Provide feedback to [email protected] or see the Support section.
Install and configure instrumentation libraries
Instrumentation libraries can be added to your project to auto collect telemetry about specific components or dependencies.
The following libraries are included in the Distro.
Customizing instrumentation libraries
The Azure Monitor Distro includes .NET OpenTelemetry instrumentation for ASP.NET Core, HttpClient, and SQLClient. You can customize these included instrumentations or manually add extra instrumentation on your own using the OpenTelemetry API.
Here are some examples of how to customize the instrumentation:
Customizing AspNetCoreTraceInstrumentationOptions
builder.Services.AddOpenTelemetry().UseAzureMonitor();
builder.Services.Configure<AspNetCoreTraceInstrumentationOptions>(options =>
{
options.RecordException = true;
options.Filter = (httpContext) =>
{
// only collect telemetry about HTTP GET requests
return HttpMethods.IsGet(httpContext.Request.Method);
};
});
Customizing HttpClientTraceInstrumentationOptions
builder.Services.AddOpenTelemetry().UseAzureMonitor();
builder.Services.Configure<HttpClientTraceInstrumentationOptions>(options =>
{
options.RecordException = true;
options.FilterHttpRequestMessage = (httpRequestMessage) =>
{
// only collect telemetry about HTTP GET requests
return HttpMethods.IsGet(httpRequestMessage.Method.Method);
};
});
Customizing SqlClientInstrumentationOptions
We vendor the SQLClient instrumentation within our package while it's still in beta. When it reaches a stable release, we include it as a standard package reference. Until then, to customize the SQLClient instrumentation, add the OpenTelemetry.Instrumentation.SqlClient
package reference to your project and use its public API.
dotnet add package --prerelease OpenTelemetry.Instrumentation.SqlClient
builder.Services.AddOpenTelemetry().UseAzureMonitor().WithTracing(builder =>
{
builder.AddSqlClientInstrumentation(options =>
{
options.SetDbStatementForStoredProcedure = false;
});
});
Configure Azure Monitor
Application Insights offered many more configuration options via ApplicationInsightsServiceOptions
.
Application Insights Setting | OpenTelemetry Alternative |
---|---|
AddAutoCollectedMetricExtractor | N/A |
ApplicationVersion | Set "service.version" on Resource |
ConnectionString | See instructions on configuring the Connection String. |
DependencyCollectionOptions | N/A. To customize dependencies, review the available configuration options for applicable Instrumentation libraries. |
DeveloperMode | N/A |
EnableActiveTelemetryConfigurationSetup | N/A |
EnableAdaptiveSampling | N/A. Only fixed-rate sampling is supported. |
EnableAppServicesHeartbeatTelemetryModule | N/A |
EnableAuthenticationTrackingJavaScript | N/A |
EnableAzureInstanceMetadataTelemetryModule | N/A |
EnableDependencyTrackingTelemetryModule | See instructions on filtering Traces. |
EnableDiagnosticsTelemetryModule | N/A |
EnableEventCounterCollectionModule | N/A |
EnableHeartbeat | N/A |
EnablePerformanceCounterCollectionModule | N/A |
EnableQuickPulseMetricStream | AzureMonitorOptions.EnableLiveMetrics |
EnableRequestTrackingTelemetryModule | See instructions on filtering Traces. |
EndpointAddress | Use ConnectionString. |
InstrumentationKey | Use ConnectionString. |
RequestCollectionOptions | N/A. See OpenTelemetry.Instrumentation.AspNetCore options. |
Remove custom configurations
The following scenarios are optional and only apply to advanced users.
If you have any more references to the
TelemetryClient
, which could be used to manually record telemetry, they should be removed.If you added any custom filtering or enrichment in the form of a custom
TelemetryProcessor
orTelemetryInitializer
, they should be removed. They can be found in yourServiceCollection
.builder.Services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
builder.Services.AddApplicationInsightsTelemetryProcessor<MyCustomTelemetryProcessor>();
Remove JavaScript Snippet
If you used the Snippet provided by the Application Insights .NET SDK, it must also be removed. For full code samples of what to remove, review the guide enable client-side telemetry for web applications.
If you added the JavaScript SDK to collect client-side telemetry, it can also be removed although it continues to work without the .NET SDK. For full code samples of what to remove, review the onboarding guide for the JavaScript SDK.
Remove any Visual Studio Artifacts
If you used Visual Studio to onboard to Application Insights, you could have more files left over in your project.
Properties/ServiceDependencies
directory might have a reference to your Application Insights resource.
Tip
Our product group is actively seeking feedback on this documentation. Provide feedback to [email protected] or see the Support section.
Frequently asked questions
This section is for customers who use telemetry initializers or processors, or write custom code against the classic Application Insights API to create custom telemetry.
How do the SDK API's map to OpenTelemetry concepts?
OpenTelemetry is a vendor neutral observability framework. There are no Application Insights APIs in the OpenTelemetry SDK or libraries. Before migrating, it's important to understand some of OpenTelemetry's concepts.
In Application Insights, all telemetry was managed through a single
TelemetryClient
andTelemetryConfiguration
. In OpenTelemetry, each of the three telemetry signals (Traces, Metrics, and Logs) has its own configuration. You can manually create telemetry via the .NET runtime without external libraries. For more information, see the .NET guides on distributed tracing, metrics, and logging.Application Insights used
TelemetryModules
to automatically collect telemetry for your application. Instead, OpenTelemetry uses Instrumentation libraries to collect telemetry from specific components (such as AspNetCore for Requests and HttpClient for Dependencies).Application Insights used
TelemetryInitializers
to enrich telemetry with additional information or to override properties. With OpenTelemetry, you can write a Processor to customize a specific signal. Additionally, many OpenTelemetry Instrumentation libraries offer anEnrich
method to customize the telemetry generated by that specific component.Application Insights used
TelemetryProcessors
to filter telemetry. An OpenTelemetry Processor can also be used to apply filtering rules on a specific signal.
How do Application Insights telemetry types map to OpenTelemetry?
This table maps Application Insights data types to OpenTelemetry concepts and their .NET implementations.
Azure Monitor Table | Application Insights DataType | OpenTelemetry DataType | .NET Implementation |
---|---|---|---|
customEvents | EventTelemetry | N/A | N/A |
customMetrics | MetricTelemetry | Metrics | System.Diagnostics.Metrics.Meter |
dependencies | DependencyTelemetry | Spans (Client, Internal, Consumer) | System.Diagnostics.Activity |
exceptions | ExceptionTelemetry | Exceptions | System.Exception |
requests | RequestTelemetry | Spans (Server, Producer) | System.Diagnostics.Activity |
traces | TraceTelemetry | Logs | Microsoft.Extensions.Logging.ILogger |
The following documents provide more information.
- Data Collection Basics of Azure Monitor Application Insights
- Application Insights telemetry data model
- OpenTelemetry Concepts
How do Application Insights sampling concepts map to OpenTelemetry?
While Application Insights offered multiple options to configure sampling, Azure Monitor Exporter or Azure Monitor Distro only offers fixed rate sampling. Only Requests and Dependencies (OpenTelemetry Traces) can be sampled.
For code samples detailing how to configure sampling, see our guide Enable Sampling
How do Telemetry Processors and Initializers map to OpenTelemetry?
In the Application Insights .NET SDK, use telemetry processors to filter and modify or discard telemetry. Use telemetry initializers to add or modify custom properties. For more information, see the Azure Monitor documentation. OpenTelemetry replaces these concepts with activity or log processors, which enrich and filter telemetry.
Filtering Traces
To filter telemetry data in OpenTelemetry, you can implement an activity processor. This example is equivalent to the Application Insights example for filtering telemetry data as described in Azure Monitor documentation. The example illustrates where unsuccessful dependency calls are filtered.
using System.Diagnostics;
using OpenTelemetry;
internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (!OKtoSend(activity))
{
activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
}
}
private bool OKtoSend(Activity activity)
{
return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
}
}
To use this processor, you need to create a TracerProvider
and add the processor before AddAzureMonitorTraceExporter
.
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddProcessor(new SuccessfulDependencyFilterProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
Filtering Logs
ILogger
implementations have a built-in mechanism to apply log
filtering.
This filtering lets you control the logs that are sent to each registered
provider, including the OpenTelemetryLoggerProvider
. "OpenTelemetry" is the
alias
for OpenTelemetryLoggerProvider
, used in configuring filtering rules.
The following example defines "Error" as the default LogLevel
and also defines "Warning" as the minimum LogLevel
for a user defined category.
These rules as defined only apply to the OpenTelemetryLoggerProvider
.
builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);
For more information, please read the OpenTelemetry .NET documentation on logs.
Adding Custom Properties to Traces
In OpenTelemetry, you can use activity processors to enrich telemetry data with more properties. It's similar to using telemetry initializers in Application Insights, where you can modify telemetry properties.
By default, Azure Monitor Exporter flags any HTTP request with a response code of 400 or greater as failed. However, if you want to treat 400 as a success, you can add an enriching activity processor that sets the success on the activity and adds a tag to include more telemetry properties. It's similar to adding or modifying properties using an initializer in Application Insights as described in Azure Monitor documentation.
Here's an example of how to add custom properties and override the default behavior for certain response codes:
using System.Diagnostics;
using OpenTelemetry;
/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (activity.Kind == ActivityKind.Server)
{
int responseCode = GetResponseCode(activity);
if (responseCode >= 400 && responseCode < 500)
{
// If we set the Success property, the SDK won't change it
activity.SetStatus(ActivityStatusCode.Ok);
// Allow to filter these requests in the portal
activity.SetTag("Overridden400s", "true");
}
// else leave the SDK to set the Success property
}
}
private int GetResponseCode(Activity activity)
{
foreach (ref readonly var tag in activity.EnumerateTagObjects())
{
if (tag.Key == "http.response.status_code" && tag.Value is int value)
{
return value;
}
}
return 0;
}
}
To use this processor, you need to create a TracerProvider
and add the processor before AddAzureMonitorTraceExporter
.
using OpenTelemetry.Trace;
public static void Main()
{
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("Company.Product.Name")
.AddProcessor(new MyEnrichingProcessor())
.AddAzureMonitorTraceExporter()
.Build();
}
How do I manually track telemetry using OpenTelemetry?
Sending Traces - Manual
Traces in Application Insights are stored as RequestTelemetry
and DependencyTelemetry
. In OpenTelemetry, traces are modeled as Span
using the Activity
class.
OpenTelemetry .NET utilizes the ActivitySource
and Activity
classes for tracing, which are part of the .NET runtime. This approach is distinctive because the .NET implementation integrates the tracing API directly into the runtime itself. The System.Diagnostics.DiagnosticSource
package allows developers to use ActivitySource
to create and manage Activity
instances. This method provides a seamless way to add tracing to .NET applications without relying on external libraries, applying the built-in capabilities of the .NET ecosystem. For more detailed information, refer to the distributed tracing instrumentation walkthroughs.
Here's how to migrate manual tracing:
Note
In Application Insights, the role name and role instance could be set at a per-telemetry level. However, with the Azure Monitor Exporter, we cannot customize at a per-telemetry level. The role name and role instance are extracted from the OpenTelemetry resource and applied across all telemetry. Please read this document for more information: Set the cloud role name and the cloud role instance.
DependencyTelemetry
Application Insights DependencyTelemetry
is used to model outgoing requests. Here's how to convert it to OpenTelemetry:
Application Insights Example:
DependencyTelemetry dep = new DependencyTelemetry
{
Name = "DependencyName",
Data = "https://www.example.com/",
Type = "Http",
Target = "www.example.com",
Duration = TimeSpan.FromSeconds(10),
ResultCode = "500",
Success = false
};
dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);
OpenTelemetry Example:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
activity?.SetTag("url.full", "https://www.example.com/");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("http.request.method", "GET");
activity?.SetTag("http.response.status_code", "500");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Error);
activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}
RequestTelemetry
Application Insights RequestTelemetry
models incoming requests. Here's how to migrate it to OpenTelemetry:
Application Insights Example:
RequestTelemetry req = new RequestTelemetry
{
Name = "RequestName",
Url = new Uri("http://example.com"),
Duration = TimeSpan.FromSeconds(10),
ResponseCode = "200",
Success = true,
Properties = { ["customprop1"] = "custom value1" }
};
req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);
OpenTelemetry Example:
var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(resourceBuilder)
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
activity?.SetTag("url.scheme", "https");
activity?.SetTag("server.address", "www.example.com");
activity?.SetTag("url.path", "/");
activity?.SetTag("http.response.status_code", "200");
activity?.SetTag("customprop1", "custom value1");
activity?.SetStatus(ActivityStatusCode.Ok);
}
Custom Operations Tracking
In Application Insights, track custom operations using StartOperation
and StopOperation
methods. Achieve it using ActivitySource
and Activity
in OpenTelemetry .NET. For operations with ActivityKind.Server
and ActivityKind.Consumer
, Azure Monitor Exporter generates RequestTelemetry
. For ActivityKind.Client
, ActivityKind.Producer
, and ActivityKind.Internal
, it generates DependencyTelemetry
. For more information on custom operations tracking, see the Azure Monitor documentation. For more on using ActivitySource
and Activity
in .NET, see the .NET distributed tracing instrumentation walkthroughs.
Here's an example of how to start and stop an activity for custom operations:
using System.Diagnostics;
using OpenTelemetry;
var activitySource = new ActivitySource("Company.Product.Name");
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource(activitySource.Name)
.AddAzureMonitorTraceExporter()
.Build();
// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
activity?.SetTag("customTag", "customValue");
// Perform your custom operation logic here
// No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}
Sending Logs
Logs in Application Insights are stored as TraceTelemetry
and ExceptionTelemetry
.
TraceTelemetry
In OpenTelemetry, logging is integrated via the ILogger
interface. Here's how to migrate TraceTelemetry
:
Application Insights Example:
TraceTelemetry traceTelemetry = new TraceTelemetry
{
Message = "hello from tomato 2.99",
SeverityLevel = SeverityLevel.Warning,
};
traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);
OpenTelemetry Example:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();
// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);
internal static partial class LoggerExtensions
{
[LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
public static partial void FoodPrice(this ILogger logger, string name, double price);
}
ExceptionTelemetry
Application Insights uses ExceptionTelemetry
to log exceptions. Here's how to migrate to OpenTelemetry:
Application Insights Example:
ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
SeverityLevel = SeverityLevel.Error
};
exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);
OpenTelemetry Example:
var resourceAttributes = new Dictionary<string, object>
{
{ "service.name", "MyRole" },
{ "service.instance.id", "MyRoleInstance" }
};
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
using var loggerFactory = LoggerFactory.Create(builder => builder
.AddOpenTelemetry(logging =>
{
logging.SetResourceBuilder(resourceBuilder);
logging.AddAzureMonitorLogExporter();
}));
// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();
try
{
// Simulate exception
throw new Exception("Test exception");
}
catch (Exception ex)
{
// Emit exception: This uses the logger instance to write a new exception
logger?.LogError(ex, "An error occurred");
}
Sending Metrics
Metrics in Application Insights are stored as MetricTelemetry
. In OpenTelemetry, metrics are modeled as Meter
from the System.Diagnostics.DiagnosticSource
package.
Application Insights has both non-pre-aggregating (TrackMetric()
) and preaggregating (GetMetric().TrackValue()
) Metric APIs. Unlike OpenTelemetry, Application Insights has no notion of Instruments. Application Insights has the same API for all the metric scenarios.
OpenTelemetry, on the other hand, requires users to first pick the right metric instrument based on the actual semantics of the metric. For example, if the intention is to count something (like the number of total server requests received, etc.), OpenTelemetry Counter should be used. If the intention is to calculate various percentiles (like the P99 value of server latency), then OpenTelemetry Histogram instrument should be used. Due to this fundamental difference between Application Insights and OpenTelemetry, no direct comparison is made between them.
Unlike Application Insights, OpenTelemetry doesn't provide built-in mechanisms to enrich or filter metrics. In Application Insights, telemetry processors and initializers could be used to modify or discard metrics, but this capability isn't available in OpenTelemetry.
Additionally, OpenTelemetry doesn't support sending raw metrics directly, as there's no equivalent to the TrackMetric()
functionality found in Application Insights.
Migrating from Application Insights to OpenTelemetry involves replacing all Application Insights Metric API usages with the OpenTelemetry API. It requires understanding the various OpenTelemetry Instruments and their semantics.
Tip
The histogram is the most versatile and the closest equivalent to the Application Insights GetMetric().TrackValue()
API. You can replace Application Insights Metric APIs with Histogram to achieve the same purpose.
Other Telemetry Types
CustomEvents
Not supported in OpenTelemetry.
Application Insights Example:
TelemetryClient.TrackEvent()
AvailabilityTelemetry
Not supported in OpenTelemetry.
Application Insights Example:
TelemetryClient.TrackAvailability()
PageViewTelemetry
Not supported in OpenTelemetry.
Application Insights Example:
TelemetryClient.TrackPageView()
Can I get live metrics for console and worker service applications?
We recommend the Azure Monitor OpenTelemetry Exporter for console and worker service applications, which does not include live metrics.
Next steps
Tip
Our product group is actively seeking feedback on this documentation. Provide feedback to [email protected] or see the Support section.
Support
- For Azure support issues, open an Azure support ticket.
- For OpenTelemetry issues, contact the OpenTelemetry .NET community directly.
- For a list of open issues related to Azure Monitor Exporter, see the GitHub Issues Page.