Hi, this is Mike Rousos from the .NET Customer Success Team. I'm going to talk today briefly about logging in ASP.NET Core.
Hi, this is Mike Rousos from the .NET Customer Success Team. I'm going to talk today briefly about logging in ASP.NET Core.

So, if you have an ASP.NET Core app and you want to log some diagnostics,
So, if you have an ASP.NET Core app and you want to log some diagnostics,

you're typically going to be using the Microsoft.Extensions.Logging package. Let me hop over to NuGet and show that to you.
you're typically going to be using the Microsoft.Extensions.Logging package. Let me hop over to NuGet and show that to you.

Microsoft.Extensions.Logging is what you're looking for.
Microsoft.Extensions.Logging is what you're looking for.

You won't have to install this, typically, because it's already included in the package references for all of our ASP.NET Core
You won't have to install this, typically, because it's already included in the package references for all of our ASP.NET Core

templates, but this is the package that you use and, like all, Microsoft.Extensions packages,
templates, but this is the package that you use and, like all, Microsoft.Extensions packages,

there's nothing in here specific to ASP.NET Core. This just
there's nothing in here specific to ASP.NET Core. This just

depends on .NET Standard 1.1, so you could just as easily
depends on .NET Standard 1.1, so you could just as easily

use this logging framework in a .NET Core console app, .NET Framework app, UWP, just the same as you would in
use this logging framework in a .NET Core console app, .NET Framework app, UWP, just the same as you would in

ASP.NET Core.
ASP.NET Core.

But, coming back to how it works in ASP.NET Core,
But, coming back to how it works in ASP.NET Core,

when you look at your ASP.NET Core app, you'll notice that in the templates our configure method in Startup.cs
when you look at your ASP.NET Core app, you'll notice that in the templates our configure method in Startup.cs

will take an ILoggerFactory. This logger factory is what produces logger objects which we use to log events.
will take an ILoggerFactory. This logger factory is what produces logger objects which we use to log events.

In the configure method, though, we need to set it up with all of the providers we want to use
In the configure method, though, we need to set it up with all of the providers we want to use

for writing those logged messages to different endpoints. Now, one of the great things about the Microsoft.Extensions.Logging framework
for writing those logged messages to different endpoints. Now, one of the great things about the Microsoft.Extensions.Logging framework

used in ASP.NET Core is its flexibility and its extensibility.
used in ASP.NET Core is its flexibility and its extensibility.

By default, you'll have an .AddDebug which adds a debug provider so that we write to debug output.
By default, you'll have an .AddDebug which adds a debug provider so that we write to debug output.

And you typically also have an .AddConsole
And you typically also have an .AddConsole

as well in your
as well in your

template that you start with and this will just write debug
template that you start with and this will just write debug

diagnostic messages out to the console output, of course.
diagnostic messages out to the console output, of course.

But when you look at these, these are extension methods AddConsole, AddDebug.
But when you look at these, these are extension methods AddConsole, AddDebug.

And they're just extension methods that wrap ILoggerFactory.AddProvider
And they're just extension methods that wrap ILoggerFactory.AddProvider

which adds an IloggerProvider.
which adds an IloggerProvider.

So you could very easily go out and write your own ILoggerProvider for any endpoint
So you could very easily go out and write your own ILoggerProvider for any endpoint

you want although you probably don't need to because someone else already has
you want although you probably don't need to because someone else already has

most likely and I'll show you some of the many options here later in this video.
most likely and I'll show you some of the many options here later in this video.

But in your configure method, you add the providers, the logging syncs that you're going to be using. Now you notice that
But in your configure method, you add the providers, the logging syncs that you're going to be using. Now you notice that

typically, we'll say, you know, if it's not development, we'll do one set of things (which would not be this) and then if it
typically, we'll say, you know, if it's not development, we'll do one set of things (which would not be this) and then if it

is a development environment, then maybe we'll hook up some more which I'll talk about in a minute.
is a development environment, then maybe we'll hook up some more which I'll talk about in a minute.

But you want to do this sort of per-environment
But you want to do this sort of per-environment

configuration of your logging providers because logging can have a performance hit.
configuration of your logging providers because logging can have a performance hit.

Some logging providers like ETW log providers are fairly fast, especially if you're only logging high-priority
Some logging providers like ETW log providers are fairly fast, especially if you're only logging high-priority

messages. But pretty much any console
messages. But pretty much any console

log provider is going to slow things down.
log provider is going to slow things down.

Some others that don't batch
Some others that don't batch

