CODEWITHSUNDEEP
asp.net-coreserilog
Vida
Vida

Reputation: 109

Serilog not logging to Console

I have installed: Serilog.sink.console in my asp.net core web project. I have the below set up to use serilog when I call the Microsoft.Extension.Logging ILogger:

.UseSerilog((context, loggerConfiguration) => loggerConfiguration
    .ReadFrom.Configuration(context.Configuration))

I have the following settings to log to Console in my appsettings.json:

  "Serilog": {
    "MinimumLevel": "Error",
    "WriteTo": [
      {
        "Name": "Console"
      }
    ]

Below is how I try to log to console:

    private readonly ILogger _logger; // using Microsoft.Extensions.Logging

    public SalesTransaction(ILogger<Sales> logger)
    {
        _logger = logger;
    }
        Console.WriteLine("XXX");
        _logger.LogError("This is an Error");

I cannot find where the Console/STDOut is logged. Note that if I use WriteTo File settings and specify a directory, it works fine.

Upvotes: 3

Views: 13034

Answers (3)

foxfuzz
foxfuzz

Reputation: 105

I had a similar problem with my console application. Using Serilog.AspNetCore with Serilog.Sinks.Console and Serilog.Sinks.File NuGet libraries, I had the using config set as:

"Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ],

and everything was sent to the file without any logs to the console. Only on removing File Sink from using, but leaving it in the WriteTo object, logging worked to write both on the console and log file.

To edit OP's settings, this would work:

  "Serilog": {
    "Using": [ "Serilog.Sinks.Console" ],
    "MinimumLevel": "Error",
    "WriteTo": [
      { "Name": "Console" },
      {
        "Name": "File",
        "Args": {
          "path": "C:\\Temp\\Logs\\log.txt",
          "rollingInterval": "Day"
        }
      }
    ]
  }

Documentation on GitHub for Serilog.AspNetCore library.
Documentation on GitHub for Serilog.Settings.Configuration

Upvotes: 1

Mehmet Akin
Mehmet Akin

Reputation: 1

  "Serilog": {
    "Using": [
      "Serilog.Sinks.Console"
    ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "Console"
      },
    ],
    "Properties": {
      "Application": ""
    }
  }

Upvotes: 0

Panagiotis Kanavos
Panagiotis Kanavos

Reputation: 131712

Essentially, an application's console is the command-line window you used to launch the application. Anything written to it is lost unless you redirect it to a file. (In reality it's a bit more complex).

If you run the web site from the console/Windows Terminal/Bash, anything written to the console will appear in the terminal. If you use IIS, the logs are lost, unless you change the web.config settings to write SDTOUT output to a file. This is described in Log creation and redirection. The default web.config file generated when publishing an ASP.NET Core application contains this element:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile=".\logs\stdout"
    hostingModel="inprocess">
</aspNetCore>

By default, STDOUT output isn't stored anywhere. Setting stdoutLogEnabled to true will redirect the output to the logs\stdout folder under the application's root. The linked article explains how to filter by level or redirect to the Event log too.

Logging in general

You should use a file sink for production logging, (ie WriteTo.File). This allows you customize file names, formats, use rolling files, specify maximum file sizes and automatically delete old files. Console logging doesn't even know about files, and the formatting options are far more limited.

Console logging is useful for troubleshooting and, under certain conditions, for basic logging in container/Kubernetes environments. All processes have an STDIN, STDOUT and STDERR stream. Errors written to STDERR are redirected to STDOUT by default :

  • It's always available, everywhere, even during startup. Any errors that prevent the application from starting will be written there.
  • It's available before the web host or Serilog starts.
  • You can use it to troubleshoot Serilog problems, with SelfLog, using Serilog.Debugging.SelfLog.Enable(Console.Error);.
  • Docker and Kubernetes collect the STDOUT output from containers/pods, making it available for inspection. A lot of designs depend on this, eg using a sidecar container to read and process the application's logs without modifying the application itself.

Upvotes: 5

Related Questions