-
Notifications
You must be signed in to change notification settings - Fork 773
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
OTLP exporter options separate out MetricReader options #2717
OTLP exporter options separate out MetricReader options #2717
Conversation
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpMetricReaderOptions.cs
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #2717 +/- ##
==========================================
- Coverage 84.41% 83.88% -0.54%
==========================================
Files 252 253 +1
Lines 8893 8910 +17
==========================================
- Hits 7507 7474 -33
- Misses 1386 1436 +50
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach is great!
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpMetricExporterExtensions.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpMetricExporterExtensions.cs
Outdated
Show resolved
Hide resolved
@CodeBlanch requested I convert this to draft for now. He's working on another approach and we'd like to give people a chance to compare. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm liking this option
…lative temporality
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpMetricExporterExtensions.cs
Outdated
Show resolved
Hide resolved
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. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
…thub.com:alanwest/opentelemetry-dotnet into alanwest/otlp-separate-out-metric-reader-options
/// <returns>The instance of <see cref="MeterProviderBuilder"/> to chain the calls.</returns> | ||
public static MeterProviderBuilder AddOtlpExporter( | ||
this MeterProviderBuilder builder, | ||
Action<OtlpExporterOptions, MetricReaderOptions> configureExporterAndMetricReader) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AddOtlpExporter(Action<OtlpExporterOptions> configureExporter, Action <MetricReaderOptions> configureMetricReader)
^ would this be more easy to use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe? It depends on who you ask 😄. I do not personally have a strong preference either way.
But... I think I may have landed on this solution in part because we're anticipating following this pattern eventually with traces as well. If I recall, the one issue I encountered was that we have
public static TracerProviderBuilder AddOtlpExporter(
this TracerProviderBuilder builder,
Action<OtlpExporterOptions> configure = null)
Because of the default parameter for configure
we can't introduce the following because the methods would be ambiguous if someone were just calling this with no parameters AddOtlpExporter()
<- this now does not compile.
public static TracerProviderBuilder AddOtlpExporter(
this TracerProviderBuilder builder,
Action<OtlpExporterOptions> configure = null,
Action<ProcessorOptions> configureProcessor = null)
... though this was a while ago, so I may not have my head on straight about this 😄 - I'll try it out and refresh my memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:) not a blocker.
var metricExporter = new OtlpMetricExporter(options); | ||
var metricExporter = new OtlpMetricExporter(exporterOptions); | ||
|
||
if (metricReaderOptions.MetricReaderType == (MetricReaderType)(-1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets take this as a follow up to decide
- What should be the MetricReaderType default
- Would that be same for all exporters (Console , OTLP). Or do we want separate defaults.
Not blocking this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to #2552.
This separates out options meant for configuring the MetricReader when using the
AddOltpExporter
extension method.I think this PR is a better alternative to #2716. However unlike #2716 it does not attempt to add support the for the
OTEL_EXPORTER_OTLP_METRICS_*
environment variables. This could be a follow up PR.If folks like this approach, I can port it to the Console and In-memory metric exporters.