can be slow. So you want to be cautious with how much logging you do in production. You want to kind of
can be slow. So you want to be cautious with how much logging you do in production. You want to kind of

keep it to just the minimum batching
keep it to just the minimum batching

providers which
providers which

don't write out to the console.
don't write out to the console.

But, anyhow, you come in here, you hook these up, and typically there's some sort of configuration you have to do.
But, anyhow, you come in here, you hook these up, and typically there's some sort of configuration you have to do.

There's not with the debug provider because it just writes to the debug output
There's not with the debug provider because it just writes to the debug output

but like when we add console, you can choose some options like
but like when we add console, you can choose some options like

what the minimum level of messages you'd like to log or whether or not to include scopes and scopes are
what the minimum level of messages you'd like to log or whether or not to include scopes and scopes are

the path of
the path of

sort of where you are in your app so you can push scopes and
sort of where you are in your app so you can push scopes and

say, "Okay now we're in this this type or this method," and ASP.NET Core
say, "Okay now we're in this this type or this method," and ASP.NET Core

will use this to indicate which API is serving your request, for example.
will use this to indicate which API is serving your request, for example.

But most commonly you'll just use something from configuration because most providers, like the console provider, can be
But most commonly you'll just use something from configuration because most providers, like the console provider, can be

set up using
set up using

configuration so we can go over in our appsettings.json. If you just look at this top section, now,
configuration so we can go over in our appsettings.json. If you just look at this top section, now,

you can see here's our configuration for how we want our console logger to work.
you can see here's our configuration for how we want our console logger to work.

We have log levels depending on the source of the message and whether or not to include scopes and
We have log levels depending on the source of the message and whether or not to include scopes and

it's a best practice to do the configuration in a
it's a best practice to do the configuration in a

config file like an appsettings.json because that way you can change your logging configuration without recompiling you app.
config file like an appsettings.json because that way you can change your logging configuration without recompiling you app.

So with AddDebug, AddConsole. Now, like I said, one of the great things about Microsoft.Extensions.Logging is
So with AddDebug, AddConsole. Now, like I said, one of the great things about Microsoft.Extensions.Logging is

how many options there are for where you want to write things. If we take a look at the documentation,
how many options there are for where you want to write things. If we take a look at the documentation,

and I should mention, actually, while I'm on the topic of documentation the documentation
and I should mention, actually, while I'm on the topic of documentation the documentation

we have for ASP.NET Core logging is quite good.
we have for ASP.NET Core logging is quite good.

So, if you go out to docs.Microsoft.com, look at ASP.NET Core,
So, if you go out to docs.Microsoft.com, look at ASP.NET Core,

find the logging article,
find the logging article,

it'll have all the information from this video plus some more details, so I'd encourage you to go check that out.
it'll have all the information from this video plus some more details, so I'd encourage you to go check that out.

But if we go down to built in logging providers, you can see that out-of-the-box, ASP.NET Core has providers for console
But if we go down to built in logging providers, you can see that out-of-the-box, ASP.NET Core has providers for console

logging, debug logging, EventSource, Event Log, Trace Source, and even Azure AppService which is pretty cool. Azure AppService logging,
logging, debug logging, EventSource, Event Log, Trace Source, and even Azure AppService which is pretty cool. Azure AppService logging,

if we hook that up, I have a blog post that talks more about this
if we hook that up, I have a blog post that talks more about this

so I'd encourage you to go check this out as well
so I'd encourage you to go check this out as well

and I'll put the link to this blog post down in the comments below this video, but
and I'll put the link to this blog post down in the comments below this video, but

you can
you can

hook up AddAzureWebAppDiagnostics (it's another AddProvider extension method),
hook up AddAzureWebAppDiagnostics (it's another AddProvider extension method),

optionally you provide some settings about what format you'd like the messages in (but this is not required),
optionally you provide some settings about what format you'd like the messages in (but this is not required),

and then when you deploy your application as an Azure AppService, we'll
and then when you deploy your application as an Azure AppService, we'll

automatically start collecting those logs if logging is enabled for your AppService, and you can enable it
automatically start collecting those logs if logging is enabled for your AppService, and you can enable it

through either the portal in the
through either the portal in the

diagnostic logs blade or just using the Azure CLI.
diagnostic logs blade or just using the Azure CLI.

Once logging is enabled for your AppService, if this provider is registered, then whatever
Once logging is enabled for your AppService, if this provider is registered, then whatever

a logger generated by this ILoggerFactory writes a message, it'll be streamed to the application logs
a logger generated by this ILoggerFactory writes a message, it'll be streamed to the application logs

which you can see either in the portal or, again, using the
which you can see either in the portal or, again, using the

CLI. Like I said, I'll include a link to this blog so you can read more of these details.
CLI. Like I said, I'll include a link to this blog so you can read more of these details.

But if you're deploying into Azure App Service, this is a nice provider to know about.
But if you're deploying into Azure App Service, this is a nice provider to know about.

Another provider that's nice, though, (like I said,
Another provider that's nice, though, (like I said,

it's not just our first party ones, there are a lot of third-party providers
it's not just our first party ones, there are a lot of third-party providers

because of the extensible nature of Microsoft.Extensions.Logging), Serilog is a big one because
because of the extensible nature of Microsoft.Extensions.Logging), Serilog is a big one because

Serilog has so many sinks you can use. If you go look on their GitHub page github.com/serilog,
Serilog has so many sinks you can use. If you go look on their GitHub page github.com/serilog,

here's a list of their available Serilog syncs.
here's a list of their available Serilog syncs.

These are all the places Serilog can write. So you've got everywhere from SQL Server
These are all the places Serilog can write. So you've got everywhere from SQL Server

to Azure Table Storage to AWS CloudWatch, to Elasticsearch and
to Azure Table Storage to AWS CloudWatch, to Elasticsearch and

so, really, about any place you want to write logging messages
so, really, about any place you want to write logging messages

from your ASP.NET Core app, you can do it either with a built-in provider or through the Serilog provider.
from your ASP.NET Core app, you can do it either with a built-in provider or through the Serilog provider.

If we come back over to my demo here, you can see I'm actually setting up a Serilog
If we come back over to my demo here, you can see I'm actually setting up a Serilog

provider here by creating a new LoggerConfiguration (which is the Serilog
provider here by creating a new LoggerConfiguration (which is the Serilog

configuration object) and then, as with most providers,
configuration object) and then, as with most providers,

you can configure Serilog, either programmatically by calling .WriteTo and then the sink you want to use (like here
you can configure Serilog, either programmatically by calling .WriteTo and then the sink you want to use (like here

I'm saying we're going to use Azure Table Storage).
I'm saying we're going to use Azure Table Storage).

If I wanted to use Amazon CloudWatch it's it's similarly simple to do programmatically. Or you can do it through configuration.
If I wanted to use Amazon CloudWatch it's it's similarly simple to do programmatically. Or you can do it through configuration.

So I can say .ReadFrom.Configuration, and I pass my configuration object.
So I can say .ReadFrom.Configuration, and I pass my configuration object.

So if we go back to appsettings.json,
So if we go back to appsettings.json,

you can see down here is our Serilog configuration. By default, Serilog will look for a configuration section called Serilog
you can see down here is our Serilog configuration. By default, Serilog will look for a configuration section called Serilog

and it gets minimum level to log. It also has a WriteTo section where I can list
and it gets minimum level to log. It also has a WriteTo section where I can list

the sinks that I plan to use, so in here I'm using the LiterateConsole sink.
the sinks that I plan to use, so in here I'm using the LiterateConsole sink.

LiterateConsole is a very cool sink. It's a console sink
LiterateConsole is a very cool sink. It's a console sink

(so it writes to the console),
(so it writes to the console),

but it uses structured logging. So the idea of structured logging is worth explaining a little bit because it's really powerful.
but it uses structured logging. So the idea of structured logging is worth explaining a little bit because it's really powerful.

Structured logging means that when we log a
Structured logging means that when we log a

message, in addition to just logging the message itself, pieces of data from within the message will be logged
message, in addition to just logging the message itself, pieces of data from within the message will be logged

separately in a strongly typed way so that they can be easily queried later. Let me show you an example of how this might look.
separately in a strongly typed way so that they can be easily queried later. Let me show you an example of how this might look.

So here in my CustomersController, I have a logger.
So here in my CustomersController, I have a logger.

Then I call LogInformation. This is how you might log a piece of information using the Microsoft.Extensions.Logging framework.
Then I call LogInformation. This is how you might log a piece of information using the Microsoft.Extensions.Logging framework.

I then provide the message that is going to be logged, but notice that I have these parameters in curly braces here. I have the HTTP
I then provide the message that is going to be logged, but notice that I have these parameters in curly braces here. I have the HTTP

verb (the method, like GET, POST, whatever)
verb (the method, like GET, POST, whatever)

that was used, and I also have a custom message that I'm just getting out of resources here
that was used, and I also have a custom message that I'm just getting out of resources here

