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

Capture http.server.duration metric for ASP.NET Core instrumentation #1347

Conversation

alanwest
Copy link
Member

@alanwest alanwest commented Oct 13, 2020

First steps in addressing #1269.

This PR captures the http.server.duration metric for ASP.NET Core.

Opening as draft for now as there are a number of TODOs peppered through the code. A few more TODOs not called out in the code:

  • Unit tests
  • Use SemanticConventions instead of string literals for attribute names

@alanwest alanwest requested a review from a team October 13, 2020 22:01
@alanwest alanwest marked this pull request as draft October 13, 2020 22:01
@codecov
Copy link

codecov bot commented Oct 13, 2020

Codecov Report

Merging #1347 (3cb3749) into metrics (6d6a045) will decrease coverage by 2.20%.
The diff coverage is 93.65%.

❗ Current head 3cb3749 differs from pull request most recent head 35dfefc. Consider uploading reports for the commit 35dfefc to get more accurate results
Impacted file tree graph

@@             Coverage Diff             @@
##           metrics    #1347      +/-   ##
===========================================
- Coverage    84.61%   82.40%   -2.21%     
===========================================
  Files          245      232      -13     
  Lines         6974     6156     -818     
===========================================
- Hits          5901     5073     -828     
- Misses        1073     1083      +10     
Impacted Files Coverage Δ
...AspNetCore/Implementation/HttpInMetricsListener.cs 87.50% <87.50%> (ø)
src/OpenTelemetry/Metrics/MeterProviderBuilder.cs 97.05% <92.85%> (-2.95%) ⬇️
...ry.Instrumentation.AspNetCore/AspNetCoreMetrics.cs 100.00% <100.00%> (ø)
...ation.AspNetCore/MeterProviderBuilderExtensions.cs 100.00% <100.00%> (ø)
src/OpenTelemetry/Metrics/MeterProviderSdk.cs 95.45% <100.00%> (+2.12%) ⬆️
src/OpenTelemetry/Internal/SelfDiagnostics.cs 0.00% <0.00%> (-100.00%) ⬇️
...Telemetry/Internal/SelfDiagnosticsEventListener.cs 0.00% <0.00%> (-96.59%) ⬇️
src/OpenTelemetry/Logs/OpenTelemetryLogger.cs 0.00% <0.00%> (-93.94%) ⬇️
src/OpenTelemetry/Logs/LogRecord.cs 0.00% <0.00%> (-92.50%) ⬇️
...lemetry/Internal/SelfDiagnosticsConfigRefresher.cs 0.00% <0.00%> (-89.72%) ⬇️
... and 140 more

}

// TODO: Currently these options are unused for metrics.
// Do we need separate options for metrics, or will the same options used for traces make sense for metrics?
Copy link
Member

@reyang reyang Oct 13, 2020

Choose a reason for hiding this comment

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

I think having one Options across traces/logs/metrics is more friendly for the user.

FYI - I think some of the exporters will move towards that direction (e.g. a single ConsoleExporter targeting logs/traces/metrics)

public class InMemoryExporter<T> : BaseExporter<T>

Copy link
Member

Choose a reason for hiding this comment

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

What are some of the possible things which can be configured in metricOptions? Do we need to allow user to specify labels? Or we always get all the labels as per semantic convention, and users can configure metric Views to drop any labels they dont care.

Copy link
Member Author

Choose a reason for hiding this comment

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

There's nothing I'm aware of currently in the spec regarding the ability to configure labels to include/exclude. The concept of metric views is still in a proposed state open-telemetry/oteps#89.

For the purpose of this work, it may just make sense to remove the ability to specify options for now. That is, the AspNetCoreInstrumentationOptions currently has options that are not really yet applicable in the context of metrics. I think the one thing that makes sense in the Filter delegate to suppress capturing metrics based on certain criteria.

}

// TODO: Prometheus pulls metrics by invoking the /metrics endpoint. Decide if it makes sense to suppress this.
// Below is just a temporary way of achieving this suppression for metrics (we should consider suppressing traces too).
Copy link
Member

Choose a reason for hiding this comment

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

yes, eventually we can leverage the SupressInstrumentation API for this.

Copy link
Member

@cijothomas cijothomas left a comment

Choose a reason for hiding this comment

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

Overall LGTM.
We may want to do benchmark about Ds Subsciption before finalizing this approach.

@alanwest alanwest marked this pull request as ready for review November 4, 2020 01:43
@eddynaka eddynaka changed the base branch from master to main January 27, 2021 22:16
@cijothomas cijothomas changed the base branch from main to metrics February 5, 2021 22:20
@alanwest alanwest closed this Apr 8, 2021
@alanwest alanwest deleted the alanwest/http-metrics-aspnetcore branch October 22, 2021 16:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants