[DiagnosticsClient] Add user events probe contract and API #5656
Conversation
mdh1418
requested review from
hoyosjs,
lateralusX,
noahfalk,
steveisok and
tommcdon
|
|
||
| The runtime will keep track per-session whether it has sent a particular event before. The first time each event is sent during a session, metadata will be included. Should multiple threads race to write the same event to the same session, they may all emit metadata. Afterwards, all instances of that event will not emit metadata, and the responsibility is on the reader to cache and link events with their previously sent metadata. As a special case, runtime events currently implemented in native code will never send metadata. | ||
|
|
||
| #### Capability probing with CollectTracing5 |
There was a problem hiding this comment.
One item to consider is making a generic API that can check for any Diagnostics IPC/EventPipe command's implementation. This would allow us to continue adding EventPipe-related features in the runtime and providing a supported mechanism for testing the capabilities. I believe this might require a new runtime Diagnostics IPC's "capability check" command. Given that user-events has already shipped in .NET 10, I think adding this capability check mechanism is OK, but something to consider for the future.
There was a problem hiding this comment.
Adding a bit more context. I briefly explored a standardized way to probe for CommandSet/CommandID availability (Dump/EventPipe/Profiler/Process) that would be backwards compatible with all prior runtime versions. An empty payload doesn't work (see dotnet/runtime#122257), so each CommandSet/CommandId requires a custom payload tailored to their parsing strategy to pass the UnknownCommand checkpoint and hit a separate error to not trigger the command.
Although this could work for Dump/EventPipe/Profiler, no custom payload can probe for Process commands availability without triggering the command, because Process commands trigger without a payload.
Due to the customization between CommandSets and even between CommandIDs (e.g. CollectTracing5 first deserializes a session_type whereas CollectTracing(2)(3)(4) first deserialize a circular_buffer_size, which have different "invalid" values) + it seems historically no one needed to query commandset/id availability + this seems to be the only mechanism in .NET 10 to detect user_events capability since dotnet-trace collect-linux/record-trace don't error even if no .NET 10 process is running, I felt that just adding a UserEvents EventPipe Command probe was more appropriate.
I do think that .NET 11 could introduce a probe command set that could return if any command set/id is supported (not just eventpipe) if there's a demand (maybe it fits as command set 0x00?), and it could possibly be made backwards compatible with older .NET versions by using customized payloads. Process commands would still be tricky for backwards compatibility given the empty payload design.
tommcdon
left a comment
tommcdon
left a comment
There was a problem hiding this comment.
Left a comment for your consideration, though given the necessity for this capability check I think this approach is reasonable.
2 participants
For an arbitrary .NET process, it's not obvious whether that .NET process supports emitting user_events dotnet/runtime#115265 without knowing the exact runtime version. To make it easier for users to probe a .NET process to determine whether they should use
dotnet-trace collect-linuxor fallbackdotnet-trace collectto collect .NET runtime events, this PR proposes a contract and API addition. To note,dotnet-trace collect-linuxwill not fail even though there may be no .NET processes capable of emitting user_events.