that explains the path that the request went to. And then, over here, we have
that explains the path that the request went to. And then, over here, we have

parameters, which will fill in to format this string
parameters, which will fill in to format this string

but because these are named curly brace parameters, Serilog recognizes these as
but because these are named curly brace parameters, Serilog recognizes these as

interesting pieces of data. So when Serilog logs our message, it'll log the formatted string which is human readable,
interesting pieces of data. So when Serilog logs our message, it'll log the formatted string which is human readable,

but it will also log (if the sink supports it),
but it will also log (if the sink supports it),

these pieces of data in a standalone way
these pieces of data in a standalone way

so you'll have a method name of,
so you'll have a method name of,

you know, POST or GET or whatever so then let's say I
you know, POST or GET or whatever so then let's say I

log this to Elasticsearch which, of course, would support all of those structured pieces of data. I could then search
log this to Elasticsearch which, of course, would support all of those structured pieces of data. I could then search

through all of my logging events, all my
through all of my logging events, all my

diagnostics for instances where method name is equal to PORT or PUT and so it makes it really easy
diagnostics for instances where method name is equal to PORT or PUT and so it makes it really easy

to query on interesting data in your logging messages
to query on interesting data in your logging messages

without having everything just be a string that you have to parse through. So, as much as possible when you're using
without having everything just be a string that you have to parse through. So, as much as possible when you're using

Microsoft.Extensions.Logging, I encourage you to really make use of this structured logging feature because it's very powerful and all it
Microsoft.Extensions.Logging, I encourage you to really make use of this structured logging feature because it's very powerful and all it

requires is that you're careful about the way you set up your messages so that interesting pieces of data are called out with curly braces
requires is that you're careful about the way you set up your messages so that interesting pieces of data are called out with curly braces

that will be stored separately
that will be stored separately

Now, to show how we're using this in here, you'll notice that I'm just
Now, to show how we're using this in here, you'll notice that I'm just

getting an ILogger in through our constructor, so all of the logging
getting an ILogger in through our constructor, so all of the logging

infrastructure is provided through dependency injection in ASP.NET Core. Now, if you look in my Startup.cs, you'll notice
infrastructure is provided through dependency injection in ASP.NET Core. Now, if you look in my Startup.cs, you'll notice

we actually don't even register anything in ConfigureServices.
we actually don't even register anything in ConfigureServices.

There's a lot of stuff being registered here,
There's a lot of stuff being registered here,

but nothing related to logging. The reason for that is because ASP.NET Core will automatically provide logging services as part of its base functionality.
but nothing related to logging. The reason for that is because ASP.NET Core will automatically provide logging services as part of its base functionality.

So in Configure, we can request the ILoggerFactory that will automatically be injected via dependency injection.
So in Configure, we can request the ILoggerFactory that will automatically be injected via dependency injection.

Similarly, then, after we've configured it,
Similarly, then, after we've configured it,

in our controllers, we can request an ILogger and that will be provided. Now you notice that the ILogger is generic.
in our controllers, we can request an ILogger and that will be provided. Now you notice that the ILogger is generic.

What we pass here is going to be the category.
What we pass here is going to be the category.

So, typically you're going to pass the class
So, typically you're going to pass the class

which is doing the logging because this will be the category which log messages are categorized into.
which is doing the logging because this will be the category which log messages are categorized into.

So it's a nice way of keeping separate things that come from one controller versus another controller.
So it's a nice way of keeping separate things that come from one controller versus another controller.

So that's why within the CustomersController, I get an ILogger. Now, you can create ILoggers
So that's why within the CustomersController, I get an ILogger. Now, you can create ILoggers

explicitly and, if you do that, you can request whatever category you want, but this is a nice,
explicitly and, if you do that, you can request whatever category you want, but this is a nice,

just sort of a nice standard way of doing it. You can actually see here in this sample, I have some custom middleware
just sort of a nice standard way of doing it. You can actually see here in this sample, I have some custom middleware

that's just defined right in-line (it doesn't have its own class). So to create a logger to use in there,
that's just defined right in-line (it doesn't have its own class). So to create a logger to use in there,

I just call LoggerFactory.CreateLogger and then I specify the category that I want. And so here's another way of doing this.
I just call LoggerFactory.CreateLogger and then I specify the category that I want. And so here's another way of doing this.

Then in here, in this middleware, whenever I log,
Then in here, in this middleware, whenever I log,

this string is what will be used as the category. And again, in here,
this string is what will be used as the category. And again, in here,

