What is the advantage of using intermediary layer (OpenTelemetry) instead directly ApplicationInsights?
For example:
builder.Services.AddOpenTelemetry().UseAzureMonitor();
instead of
builder.Services.AddApplicationInsightsTelemetry();
There already is logging abstraction built in .NET (ILogger, ILoggerProvider), which allows to easily switch to different logging libraries without changing application code, so I'm missing the point of the OpenTelemetry layer here.
For .NET specifically, Azure Monitor Open Telemetry SDK (Distro) is the future replacement of Application Insights SDK. With all new development happening in the former.
There are a few benefits of using it:
App is instrumented with open standard (Azure Monitor part is the exporter which actually sends data to Azure Monitor). It means that if a need arises then it will be more straightforward to migrate to other telemetry providers / clouds.
More and more SDKs use Open Telemetry API to emit telemetry. It means that by using Azure Monitor Open Telemetry (compared to Application Insights SDK) these signals will be automatically picked up.
Note, as of today, Open Telemetry defines only instrumentation and exporter part. It does not prescribe how data is stored and consumed.
Azure Monitor Open Telemetry data lands in Application Insights and can be consumed exactly the same way as data from Application Insights SDKs.
There is work happening to expose consumption schema which is more aligned with Open Telemetry. For instance, today, there is a division on requests and dependencies in Application Insights while in Open Telemetry they are considered spans. Application Insights will provide both consumption schemas and for each it will not matter how data is emitted (i.e., if one app is instrumented with Application Insights SDK and another with Azure Monitor Open Telemetry - then it will be possible to use both classic and Open Telemetry schemas. So, from consumption perspective there will be no difference.