AI OnAI Off

Understanding Serilog vs Application Insights Log Levels in Optimizely

Sunil
Sunil
Vote:
 

Hi everyone,

I'm trying to better understand how logging configuration works in an Optimizely CMS 12 application using Serilog and Application Insights.

Below is a simplified version of our current configuration:

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Console" ],
    "MinimumLevel": {
      "Default": "Warning",
      "Override": {
        "Microsoft": "Warning",
        "Microsoft.AspNetCore": "Warning",
        "System": "Warning"
      }
    }
  },

  "Logging": {
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information",
        "Microsoft": "Warning",
        "Microsoft.Hosting.Lifetime": "Information"
      }
    }
  }
}

Based on this configuration, my understanding is:

  • Serilog is configured with a minimum level of Warning
  • Therefore, only Warning, Error, and Critical logs should be emitted by Serilog
  • This matches what I'm currently seeing in Application Insights (warnings and errors only)

However, in several places in our application we are writing logs like:

_logger.LogInformation("Customer {CustomerId} updated profile", customerId);

These Information logs do not appear in Application Insights.

My questions are:

  1. Is this expected because Serilog's MinimumLevel.Default is set to Warning?
  2. If I want to start seeing Information logs in Application Insights, do I need to change:
    • Serilog:MinimumLevel:Default to Information
    • OR Logging:ApplicationInsights:LogLevel:Default to Information
    • OR both?
  3. Which configuration takes precedence when both Serilog and Application Insights logging settings are present?
  4. What is the exact purpose of the following Serilog override section?
"Override": {
  "Microsoft": "Warning",
  "Microsoft.AspNetCore": "Warning",
  "System": "Warning"
}

My assumption is that these overrides suppress framework-generated logs while allowing application logs to follow the Default level, but I'd like to confirm that understanding.

Has anyone configured Optimizely CMS / Commerce applications with Serilog and Application Insights and can explain how these settings interact?

Additional Question

One more thing I'm trying to understand:

If Information logs are already being generated by the application, is there a way to verify whether they exist in Application Insights even if they're not visible in the standard Logs/Failures views?

For example:

  • Can I use any specific queries to check whether Information logs are being ingested?
  • Is there a specific table (traces, AppTraces, etc.) that I should query?
  • Is there a way to determine whether the logs were filtered out by Serilog before reaching Application Insights versus being stored but hidden by the current view/filter settings?



Thanks in advance!

#342688
Edited, Jun 01, 2026 15:23
Scott Reed
Scott Reed
Vote:
 

Adding the answer that we covered from Slack just for visibility. 

Scott Reed (Optimizely MVP)  [12:55 PM]

Here is a breakdown of how Serilog and Application Insights interact in the Optimizely DXP environment, and why your Information logs are currently missing.
1. The Filtering Pipeline: Why Information Logs are Missing
Yes. Because Serilog’s minimum level is set to Warning, your Information logs are being discarded before they ever reach Application Insights.
When you use Serilog as your primary logging provider in an Optimizely CMS application, it effectively takes over the .NET logging pipeline. The interaction flows like this:
  1. Log Generation: Your code calls _logger.LogInformation("...");.
  2. Serilog Ingestion: The log entry enters the Serilog pipeline. Serilog checks its global MinimumLevel. Since it is set to Warning, Serilog immediately drops any Information level logs.
  3. Sink Distribution: Serilog only forwards logs that pass its filter (Warning, Error, Fatal) to its configured sinks—including the Application Insights Sink.
  4. App Insights Filtering: The Logging:ApplicationInsights:LogLevel:Default = Information setting is part of the native Microsoft logging configuration. Because Serilog is overriding the pipeline, this secondary filter is only evaluating the logs that Serilog actually passes to it.
Because Serilog dropped the Information logs at Step 2, Application Insights never receives them to begin with.
2. How to Enable Information Logs
To start seeing Information logs in Application Insights, you must change the Serilog configuration.
You should update your setup to the following: JSON