you know, you can see I'm calling LogInformation just the same as we did before.
you know, you can see I'm calling LogInformation just the same as we did before.

Now one other thing to point out also is that in appsettings.json, you can see I'm actually referring to some other
Now one other thing to point out also is that in appsettings.json, you can see I'm actually referring to some other

some other parameters which I didn't define like RequestId and Level. These things are automatically
some other parameters which I didn't define like RequestId and Level. These things are automatically

provided by ASP.NET Core, as well. If you look at the blog post I was referring to earlier,
provided by ASP.NET Core, as well. If you look at the blog post I was referring to earlier,

you can see down here where I sent some information to Elasticsearch, it gets all of those parameters. You can see that ASP.NET Core
you can see down here where I sent some information to Elasticsearch, it gets all of those parameters. You can see that ASP.NET Core

out-of-the-box is going to include parameters for request path (which is going to be the path the request went to), request Id
out-of-the-box is going to include parameters for request path (which is going to be the path the request went to), request Id

(which is a unique Id for correlating different
(which is a unique Id for correlating different

events that happened while processing a single HTTP request), action name action ID,
events that happened while processing a single HTTP request), action name action ID,

task Id, SourceContext, these are all things which are included by default either by Microsoft.Extensions.Logging or
task Id, SourceContext, these are all things which are included by default either by Microsoft.Extensions.Logging or

ASP.NET Core.
ASP.NET Core.

So you could refer to these when you're creating a template path that you would like your provider (like the console provider or
So you could refer to these when you're creating a template path that you would like your provider (like the console provider or

one of the Serilog sinks) to use so these can then be be
one of the Serilog sinks) to use so these can then be be

included in your messages.
included in your messages.

I've gone through that really quickly.
I've gone through that really quickly.

To wrap up let me go ahead and just kick this app off
To wrap up let me go ahead and just kick this app off

and we'll see some logging happening. Since I've configured the LiterateConsole, we'll just see it right in our console output.
and we'll see some logging happening. Since I've configured the LiterateConsole, we'll just see it right in our console output.

This is just a very simple web API. The app itself is not super interesting but you can see here all
This is just a very simple web API. The app itself is not super interesting but you can see here all

that logging happening.
that logging happening.

And you can see that the output template is being used to to format the messages
And you can see that the output template is being used to to format the messages

so I'm getting things like the request Id,
so I'm getting things like the request Id,

if it exists, the level, the timestamp, and then, over here,
if it exists, the level, the timestamp, and then, over here,

If I go ahead and call the GET method that we were looking at previously,
If I go ahead and call the GET method that we were looking at previously,

you can see here that we (here it is), here is that
you can see here that we (here it is), here is that

message that I was showing that's using structured logging so 'GET' and 'Getting customers' are actually highlighted in cyan here by the
message that I was showing that's using structured logging so 'GET' and 'Getting customers' are actually highlighted in cyan here by the

LiterateConsole sink because it recognizes those as being string parameters that are part of the structured message.
LiterateConsole sink because it recognizes those as being string parameters that are part of the structured message.

So when this goes to something like
So when this goes to something like

Table Storage or Elasticsearch, these will be called out as separate string parameters that we could query on. In the LiterateConsole, what it
Table Storage or Elasticsearch, these will be called out as separate string parameters that we could query on. In the LiterateConsole, what it

does is just sort of color code them to make it easy to spot things that are maybe particularly interesting or that,
does is just sort of color code them to make it easy to spot things that are maybe particularly interesting or that,

you know, are especially relevant to
you know, are especially relevant to

what we're looking at.
what we're looking at.

And so you also can see here some of the information from that custom middleware about how long
And so you also can see here some of the information from that custom middleware about how long

things took. And that's not even really necessary since ASP.NET Core also logs similar messages, but I included it here
things took. And that's not even really necessary since ASP.NET Core also logs similar messages, but I included it here

just as a way to demonstrate some middleware in a separate sample.
just as a way to demonstrate some middleware in a separate sample.

But this is what the LiterateConsole output looks like. Again,
But this is what the LiterateConsole output looks like. Again,

this is a Serilog sink because I've plugged Serilog into Microsoft.Extensions.Logging
this is a Serilog sink because I've plugged Serilog into Microsoft.Extensions.Logging

through their provider and,
through their provider and,

in general, this is just a super flexible way of logging in your asp.net core apps. I hope this has been helpful.
in general, this is just a super flexible way of logging in your asp.net core apps. I hope this has been helpful.

Thanks!
Thanks!