Implement a Telemetry Interface for Internal MSFT Windows OS Users for more robust telemetry/logging

[HenokAddis]

When you investigate the developer experience around Static Analysis in WAVE, you’ll realize that WAVE is really a coordinator that kicks off a series of workflows that get consumed and engaged with in a separate extension – the Static Analysis Results Interchange Format (aka SARIF, full documentation) Viewer extension in Visual Studio and VSCode. Specifically, the only events we fire in WAVE today for static analysis can be found below (build invocation/completion):

• Microsoft.Internal.Windows.DevProductivity.VSCodeClient.codeAnalysisBuildStarted
• Microsoft.Internal.Windows.DevProductivity.VSCodeClient.codeAnalysisBuildCompleted
• Microsoft.Internal.Windows.DevProductivity.VSClient.CodeAnalysisBuildStarted

The SARIF Viewer extensions should coordinate and collect telemetry on their own, but the issue is that for our internal developers we will not get telemetry associated with individuals, file paths, or other rich pieces of information that allow us to iterate. Also, as it stands, there is no telemetry being sent by the SARIF Viewers today at all. Enumerating the problems more clearly below:

• GDPR/PII of a public marketplace extension hurts our ability for rich insights
• No telemetry is being fired today; no data model today
• There should be some commonality between the extensions/IDEs

What we hope to accomplish in this document:

• Creating an initial set of default telemetry for SARIF viewer
• Elaborating on the extensions necessary for the internal WAVE experiences
• Timelines for delivery (optionally funded through COSINE dev resources)

[HenokAddis]

Below I’ve enumerated a proposal for a telemetry schema that we can use to begin firing information from the SARIF Viewer. Keeping custom event information inside of a DataJson makes it:

• Easy to consume, parse, engage with
• Easy to extend - standard model with custom columns allow easy integration across any Event/Exception