Logging in ASP.Net Core made easy

hey there and welcome back to the code wrinkles channel for a brand new video in this one we will talk about logging in asp.net core and actually this is a getting started video into asp.net core logging an introduction and my hope is that this would be one of the clearest explanations that you would get about how logging actually works and how it is designed in asp.net core because let's face it probably most of you already know exactly that we have some kind of magic that we can use and inject loggers wherever we want them and we can then just simply use them to lock different things and this is correct but in order to really understand or in order to be able to build upon this type of foundation to add some custom logging structured logging understand logging providers logging things and things similar to that it is important to understand how actually this logging infrastructure is set up in asp.net core and that's the main purpose of this video right now so this means that there will be a lot of other videos coming very very soon so you might just want to hit the subscribe button if you haven't done that already because you want to be posted whenever we have new content regarding asp.net core logging and i can assure you that we will go into a lot of topics when it comes to logging we will also look into other third-party logging providers like serilog like analog like log4net and so on so you might want to really uh keep in touch on this one if you are interested of course in asp.net core logging now let's get right into it and i would like first of all to just make sure that we all have really a common understanding or baseline about how we use logging in asp.net core i just want to get started on implementing and logging some information which is very very easy the project that you see here is actually a project that we have built when we created a video on how to structure the layered architecture so if you want to better understand the layers of these applications that are expressed in different projects then you might just want to just go to that video you see a card with this video in the right top corner on this video right now and you will also find it in the description of this video so you can pause that go to the other video and try to understand exactly what we have here because right now i just want to concentrate about logging and as i said the good thing or a very good thing about logging in asp.net core is that it actually works without the need for us to do anything we can just simply start use the logging uh features that we have in sp.net core without even configuring anything so let's see a little bit how this is done first of all of course we will need here a private field so we'll go for private read only and we'll inject here and i logger now the cool thing about the logger is let's first name the field and then we'll go into this discussion the interesting thing about this ilogger is that it is just a service that is already there in the dependency injection containers so you can just inject it and as part of this i logger interface you have different methods that you can use to log different type of things that you might want to look for instance if you want just to log some information you can log information if you have in your application or if you reach a state for instance where things are not as they should be then you might want to log a warning but if that if your things get really really messy and you have exceptions then you might want to log exception so everything is part of this i logger interface and we will look into that just in a second however right now there is one important thing that i want to emphasize that this i logger interface is a generic one and we usually put here as a generic type parameter the name of the class in which we actually do the logging so in this case it would be our weather forecast controller because we do the logging in our weather forecast controller class seems very easy and straightforward so no big deal here now the idea is that we will see just in a second when we will launch the application exactly why this is important to specify his the here this generic type of parameter and we'll see exactly that we can actually individuate and see exactly where we did the logging or what class did the logging of that specific log that we are looking to now let's also for instance we have already here in the constructor of this controller this i logger of weather forecast service so the only thing that we need to do here is we can say logger equals longer and then we should be good to go now here we use a service we have moved all the weather forecast retrieval in a service and there below the service there is a repository so it's a regular structured application but right now what i want just to do is let's log something here logger dot and we see that we have here the different type of logging that we can do we can log information which is simply just an information that we want to log to have it somewhere we can log debug this is then maybe used when we are debugging just to log different things or different states of objects then we have log error and we use this one when we have exceptions or errors in our application so when the application reaches that state that cannot actually go forward and of course you just want to log this and we log this as uh as error then we have trace which is even more verbals than uh than the debug and we have the warning i said when something is a little bit fishy in the application but it's not quite an error so in this case we can just log a warning and that should do it now let's start very simple by having a log information and here we can for instance let's make a string interpolation let's say controller action executed on and date time dot now and let's um let's use only the time for this or time of day good so this is what we look here now we can also refactor this a little bit we just want to get a result first so let's have here var result because what we want to do here is of course we need an equals here we just also want to log how many objects did we actually get back from the service so in this case once again logger log information and let's also use once again string interpolation because i really like it and say we got and then we can get actually the count of the result result.count forecasts from the service which is cool and then we can simply return result and that should do it our application should be up and running again now let's run the application and look a little bit into what will happen when we will execute the controller or when we will execute from swagger an action uh to this controller when we will try it out so we have here the console now on on the other monitor we have the the swagger open i won't bring it here because i want us to keep focus on what happens in the console so i'll click on try it out and execute right now and i can already close swagger we don't need it anymore so what happened here well it happened here that when we started the application we got some logs that come from microsoft these logs come from asp.net core directly but we haven't even logged them but an external library has logged them off for us but then we see that we have these two log informations and here we see that uh we got so the the controller action executed on and we see exactly the time and then that we got five results back which is fairly fairly cool but i want us to take a closer look about how actually the name of this logger looks like because we have here for instance weather forecast api controllers which is actually the name of the project uh this one is the name of the project and this is the name of the folder where we are and this is actually the name of the class so this here is actually the name that we specify here when we define the i logger and when we inject the i logger in our constructor and this is very very important because you you will log and we will actually do this we log into different classes and in that case we want for each log to have a better overview where exactly did that logging happen and this is how you can do it so it's very very easy now in fact let's enhance our logging that we have right now and do exactly that so let's move here into our service class we have this weather forecast service which is in a total different layer of the application which is the services layer and of course we also want to log what happens here so in this case we would also need to add the i logger so we'll have private read only and in order to be able to see exactly from the console in this case where exactly did this logging happen we can just specify that this is an i logger of weather forecast service because this is where our logging happens and let's call it logger and that should be okay now the only thing is and in fact i wanted this to happen is that of course we are here in a class library project we are not in the asp.net core project anymore so in this case our class library does really not know exactly where to look uh for or logging and in fact if we click here on this light bulb we see that we have here this hint to install the package microsoft is microsoft extensions logging and actually this is what we want to do so let's install this uh let's install let's install with package manager okay and here we have this one which is the latest stable version we'll choose the latest stable version and that shouldn't work once again if you want to log actually or to use the logging that we have already in asp.net core but in other class libraries so meaning in other layers of your application because your api or your web application it's actually just the front end but you would have probably a lot of different other types of players then you would have to install this package microsoft extensions logging abstractions which provides you actually with this ilogger interface so now we can see here using microsoft extensions logging and that should do it so this is a very very first key point here of this video if you want to use the i logger in your class libraries that actually represent different layers of your applications you have to install the microsoft extensions logging nuget package otherwise you can't really do that but once you have done that this it's actually very very easy because you can say here once again i want through the dependency injection container and i logger which will be here of type weather forecast service and let's call it logger and here where we actually also assign the repository let's also assign the logger so now once again just we just as we did in our controller we have a fully functional logger directly into our service and since we have registered this service in our dependency injection container like here services add scoped eye weather forecast service and the logger is also part of the dependency injection container even though we don't need to edit manually asp.net core does this for us this means that when we reach here this constructor the dependency injection container will just simply provide us an instance of an i logger that will use this generic type of param and here we can then just again for instance use it exactly the same way that we used it in our controller so logger.log information here we will just use a simple information like maybe also getting data in the repository so now we get the data then we start another step here we can just log in other information for that blogger dot log information and here we can simply say that uh processing the forecasts and then we actually do that and then we can maybe just log once again longer dot log information and here we can say for instance that returning results to the caller so that should be it now we have added a few bunch more of logging here once again the most important thing right now we are doing logging in a class library and for that we had to install this microsoft extensions login you get package so that's a very very important thing but once we have done that and everything is wired up with the dependency injection container in asp.net core everything should work just fine so let's once again run our application swagger opened on the other monitor but once again we really don't care about it let's just try it out again and here we see that we get a bunch of more logging here we get from our controller and we see that it is from our controller because this is from the generic type param and then we see that we have this from the weather forecast service this is once again from the weather forecast service and this is also from the weather forecast service and this log is once again from the controller so this is why the generic type params for logger are important because it really helps you to better understand exactly which class did the logging of this certain log so that is really really important now that's fairly cool and everything seems to work very very nice let's hear just for for for a demo purpose add some other type of logger logs let's for instance logger.log warning here we can just say this is a warning and then we can for instance even say here logger.log error and theoretically here we should provide also an exception and we can say here new exception and then demo exception so that would be okay let's just run the application again and we will okay no we have errors of course uh expected okay we need to semicolon here and that was a typo it was a column instead of a semicolon so let's run the application again once again swagger will open on the other monitor we will execute and we'll see exactly how the warning and the error are displayed in the console here and we did execute things are done here so let's see what happened you see that we have here the warning that comes still from the weather forecast controller and we see that it is colored actually in yellow and the error is is actually labeled here with fail and it's colored with red so this is how we actually see that this is info this is warning and this is actually an exception and we see here some more information about the exception but it did in our case it was just a very plain and default exception object so there's not much to see here but once again the main idea is that logging here just works now actually for the coding part i would say that uh that uh well that's really easy to to implement really this is no big deal but i think it is very very important in order to understand and more advanced topics about logging and providers and things and uh structured logging and a lot of different things we need to have a better understanding about how actually this logging works in asp.net core and actually it's very very easy it's not complicated at all and if if you think it's complicated by reading some of the documentations then i hope this video will make it clear for you and here we have actually four main classes or concepts that we actually use or that define exactly what or how logging actually works in asp.net core and where as we have seen we have a library which is the microsoft extensions logging library that contains all the logging infrastructure now if we are in an asp.net core application we already have this library so we didn't have to install it but as you have seen when we wanted to actually to actually use an i logger in in another layer which was actually a class library so a dedicated project we needed to install this so wherever you want to use this i logger you need to install it until or unless it's actually an asp.net application where it comes by default and then there are really three concepts or three fundamental concepts to logging in asp.net core and actually that's it so nothing more than that so first of all we have this uh interface i logger of t that we have already used so it's not really complicated it's simply just a logger that is a named one and that provides actually a type t for it and all logs that are sent to an i logger of t will have then the logger name of that specific uh assembly and then of that specific class so it will have actually the fully qualified name or the full name of it once again this is important because it really helps us to better understand by which class was each log generated and that could really help us a lot when we do some bug investigation or troubleshooting or things similar to that now i use the terminology that uh that the type t actually defines the name of the logger but in the microsoft documentation you will often see the terminology category i really prefer to use name because it's uh easier to grasp and to understand what this t is all about because it's there to just provide us with a named blogger so that we know exactly which class did a certain log so that's basically it and then we have the concept of an ilogger provider which is another interface and actually this is a type that provides i logger instances now the idea is that it's actually not just that it provides i logger instances for a specific logging system so when you hear this concept of logging provider in asp.net core it's actually nothing else than a word that defines a certain logging environment or a logging system and this is important because by default in asp.net core we have four different log providers we have a provider for the console which provides us with the capability to write logs in the console the logs that we have seen when we run this application then we have a provider for debug that actually writes logs in the debug console we have also a provider a logging provider for the event source system and we have then uh another provider another login provider for the windows event log so this means that theoretically logs that we actually capture by default should also be there in our event log on our operating system if we are on windows this is important so this brings in this concept of having providers because each destination for your logging should be or is or has of course its own very specific characteristics so we cannot simply use just a generic provider that will write logs everywhere no we simply can't do that so instead we have this concept of providers that actually are targeted to work with a certain logging system and that's it and those four systems that you see here are actually as said already built in in asp.net core and then we have the ilogger factory which is actually the mastermind that brings everything together that wires everything uh together it actually uh well it has a collection of i logger providers and we can add logger providers to the factory and then it can create loggers that are associated to those logger providers so when we see when we say that we need an ilogger of t what happens behind the hood is that we have this idlogger factory that actually tries to create loggers for all the providers that are currently registered so actually this keeps track about what what providers are there and the fact we make sure that each provider will have the correct log instances so that we can consume and really start logging and this is how uh or because of this i logger factory it's actually possible for us that we can actually log it only once because we just log this information once this information once this other information we log it only once so we do not do a logs or we do not do dedicated logs for each provider so we don't do for instance here a log for the console and then separately a log for the event log no we just log it once because the ilogger factory made sure that all the providers that were registered have these loggers that they need in order to able to log the information or the warning or the error that we actually want to log so that's actually it but before we really go uh into this i just let's let's bring here also a whiteboard because i also want to to give a basic understanding on how this what we discussed right now is actually a foundation for understanding basically or virtually everything about logging in asp.net core so let's start to draw a little bit here so we have here something and this is the i uh logger factory so ilf sorry my my drawing and i said the eye logger factory or we can register different logging providers to this i logger factory so we would have here for instance an ilogger provider and let's say here uh i l and p for provider and here we can have for the console for instance console and then we'll have another ilogger provider and this idlogger provider for instance is for let's say i blogger provider and this i ilogger provider is for the event log so let's see event log and then maybe we have another i logger provider as said we have totally four but we will draw here uh only one other so let's have here ilp i logger provider and this provider is then for let's let's say it for debug okay so we have this provider now each of these providers uh could have different loggers and the ilogger factory whenever you need a logger is responsible to create all the different loggers that each provider needs in order for you to be able to log but this means that this provider would have for instance here an instance of a logger which could be for instance i don't know for our controller uh but it could it could virtually have several different loggers for the different classes that we would actually need to log so this is why also our naming is important and how we use the generic type around now then we have for for this provider it's exactly the same thing so we have here a logger which is cool and let's say that for this one we have also one other logger and once again the very very important thing is that all these loggers are actually created by this i logger factory so this one is created for this one so the factory actually keeps them track of all the providers that it has and then for all the different loggers that each provider actually needs and this is how logging in asp.net core works now why is this important because most of the times the logging that we have built in here or the providers that we have built in into asp.net core are not enough for real logging when we think about uh production applications and that's why we usually use different type of third-party logging libraries like serilog or log4net or analog so what happens if we want to use one of those libraries and once again i talk here very conceptually because each third-party logging provider does this type of things a little bit different but generally what i'm about to show here actually uh is a general concept that works in my opinion for all of them so let's say that right now so this is the standard logging setup that we already have in asp.net core so this is not nothing that we uh influence right now so let's say that we want for instance to load to be able to log to a file and we cannot do logging to a file with the providers that we have by default so in that case let's say that we want to add siri log to our application serial log i said is a third-party login provider so what this actually will do is that to this i logger factory we will actually add a new provider and this provider would be serilog logging provider so we will also add it to the ilogger factory and as we add this provider to the ilogger factory it will get of course the different instance of loggers that it actually needs to provide the logging infrastructure so we have one logger we have potentially another logger for a different class and things similar to that now how sirilog or how this logging provider is writing the logs to a file asp.net core doesn't care or the ilogger factory doesn't care the idloger factory is just responsible to provide loggers to the provider and then how the provider does the magic behind on reaching out to a logging system well it's the job of the provider to define this type of low-level behavior but once again the important thing is that if we want to add a third-party logging library we need to actually add a provider to our ilogger factory and in this case this provider the logger factor the logger factory will now will not now know that instead of three providers that it has or four providers that it has by default it has then right now a fifth one which is serilog and then it does its job and it makes sure that whenever sirilogue or this provider needs a logger it makes sure that it will have all the logger instances that this provider needs in order to do the logging so and if we would like for instance to add another third-party login provider like a log for net we would have to do exactly the same thing so we will have to add that provider to the logger factory and then the logger factory would make sure that that new provider would get all the necessary loggers when it needs to load something now uh one last very important thing here is that usually i said we can we can have several different providers that work in parallel however third-party logging libraries might have different approaches because some of the libraries when you add the logging provider for their library they actually remove all the default providers that are provided there by asp.net core so you have to be a little bit careful for that but we will go into more detail about this once we will talk about those specific logging providers for asp.net core good and i guess that's actually it for today i hope you found this uh this content useful i said this is just a getting started video into how asp.net core logging works and i can promise you that there will follow more and more videos about logging in asp.net core from very very easy concepts to more advanced concepts until we arrive even at structured logging and things similar to that to them or maybe even creating our own logging abstraction for our own class library that could also be a topic but if you want to to be updated on that then just please hit the subscribe button if you didn't do it already and so you can make sure that that you get uh always the latest information and the latest content that we try to provide here and if you enjoyed it also hit the thumbs up button that would be very very much appreciated and if you think that you might have friends or colleagues or peers that might also benefit from this one don't be shy again and uh send them spread the word sharing is caring they say last but not least if you have any questions or ideas or if you just want to add something don't be shy once again and just use the comment section because we have it here and i'm really more than happy to start a conversation going with you so i am waiting for your comments once again thank you very much for watching and until the next time i wish you the very best

Channel: Codewrinkles

Views: 4,155

Keywords:

Id: ceg7GpomQmc

Length: 31min 9sec (1869 seconds)

Published: Thu Nov 04 2021