I see ActionId, ActionName, ConnectionId, CorrelationId, RequestPath plus a bunch of others.
Original Issue
https://github.com/aspnet/AspNetCore/issues/7628
Hello @AceHack ... Log scopes are currently covered in ...
Are you asking for something specific showing the use of those specific properties? I don't suppose that it would be difficult to merely use the props in a log scope, so I'm probably misunderstanding what you would like to see. Can you be more specific?
@guardrex I'm not asking to document how to use log scopes, I'm asking please document all the log scopes that are automatically created by ASP.NET core in the various situations. I listed a few above that seems to show up when logging inside a controller.
Ah, I see ... those aren't "log scopes" ... just data reported by log scopes ... and they aren't all MVC. I think the last few are Hosting-related. This is a bit too much detail for general docs. We would have a very hard time keeping them up-to-date given the small team size, our issue load, and churn in the framework. Best bet is to just search the engineering repo for "BeginScope" and then track down the various "...LogScope" classes in the ref source (e.g., HostingLogScope, ActionLogScope, etc.). Fortunately, engineering seems to have named them all the same way, so they should be easy to track down.
https://github.com/aspnet/AspNetCore/search?q=BeginScope&unscoped_q=BeginScope
@Rick-Anderson Do you concur?
@guardrex This seems like a terrible response, we use elasticsearch for our logging and knowing what the fields are and what they mean are pivotal to our success. We use ASP.NET core and also a custom built service to service communication library. We are a team of two that both built the service to service communication library and documented all the log scopes we automatically generate for teams to help with diagnosing and troubleshooting issues. It seems improbable that Microsoft does not have the resources to do the same.
@AceHack I apologize but we're a very small doc team. This is a very specialized question that doesn't impact most users. We expect advanced users, such as yourself, to review the source code for specialized problems that don't meet our bar for relevancy to most customers.
It seems improbable that Microsoft does not have the resources to do the same.
Right, but that's not our call. This is just where we're at today. There are only three of us here working on the _entire doc set_ for ASP.NET Core. There are over _300 documents_ in this doc set and perhaps _80 sample apps_, and we have to keep up with something like 50 fast moving MS engineers crank'in out the code. We just won't be able to take every request under these circumstances.
I recommend taking my advice tho. Follow that link. Look for the classes named {something}LogScope ... pull those up ... there will only be perhaps a dozen or so of them. Then, you can see exactly what they're shooting into logging.
[EDIT] ... and do the same "BeginScope" search over on the Extensions repo for the framework extensions (caching, logging, DI, configuration, etc.) if you need log scope info in those areas of the framework. https://github.com/aspnet/Extensions
Most helpful comment
Ah, I see ... those aren't "log scopes" ... just data reported by log scopes ... and they aren't all MVC. I think the last few are Hosting-related. This is a bit too much detail for general docs. We would have a very hard time keeping them up-to-date given the small team size, our issue load, and churn in the framework. Best bet is to just search the engineering repo for "BeginScope" and then track down the various "...LogScope" classes in the ref source (e.g., HostingLogScope, ActionLogScope, etc.). Fortunately, engineering seems to have named them all the same way, so they should be easy to track down.
https://github.com/aspnet/AspNetCore/search?q=BeginScope&unscoped_q=BeginScope
@Rick-Anderson Do you concur?