CSharpEssentials.LoggerHelper is a modular, centralized hub for Serilog sinks that delivers comprehensive observability
. Its flexible JSON‑based configuration lets you decide which log levels go to which sink—for example, routing only Error messages to email while sending all logs to ElasticSearch—without touching your code
. The package unifies logs, metrics and traces via OpenTelemetry; every log entry carries a trace_id to correlate distributed requests, and an interactive dashboard lets you visualize traces, sink failures and telemetry, and configure alerts
. Standard structured fields (e.g., IdTransaction, ApplicationName, MachineName, Action) are included by default, and you can enrich logs with custom properties that propagate across all sinks
. Each sink—Console, File, MSSQL, PostgreSQL, ElasticSearch, Email, Telegram, xUnit, Telemetry, Dashboard and AI—is delivered as a separate NuGet package, so you install only what you need; the core loads them dynamically and exposes CurrentError and an in‑memory Errors queue to simplify debugging
. The latest AI integration enables natural‑language queries against logs, trace correlation for root‑cause analysis, anomaly detection and automatic incident summaries
, while the new xUnit sink captures full traces of failed tests directly in your test output—ideal for debugging flaky tests or disconnected environments
A flexible and modular structured logging library for .NET ( 6.0/8.0 ) applications based on Serilog. Easily configure logging to Console, File, Email, PostgreSQL, ElasticSearch via simple JSON configuration. Includes automatic placeholder validation and multi-sink orchestration.
It allows you to:
Send structured logs with guaranteed fields like Action, IdTransaction, ApplicationName, MachineName
Dynamically enable multi-sink support (Console, File, HTML Email, PostgreSQL, ElasticSearch)
Automatically validate message {} placeholders
Centralize configuration through LoggerBuilder, just by editing the appsettings.json file
In common usage scenarios, it is advisable to avoid logging Information level events to sinks like Telegram, MSSQL, or PostgreSQL. This practice prevents issues such as HTTP 429 (rate limits) on Telegram and reduces risks of deadlocks or insufficient storage in database systems.
Starting from version 2.0.0, LoggerHelper no longer uses the standard Serilog.Sinks.Email for sending emails.
Reason:
The official Serilog Email Sink does not support custom body formatting (HTML templates, structured logs, color coding, etc).
It only supports plain text messages generated via RenderMessage(), without the ability to control the message content.
⚠️ Important:
The logger will only write to a sink if the Level array in SerilogCondition contains at least one valid log level (e.g., "Error", "Warning").
If the Level array is empty (e.g., "Level": []), that sink will be ignored, and WriteTo** will not be applied**, even if the sink configuration exists.
🧩 PostgreSQL is preconfigured with a default column mapping for logs. The following columns are used automatically:
message, message_template, level, raise_date, exception, properties, props_test, machine_name. No custom mapping is required in the JSON.
📌 Log Levels
🖼️ Example of a Telegram-formatted log message:
💬 Telegram Notice: When using the Telegram sink, log messages are formatted for human readability, and may include emojis or markdown. For this reason, it's strongly recommended to set the Level to only Error or Fatal to avoid exceeding Telegram's rate limits and to prevent excessive message noise.
🛠 Tip: Before publishing to production, test each sink you plan to use. You can enable Serilog self-logging to capture internal errors using:
Replace logPath with your local or shared log directory. This helps identify misconfigurations or sink loading issues early.
Each sink only receives log levels specified in the SerilogCondition array. If a sink's Level array is empty, that sink will be ignored entirely, and no log will be written to it, even if it's configured elsewhere:
Sink
Levels
Console
Information, Warning, Error, Fatal
File
Error, Fatal
PostgreSQL
Error, Fatal
MSSqlServer
Error, Fatal
Telegram
Fatal
Elasticsearch
(disabled)
🧪 ASP.NET Core Setup
Request/Response Logging Middleware
The LoggerHelper package includes a built-in middleware that logs every incoming HTTP request and outgoing response automatically. It captures:
📌 This middleware uses LogEventLevel.Information by default and is automatically compatible with sinks that accept that level.
🔥 Register the logger in Program.cs
🚀 Important Setup
⚠️ IMPORTANT:
You must call AddLoggerConfiguration during the Program.cs setup.
Without it, LoggerHelper will NOT work.
No logs will be captured, and no middleware will be active.
ℹ️ Important: depending on the target framework version, you must configure LoggerHelper differently.
If you are using .NET 6.0, you must call the configuration directly on the builder.
If you are using .NET 8.0, you must call it on the builder.Services.
Here’s how you should do it:
using CSharpEssentials.LoggerHelper;
var builder = WebApplication.CreateBuilder(args);
// Add LoggerHelper configuration
#if NET6_0
builder.AddLoggerConfiguration();
#else
builder.Services.AddLoggerConfiguration(builder);
#endif
builder.Services.AddControllers();
var app = builder.Build();
// Logs every HTTP request and response
app.UseMiddleware<RequestResponseLoggingMiddleware>();
app.MapControllers();
app.Run();
🧠 Explanation
Target Framework
Usage
.NET 6.0
builder.AddLoggerConfiguration();
.NET 8.0
builder.Services.AddLoggerConfiguration(builder);
This ensures full compatibility across different .NET versions.
