Flogger serilog

[dahlsailrunner]

I removed the binaries from the repo (and added a git ignore) just to keep the size of the repo smaller (just code files).

The Flogger.Serilog project reflects some of my current thinking about this stuff. We can iterate and add to it from there if it seems like something you're ok with.

Here are some general notes:

• I called it Flogger.Serilog because it's specifically tied to Serilog and uses its library (which has some advantages)
• I use the RequestLogging feature of Serilog to include the heavier log entry with lots of details about the user, assembly, and other information like that. This keeps storage requirements for log entries a little leaner
• One thought that I'm using at my current company is to provide the Sink configuration for them - so there's a small appsettings.json section for Logging that I use to include only what I want them to provide from the application and the rest of the setup is handled in the library.

If you run the UI application and go between the About page and the Home page (no api calls at this point) and then have seq running locally you can explore the entries and see the level of detail they have. If this can serve as a good starting point, we can iterate from here and add the API stuff and data access stuff you may be interested in.

And please provide more clarification if this is not what you were after / seeking.

[dahlsailrunner]

In looking at the changes, it might be easiest for you to simply pull the branch and have a look at the code -- specifically check the SerilogHelper.cs class in Flogger.Serilog, and then look at Startup and Program within the UI, along with some of the different pages in there.

[justSteve]

I found I had to bump Flogger.Serilog's from 2.0 to get it to build. <TargetFramework>netstandard2.1</TargetFramework>

<<We can iterate and add to it from there if it seems like something you're ok with.>>

Totally.

<<...provide the Sink configuration for them>>

The 'them' is reference to the UI and API projects right? Noticing that you only log UI and API - the points where users interact with the system. Would you ever choose to log something like the BookClub.Logic project?

Other than that everything looks straight forward and comprehensible.

[dahlsailrunner]

I haven't updated the API project to use the new approach (which would include both the UseCustomApiExceptionMiddleware and UseCustomSerilogRequestLogging methods) -- was thinking you might like to try that. I can do it if you want to see it (or review what you come up with).

As for logging from the Logic or Data projects, it should work just fine. My recommended approach (if you will be using Serilog) would be to avoid injecting ILogger<T> all of the place and simply add a reference to Serilog (just that project - nothing else) and then use the static methods like Log.Information and such.

[dahlsailrunner]

Also - it's weird that you had to upgrade to .NET Standard 2.1 -- i was running fine (only with the UI) when Flogger.Serilog was on .NET Standard 2.0. Do you still have the error(s) that prompted you to do that? Just curious.

[justSteve]

Thanks! I'll take a swing at hooking up the .API and let you know when I bump my head.

If I change 2.1 down to 2.0, Clean and Rebuild I get:

The type or namespace name 'Claims' does not exist in the namespace 'System.Security' (are you missing an assembly reference?) Flogger.Serilog ...Flogger.Serilog\SerilogHelper.cs

CS0012 The type 'MulticastDelegate' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Flogger.Serilog ...Flogger.Serilog\Middleware\ApiExceptionMiddleware.cs 12 Active

[justSteve]

Most of the code that exists in 'CoreFlogger' isn't going to be compatible with a .NetStandard project. Does that mean that methods like CustomExecptionMiddleware is going to exist in both the .UI and .API projects?

[dahlsailrunner]

I don't think we will use coreflogger at all. We will move anything into flogger.serilog.

-Erik Dahl m: 651-592-4113

---

From: justSteve [email protected] Sent: Monday, December 7, 2020 11:29:35 AM To: dahlsailrunner/aspnetcore-effective-logging [email protected] Cc: Erik Dahl [email protected]; Author [email protected] Subject: Re: [dahlsailrunner/aspnetcore-effective-logging] Flogger serilog (#5)

Most of the code that exists in 'CoreFlogger' isn't going to be compatible with a .NetStandard project. Does that mean that methods like CustomExecptionMiddleware is going to exist in both the .UI and .API projects?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdahlsailrunner%2Faspnetcore-effective-logging%2Fpull%2F5%23issuecomment-740064524&data=04%7C01%7C%7Caa32f4fca01f483a48ba08d89ad5aafe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C1%7C637429589764574627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uvbZC0gwXUtKlpKpDyDTTiTvxNe3Mx%2FMJsHf9lGxNZE%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACAAJ22FRJUOV25LGZIGKCDSTUGH7ANCNFSM4UPK36YA&data=04%7C01%7C%7Caa32f4fca01f483a48ba08d89ad5aafe%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C1%7C637429589764574627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HUEJlTA2Wtd4sIoEfuY52FaLXsH4yFUDw%2FYOKDPebFc%3D&reserved=0.

[dahlsailrunner]

I didn't mean to be "short" in last note - but was sending from phone. I think my recommendation will be to simply use the Flogger.Serilog project and not use CoreFlogger. That will mean that any specific pieces of functionality will be in the Flogger.Serilog project. And as for the CustomExceptionMiddleware -- that is for API projects only -- not UI. The built-in middleware is fine for UI projects -- it logs the exception and shows a page that shields the error -- and you can customize the page however you like. But that behavior doesn't work for APIs- which need to return a 500 response and a custom response body. And that API middleware is defined in Flogger.Serilog.

Let me know if you have any specific questions.

[justSteve]

Yep -- I'd understood that at one level or another CoreFlogger is being replaced by Flogger.Serilog. What I'm not clear on is how a .NetStandard lib is going to be able to hold references to the range of dependencies as are currently found in CoreFlogger.

Probably my confusion is due to a too shallow understanding of how to implement global exception (and filters) handling. I'm slowly coming to the understanding that those sorts of concerns have to be implemented from within the UI and/or API itself instead of coming in from the outside.

I'm probably getting hung up on the idea of coding a single reusable project that can bring the features to new projects instead of a deep understanding of how any given Core project needs to be structured in order to implement those features.

So probably I should concentrate on implementing the capabilities one at a time -- makes sense to start with .API. Your differentiation of .UI vs. .API is helpful. thx

[dahlsailrunner]

If i have a few minutes tomorrow AM maybe I'll update the API and the other assemblies in another branch and create another PR to this one so you can see the changes I made. We should be able to centralize the logic that you want.