dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.3k stars 9.97k forks source link

[Mvc] Add EventSource tracing to application part discovery #14343

Open javiercn opened 5 years ago

javiercn commented 5 years ago
javiercn commented 5 years ago

Sample on DI https://github.com/aspnet/Extensions/blob/master/src/DependencyInjection/DI/src/DependencyInjectionEventSource.cs

rynowak commented 5 years ago

Do you have some examples of bugs/investigations we could short circuit with this?

javiercn commented 5 years ago

Sample issues this would help troubleshoot https://github.com/aspnet/AspNetCore/issues/13850 https://github.com/aspnet/AspNetCore/issues/10331 https://github.com/aspnet/AspNetCore/issues/4332

To name a few, but there are more.

With tracing we can answer the following questions:

davidfowl commented 5 years ago

Just and FYI the reason DI has to use event source is because logging isn’t possible. Why not just log it as debug?

javiercn commented 5 years ago

It’s not possible either. The container is not yet built at the time it happens.

davidfowl commented 5 years ago

@javiercn why not log the results instead of logging the process or building those results?

javiercn commented 5 years ago

@davidfowl Because logging information during the process is what it is useful in troubleshooting the issue. When this issue happens the result is typically an empty application parts list, which gives you no clue as to why you ended up there.

javiercn commented 5 years ago

More issues this will help with https://github.com/aspnet/AspNetCore/issues/14359 https://github.com/aspnet/AspNetCore/issues/14374

mkArtakMSFT commented 5 years ago

Moving this to happen now as this will help with future investigations a lot.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

ghost commented 1 year ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.