Structured Logging

Applies to version: 2026.1.x and above; author: Grzegorz Straś

 

Related documentation

A detailed description of the functionalities mentioned herein and their configuration can be found in the following sections of the WEBCON Help:

• Administration tools
• Diagnostic sessions
• Diagnostics
• Services configuration

Other related Community articles include:

• OpenTelemetry in WEBCON 2026 R1

 

Introduction

In version 2026R1, the method of error logging has been changed from traditional text-based logs (NLog) to structured logging based on Serilog. This modernization significantly improves the quality, readability, and analytical capabilities of logs in the system.

• The main goal of migrating to structured logging is to modernize the logging technology and enable advanced, machine-readable log processing. Serilog stores data in key–value format, which greatly facilitates analysis and searching.
• The ErrorGuid parameter has been replaced with CorrelationID - a consistent identifier for tracking events.
• Logging configuration is located in the appsettings.json file within the installation directory of the Portal and Service.
• Serilog supports the OpenTelemetry standard, enabling unified log transmission, correlation, and processing across various tools.
• Tools compatible with OpenTelemetry can be configured in the Exporters section of appsettings.json.
• Thanks to OpenTelemetry, logs are linked with diagnostic data (Traces) and metrics (Metrics), which simplifies analysis and monitoring.
• The database structure has been updated to allow storing log objects — existing behavior remains unchanged.
• Log content is now standardized, as logs are no longer based on a rigid text formula but on structured data.

 

Example of a Structured Log

Standardized content offers more clarity compared to rigid text formulas.

{
  "Name": "WebCon.Workflow.Module.Identity.AccountController",
  "MessageTemplate": "Incorrect password for user '{UserLogin}'.",
  "UserLogin": "t.green",
  "ClientIP": "192.168.1.0",
  "CorrelationId": "a987763c-3e5c-42eb-bade-76a6e35cb3df"
}

 

Examples of Popular Sinks

Serilog allows logs to be sent to multiple destinations simultaneously using sinks. In a default WEBCON installation, the appsettings.json file contains nodes corresponding to these sinks.

MSSQL

The default log storage for WEBCON. In a fresh installation, logs are stored in the Infrastructure.Logs table in the Configuration Database.

Like other sinks and exporters, this is fully configurable. It is possible (and recommended for larger systems) to store logs in a separate dedicated MSSQL database.

"MSSqlServerSink": {
  "Name": "MSSqlServer",
  "Args": {
    "connectionString": "LogsDb",
    "tableName": "Logs",
    "schemaName": "infrastructure",
    "autoCreateSqlTable": true,
    "restrictedToMinimumLevel": "Warning"
  }
}

 

File

A file created in a specified location. By default, fatal logs (critical errors preventing the system from starting) are written here.

"FileSink": {
  "Name": "File",
  "Args": {
    "path": "Logs/log-.txt",
    "rollingInterval": "Day",
    "outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss} [{Level:u3}] {Message:lj}{NewLine}{Exception}",
    "restrictedToMinimumLevel": "Fatal"
  }
}

 

OpenTelemetry

Any tools using the OpenTelemetry standard. Different tools may support different combinations of Metrics/Traces/Logs depending on requirements and preferences. Tools can also interoperate; for example, logs sent to Loki can be visualized using Grafana.

Multiple OpenTelemetry exporters can also be active at the same time, and receive logs simultaneously. Thanks to modularity, the configuration can be easily adapted to the size of the environment and operational needs.

More information is available in the article on the OpenTelemetry standard.

• Seq
• Loki
• Grafana
• Prometheus

"OpenTelemetry": {
  "Logs": {
    "Enabled": true,
    "Exporters": {
      "Loki": {
        "Enabled": true,
        "Endpoint": "http://localhost:3110/otlp/v1/logs",
        "Protocol": "http"
      },
      "Seq": {
        "Enabled": true,
        "Endpoint": "http://localhost:5432/ingest/otlp/v1/logs",
        "Protocol": "http"
      }
    }
  }
}

 

A Few Words About the MSSQL Database

• While Serilog supports logging to MSSQL, we recommend using this option carefully - especially in large environments.
• The MSSQL configuration database may become overloaded with high log volume, which can affect the overall performance of the WEBCON system.
• In large environments, using a dedicated MSSQL database or dedicated sinks is recommended.
• The downside of moving logs out of the Configuration Database is that they will no longer be searchable directly from Designer Studio.

 

Loggers

In the configuration of individual nodes, it is possible to override the minimum log level for specific loggers.
For example, for a selected WEBCON module (1), you can change the level to Information or Verbose (2), allowing detailed troubleshooting. Log levels and their default values are described below.

In WEBCON, loggers correspond to specific system areas, allowing you to isolate logs for the module you are interested in.

List of areas and loggers (partial; it will be updated continuously)

 

You're not limited to system loggers only - you can also use loggers provided by Microsoft, such as Microsoft.Extensions.Logging, which allows tracking other parameters (e.g., execution duration for selected operations).

 

Log Levels

Different logging levels allow tracking system events with varying detail. The more detailed the level, the more logs and the higher the performance cost.
However, using detailed levels only for selected loggers enables in-depth analysis of specific areas.

• Verbose – the most detailed and least-used level; useful for debugging complex scenarios.
• Debug – detailed information helpful in troubleshooting in test environments.
• Information – general system events (e.g., validations, execution flow).
• Warning – unexpected events that do not interrupt operations; the default MinimumLevel in appsettings.json.
• Error – errors that interrupt the current operation but do not stop the entire application.
• Fatal – critical errors preventing the system from operating (e.g., Portal startup failure).

 

Where Are Logs Stored by Default?

In a new WEBCON installation, configuration nodes define the default minimal log level and default log destinations.

• Configuration is located in the WriteTo section of appsettings.json.
• Fatal logs are written to a file in the logs folder (as configured).
• Logs at Warning level and above are stored in the MSSQL database defined in the MSsqlServer node (by default, the Infrastructure.Logs table in the Configuration Database).
• IIS logs are stored in the Inetpub folder.
• EventLog includes logs at Error level and above.

 

Future Changes

The changes introduced in version 2026R1 are only the first step in modernizing the logging system.

Due to the significant number of required updates, not all areas of the system are yet covered by the new standard - some loggers still write data to their previous tables.

In future versions, these will also be replaced by Serilog-based logging, and the amount of data written to legacy tables will gradually decrease until they are fully phased out.

Information about these plans will be available in the Roadmap.

At this moment, the following remain unchanged:

• logging by the Service — AdminWfEventLogs, Event Viewer, etc.
• diagnostic sessions
• REST API and UDA logs

 

Summary

• Logs are fully searchable

Each entry contains structured fields (e.g., CorrelationID, UserLogin), allowing analytical tools to filter and aggregate results far more effectively than with text logs.

• Improved system observability

Structured logs allow easy dashboard creation, trend analysis, event correlation, and reporting — especially when integrated with Seq, Elasticsearch, Grafana, or Application Insights.

• Integration with the OpenTelemetry ecosystem

Combining logs with metrics and traces provides a complete view of system behavior and significantly accelerates diagnostics.

• Unified log structure

Regardless of where an error originates, logs share a consistent schema, simplifying analysis and automated processing.

• Reduced noise and improved efficiency

Structured logging reduces repetitive text and improves the performance of log storage mechanisms.