Configuration
An overview of configuration options for monitoring in Altinn Apps.
The new monitoring and instrumentation setup is enabled by setting UseOpenTelemetry
to true
in appsettings.json or equivalent.
{
"AppSettings": {
"UseOpenTelemetry": true
}
}
When this flag is enabled, OTel is configured as opposed to the classic Application Insights SDK. All the telemetry is then shipped by default to the local monitoring setup with running locally, and to Azure Monitor when the app is deployed in an environment. Optionally, if an instrumentation key or Application Insights connection string is added to AppSettings or environment locally, Altinn.App will ship the telemetry to Azure Monitor. When the app is run, you will both get auto-instrumentation based on HTTP (traces and metrics), but also manual trace spans and metrics that are domain specific.
The next sections will describe customizing the OpenTelemetry SDK and migrating from Application Insights. On the next page, there is information on automatic and manual instrumentation.
Configuring the OpenTelemetry SDK
If you need to customize OTel in any way, you can use the extension methods below to get the appropriate provider-builder from the OTel SDK. This is relevant if you
- Need custom enrichment
- Customize sampling
- Need to export telemetry to a different backend
In this case, the configuration only adds an additional exporter (ConsoleExporter
) to the respective provider-builders.
First, we update the App.csproj
file:
<PackageReference Include="OpenTelemetry.Exporter.Console" Version="1.9.0" />
Then we update the configuration code in Program.cs
:
using OpenTelemetry.Logs;
using OpenTelemetry.Metrics;
using OpenTelemetry.Trace;
void RegisterCustomAppServices(IServiceCollection services, IConfiguration config, IWebHostEnvironment env)
{
// Configure exporters for telemetry signals (metrics, traces and logging).
// Here console exporters are used for demonstration purposes.
// This could also ship your telemetry to a custom backend.
services.ConfigureOpenTelemetryMeterProvider(builder =>
builder.AddConsoleExporter(
(_, readerOptions) =>
{
// Lower the export interval so that we get metrics more often
readerOptions.PeriodicExportingMetricReaderOptions.ExportIntervalMilliseconds = 5_000;
readerOptions.PeriodicExportingMetricReaderOptions.ExportTimeoutMilliseconds = 4_000;
}
)
);
services.ConfigureOpenTelemetryTracerProvider(builder =>
{
// Customize sampling
builder.SetSampler(new ParentBasedSampler(new AlwaysOnSampler()));
builder.AddConsoleExporter();
});
services.ConfigureOpenTelemetryLoggerProvider(builder => builder.AddConsoleExporter());
}
To learn more about what can be configured, read the respective docs on the opentelemetry-dotnet repo:
- Customizing OpenTelemetry .NET SDK for Tracing
- Customizing OpenTelemetry .NET SDK for Logs
- Customizing OpenTelemetry .NET SDK for Metrics
Migration from classic Application Insights SDK
Microsoft have documented that
The long-term plan for Application Insights is to collect data using OpenTelemetry.
Which means that the classic SDK that we now use is likely to be deprecated at some point. It is therefore recommended to migrate when possible, by following the instructions above.
Telemetry initializers and processors need to be migrated to the respective OTel abstractions.
Application Insights | OpenTelemetry |
---|---|
ITelemetryInitializer | Processor |
ITelemetryProcessor | Processor |
Considerations
- Both OTel and App Insights SDK use W3C Trace-Context propagation by default for distributed traces, so correlation across systems should still work during a migration