Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HttpClient metrics for .NET Framework #4768

Closed

Conversation

matt-hensley
Copy link
Contributor

@matt-hensley matt-hensley commented Aug 14, 2023

Fixes #4764

Changes

Extends the existing tracing implementation to also generate metrics. This requires tracing to be enabled - while not ideal, this significantly limits the scope of changes to get metrics working.

To enable metrics, you must call AddHttpClientInstrumentation() on TracerProviderBuilder.

A single metric is published: http.client.duration, same as the .NET Core/.NET metrics implementation.

Unit tests have been modified to cover HttpClient metrics on .NET Framework. All unit test are passing.

Merge requirement checklist

  • CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
  • Unit tests added/updated
  • Appropriate CHANGELOG.md files updated for non-trivial changes
  • Changes in public API reviewed (if applicable)

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 14, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

@matt-hensley matt-hensley marked this pull request as ready for review August 17, 2023 02:13
@matt-hensley matt-hensley requested a review from a team as a code owner August 17, 2023 02:13
@codecov
Copy link

codecov bot commented Aug 18, 2023

Codecov Report

Merging #4768 (dadfeb4) into main (77b3a1e) will decrease coverage by 3.17%.
The diff coverage is 100.00%.

❗ Current head dadfeb4 differs from pull request most recent head 06c704b. Consider uploading reports for the commit 06c704b to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4768      +/-   ##
==========================================
- Coverage   85.46%   82.30%   -3.17%     
==========================================
  Files         314      314              
  Lines       12940    12956      +16     
==========================================
- Hits        11059    10663     -396     
- Misses       1881     2293     +412     
Files Changed Coverage Δ
...plementation/HttpWebRequestActivitySource.netfx.cs 81.41% <100.00%> (+0.55%) ⬆️
...rumentation.Http/MeterProviderBuilderExtensions.cs 100.00% <100.00%> (ø)

... and 22 files with indirect coverage changes

> Metrics are not available for .NET Framework.
> Metrics are only available for .NET Framework when traces are recorded. This requires:
> 1. Tracing to be enabled by calling `.AddHttpClientInstrumentation()` on `TracerProviderBuilder`
> 2. [If a sampler is in place, return `SamplingDecision.RecordAndSampled` for `ShouldSample`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/docs/trace/extending-the-sdk/README.md#filtering-processor)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nits:
"If a sampler" is not right, as there is always a sampler! Suggestion:
The sampler must return RecordAndSample for ever Activity in order for the Metrics to be accurate. If some spans (Activity) are sampled, but others not, it'll affect Metrics accuracy, as Metric Tags (Attributes) are generated based on the Activity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, the user provided Filters can also affect this,

if (!WebRequestActivitySource.HasListeners() || !Options.EventFilterHttpWebRequest(request))
.

  1. Enable tracing.
  2. Sampler returns RecordAndSample
  3. No user defined filters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest revisit the design of relying on Activity for generating metrics, and instead produce Metrics independently.
The approach done in this PR is more like a "Span2Metrics" processor, and can done as a regular ActivityProcessor instead, so it'll be easy to convey that Metrics are only as good as the underlying Activity.

Could you check how big of a change it'd to produce metrics independently? (It may not be as bad to rely on Activity for duration alone...but not for the whole tags.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did some research and have an idea. Could follow a similar pattern to HttpClient. The idea would be to:

  • Call ActivitySource.CreateActivity if tracing is enabled. This Activity would be used by metrics and traces
  • Instantiate a standalone Activity if only metrics are enabled. This wouldn't cause a trace to be emitted
  • Null Activity if neither metrics nor traces are enabled

If metrics or traces are enabled, the existing tags would still be set, with the only difference being whether the Activity ends up processed by an exporter.

Does this approach sound OK? There are some details to work through, but this looks feasible to me. Also welcome to other ideas if anyone has thoughts.

@github-actions
Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement support for metrics in HttpClient for .NET framework
4 participants