Skip to content
This repository has been archived by the owner on Nov 10, 2019. It is now read-only.

Topic: System.Diagnostics Deep Dive #25

Closed
cwe1ss opened this issue Jun 27, 2017 · 6 comments
Closed

Topic: System.Diagnostics Deep Dive #25

cwe1ss opened this issue Jun 27, 2017 · 6 comments
Labels

Comments

@cwe1ss
Copy link
Collaborator

cwe1ss commented Jun 27, 2017

I feel like diagnostics/tracing/logging topics in corefx don't get enough interest from the community and I'd love to hear if you agree and what could be done to improve this.

Example: We now have integrated distributed tracing with the new "Activity" class and I'm pretty sure that very few people even know about this type. The result is that IMO there hasn't been enough community feedback during the API design phase.

Also, due to the long history of this namespace, there now exist quite a few ways to do similar things and I think it becomes increasingly difficult for people to choose the right types because there's no clear guidance for it.

E.g. one has to choose between the following things just in corefx:

  • Trace
  • Debug
  • TraceSource
  • EventSource
  • DiagnosticSource
  • PerformanceCounter
  • EventCounter
  • EventLog
  • Activity

In addition to that, the following Microsoft libraries also cover this area:

And of course, there's an overwhelming amount of 3rd party libraries in this area (AppMetrics, log4net, Serilog, NLog, LibLog, ...).

It is my impression that people are not happy with what is offered by corefx and therefore prefer to build their own solutions (within Microsoft [Microsoft.Extensions.Logging] and in the community [Serilog, ...]). Also, I think that a lot of regular developers don't even know about most of these types.

Sure, all of these types have their reasons to exist and Vance wrote a great comment about this once but still, I feel like the current state of this area in the .NET ecosystem is way too complex.

Especially in server scenarios it is extremely important to have a good and unified tracing story. Unfortunately, due to this big amount of types/technologies, application developers have to invest a huge amount of time to consolidate these different sources in their environments.

So maybe we could do some sort of "deep dive" in a future stand up with one/some of the area experts and talk about the scope of existing types, the "Microsoft vision" in this area and also ask contributors/community members about their experience with this area?!

@Drawaes
Copy link
Collaborator

Drawaes commented Jun 27, 2017

This is a big issue for me. Attempting lay down the monitoring story for .net in a large organisation it really isn't easy or fun. As usual I have many opinions so am keen.

@karelz karelz added the Topic label Jun 27, 2017
@karelz
Copy link
Member

karelz commented Jun 27, 2017

I am not sure if this is a topic we want to cover in the standup.
This looks more deep-dive than what we had in mind originally for the standup, which is more meta. That said, if there is enough demand for change of content in the standup, we will definitely consider it.

For this particular request, I would suggest to create a working group with people interested in the topic and starting ad-hoc technical discussion with experts (@vancem @brianrob from MS side and few community experts maybe?). That is definitely fair request and good thing to bubble up in the standup as a gap. I can definitely help to facilitate such cooperation and open discussion.
Would that work?

@Drawaes
Copy link
Collaborator

Drawaes commented Jun 27, 2017

That sounds like a great idea. At a previous large employer we had a system of "meta" meetings like this but internal and then for a detailed topic the idea of an "offline" focused working group with a mix of end users and technical that could knuckle down and get things done that could report back via a plan. It actually worked well and allowed the meta meeting to not get bogged down in detailed discussion.

@cwe1ss
Copy link
Collaborator Author

cwe1ss commented Aug 17, 2017

For this particular request, I would suggest to create a working group with people interested in the topic and starting ad-hoc technical discussion with experts

As I've said, the problem is that there's currently no real interest from the community (at least from my point of view) so it's not really possible/useful to create a working group just yet.

The question is why there's no interest... and this should be discussed in some meta forum first (like this stand up or whatever else).

TBH I pretty much lost interest in contributing to this topic as well as it has been a constant point of frustration and pretty much wasted time/energy over the last months. The (understandable) constraints of the .NET framework (backwards compatibility, old APIs, no deprecations, ...) just don't leave much room for innovation/change. Instead, every iteration just adds more complexity and makes the situation worse.

@karelz
Copy link
Member

karelz commented Aug 30, 2017

The question is why there's no interest... and this should be discussed in some meta forum first (like this stand up or whatever else).

This might be a reasonable meta-topic. Not specific to Tracing. Feel free to open a new issue for it (reusing this one would be IMO messy).

I will close this specific Tracing topic as it doesn't fit CoreFX standup intended content. Please let me know if you disagree.

@karelz karelz closed this as completed Aug 30, 2017
@cwe1ss
Copy link
Collaborator Author

cwe1ss commented Aug 30, 2017

Nah, I don't want to invest more of my free time into a topic if no one else cares. So I think I finally reached the "acceptance" stage and made my peace with it.

I might jump back in once there's some concrete interest from MS or a broader set of the community.

So long and thanks for all the fish! 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants