Define + implement initial metric to collect

[JanKrivanek]

Motivation

For our initial investigation of exposing and collecting data in VS we need some meaningfull data, that are available in the main node, not expensive not complicate to obtain and not of a high volume or size.

Proposal

• build request duration
• maybe type? - full/incremental
• some flags around SAC/CI/AVs

Goal

Metrics defined and exposed in MSBuild

[KalleOlaviNiemitalo]

Is this intended only for sending telemetry to Microsoft, or would another company be able to set up its own OpenTelemetry collector and configure MSBuild to send the telemetry there?

[JanKrivanek]

Current thinking is to instrument with pure OTel and sensibly initialize our collector, without preventing other collector.

We need to experiment to see downs/ups. We might possibly end up with internal proprietary data collection within msbuild (would distributed tracing prove as perf hit as compared to our current telemetry BuildEventArgs and logger), translated to OTel metrics in the main node. So still collectable by 3rd pties, but possibly some context data might not have exact fidelity.

[KalleOlaviNiemitalo]

When MSBuild replays a binlog, will it publish the original timestamps and durations as telemetry, or generate new ones from the system clock?

[JanKrivanek]

When MSBuild replays a binlog, will it publish the original timestamps and durations as telemetry, or generate new ones from the system clock?

This is a great question - though this is currently not a core scenario that we'd need to figure now.
Synthetizing might be nice, but can skew data when not deduplicated in backend. We might possibly skip emiting alltogether.

Btw. the TelemetryEventArgs are not part of the binlog (nor are they raised via IEventSource.AnyEvent) - they only go to the dedicated handler (and only during live run).

[YuliiaKovalova]

please include it in the initial set
#11075

[JanKrivanek]

Prototype of querying AV: main...proto/get-av
Bit complicated due to need to use WMI