Conversation
There was a problem hiding this comment.
In general, not against this change, would be nice to not have to understand which events go to telemetry and which done.
But there might be some diagnostic events here that @mavasani was using for feedback tickets via this logger - https://sourceroslyn.io/#Microsoft.VisualStudio.LanguageServices/Telemetry/FileLogger.cs,21
These events could also be recorded via etwlogger / codemarkerlogger - not sure how important those are.
|
If so, i'd rather those features explicitly use such a logger in a clearly defined fashion. right now there's just no wy to tell from looking at things what the purpose of the calls are, and i know i've certainly created/maintained many telemetry markers with the expectation that they were actually getting reported and that we'd be able to see how things changed over time. |
Yeah I wonder if our ILogger abstraction is hurting a bit here - it almost seems like we want the log calls themselves ot be explicit in where they log (either telemetry, etw, file diagnostics, etc). |
|
Seems like a perfectly reasonable design to me for log messages to declare their verbosity, and loggers to decide which verbosities they care about. I do think it would be great if the verbosity of the logger was smarter, and could be dialed up or down remotely, or when doing Report a Problem, etc. |
This telemetry was going into a black hole. We didn't even notice till now, so clearly it was providing zero value. Removing and reclaiming the CPU usage (as well as horizontal space) we were wasting.