[🚀 Feature]: [dotnet] Support Activity monitoring

[nvborisenko]

Description

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.activitysource?view=net-11.0-pp

Low-level libraries like Selenium are able to emit information about commands/events. Selenium can support it for free, "one line" code.

Motivation

When I started to contribute, I continuosly was creating "helper projects" to see how fast Selenium is. We can do it built in easily.

Implementation

• Easy
• No extra dependencies
• Need to decide what we want to emit as "events"
• No performance penalty

Example

I successfully introduced it in https://github.com/nvborisenko/selenium.webdriver.bidi.cdp

Have you considered any alternatives or workarounds?

Currently only via internal logging.

[selenium-ci]

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[selenium-ci]

This issue is looking for contributors.

Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.

[ashrafiucse]

Hi, I'd like to work on this issue. 👋

Before starting the implementation, I'd like to align on a few design decisions:

1. Scope of emitted activities

• WebDriver commands — all commands naturally flow through WebDriver.ExecuteAsync() / HttpCommandExecutor.ExecuteAsync(), so emitting one ActivityKind.Client activity
  per command (name = command name, tags = session id, command, status) seems like the natural starting point.
• BiDi/CDP events — the reference implementation wraps event subscriptions with ActivityKind.Consumer activities. Should we include these in the first iteration, or start
  with commands only and add events as a follow-up?

2. Target framework support
Selenium.WebDriver targets net462; netstandard2.0; net8.0. ActivitySource is built into net8.0, but the older targets would require adding the
System.Diagnostics.DiagnosticSource NuGet package. Since the issue mentions "no extra dependencies" — is adding that package reference acceptable, or should the tracing code be
conditionally compiled / limited to net8.0?

3. ActivitySource naming
Any preference for the source name — Selenium, OpenQA.Selenium.WebDriver, or something else? This matters since it becomes the identifier users filter on (e.g., in
OpenTelemetry exporters).

My suggested minimal first iteration: an internal static SeleniumActivitySource + activity wrapping in WebDriver.ExecuteAsync() with error status on failures + unit tests,
keeping the diff small and reviewable. Happy to adjust based on your feedback.

cc @nvborisenko (since you have a working reference implementation — any other patterns worth carrying over?)

[nvborisenko]

• WebDriver.ExecuteAsync() for classic commands
• WebDriver holds internal static activity source (Selenium or Selenium.WebDriver)
• Classic commands.. DevTools (CDP).. BiDi.. should it be separate activity source?.. Not yet clear.
• External dependency for net462/netstandard2.0 is acceptable.

Everything else is clear. Put into tags whatever is available (rational, but without performance degradation).

[nvborisenko]

Giving some more context: webdriver classic commands will be replaced by BiDi internally soon, CDP is already "deprecated". I propose to focus on BiDi implementation only. Let's start from commands tracking:

selenium/dotnet/src/webdriver/BiDi/Broker.cs

Line 68 in 05423ea

public async Task<TResult> ExecuteAsync<TParameters, TResult>(string method, TParameters @params, JsonTypeInfo<TParameters> paramsTypeInfo, JsonTypeInfo<TResult> resultTypeInfo, CommandOptions? options, CancellationToken cancellationToken)

Points for implementation:

• new nuget dependency for net462/netstandard2.0 - it is OK. Still no extra dependencies for net8.0;
• performance: easily acceptable - internal static ActivitySource in the BiDi class, and per command it will be using var act = src.StartActivity(...) where act may be null. Super cheap.
• naming: I propose to name ActivitySource as Selenium.WebDriver - one single source for the entire assembly. Later, if we really want to split, think about use cases. Hopefully we will get some feedback to consider.
• naming: StartActivity for methods within string method (already available). For events: consumer with event name.

Everything else in PRs discussions. IMHO we already defined good start point. Please help who want to contribute.

PS: No new unit tests expected.

[diemol]

This would be great. So far, this has been implemented in Java using Open Telemetry.