{ "Serilog": { "MinimumLevel": { "Default": "Information" } } }
Do you need to change both?
If you change Serilog's default to
Information, and your Logging:ApplicationInsights configuration is already at Information, you will start seeing those logs.
However, in a standard Serilog setup utilizing the Application Insights sink, it is highly recommended to control the filtering entirely within Serilog to avoid confusion. You can specify the minimum level directly for the sink if your Serilog package supports it, but simply opening the main gate in Serilog to Information will solve your immediate issue.
3. The Purpose of Microsoft and System Overrides
If you change the global default to Information, your logs will quickly become flooded with framework-level noise. This is where Overrides come in.
Overrides allow you to keep your application's custom logs at a granular level (Information), while keeping noisy framework telemetry quiet (Warning or Error).
Common Practical Use Cases:
  • Microsoft.AspNetCore: Controls logs for every single HTTP request, routing decision, and middleware execution. Setting this to Warning prevents your App Insights from being flooded with standard 200 OK request logs.
  • Microsoft / System: Controls internal .NET framework behavior, dependency injection lifetime events, and configuration loading.
  • EPiServer: In an Optimizely DXP context, you can use overrides specifically for the CMS. For example, you might want your own code at Information, but keep EPiServer at Warning to avoid logging routine CMS background tasks, initialization steps, or content loading telemetry unless something goes wrong.
A balanced production configuration for Optimizely DXP usually looks something like this: JSON

{ "Serilog": { "MinimumLevel": { "Default": "Information", "Override": { "Microsoft": "Warning", "Microsoft.AspNetCore": "Warning", "EPiServer": "Warning", "System": "Warning" } } } }
4. Verifying Ingestion Before Changing Configuration
If you want to absolutely verify if
any Information logs are making it through before you deploy a configuration change, you can query your App Insights instance directly using Kusto Query Language (KQL) in the Azure Portal.
Go to your Application Insights resource, open Logs, and run the following query:
Code snippet

traces | where severityLevel == 1 | take 50
Severity Level Reference:
  • 0 : Verbose / Debug
  • 1: Information
  • 2: Warning
  • 3: Error
  • 4: Critical
If this query returns zero results for your specific cloud environment, it confirms that the pipeline is completely blocking them at the application level, and a configuration change to Serilog:MinimumLevel:Default is required.
 
Sunil Kumar (OMVP)  [1:17 PM]
Thanks @Scott Reed (Optimizely MVP) for the explanation — it's much clearer now.
I do have one follow-up question though.
Based on your explanation, my understanding is that Serilog is filtering out the application's Information logs before they are sent to Application Insights. However, when I run the following query in Application Insights:
traces | where severityLevel == 1
I still see a number of Information-level entries. The two messages I consistently see are:
  • StopProfiler triggered.
  • StopProfiler succeeded.
Do you have any idea where these logs are coming from?
I'm wondering whether these are being generated by:
  • Optimizely itself,
  • Application Insights SDK,
  • MiniProfiler,
  • or some other framework component that bypasses the Serilog filtering pipeline.
Just trying to better understand why these Information logs are still appearing while my application's LogInformation() entries are not.

Thanks again for your help!
Scott Reed (Optimizely MVP)  [1:19 PM]
They're coming from the Application Insights SDK. They are being logged directly and not going through your logging pipeline, so therefore that's why they are appearing. You can filter them out though if you need.
Just create a ITelemetryProcessor for any event you don't want AI to log. I personally actually use this myself to stop loads of dependency, worthless data from being logged in Application Insights.
I use this to implement a core standard to enhance my SQL messages and also remove all of the random dependency noise to reduce my log levels as low as possible, so only the specific messages that I want logged through Application Insights are logged. It made it a lot easier to debug and view information when looking at the traces
Sunil Kumar (OMVP)  [3:00 PM]
Great, thanks @Scott Reed (Optimizely MVP) it helps allot.
#342705
Jun 04, 2026 12:37
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.