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

Support for SamplerDetectors and EnvVarSamplerDetector #3635

Closed
wants to merge 11 commits into from

Conversation

Kielek
Copy link
Contributor

@Kielek Kielek commented Sep 7, 2022

Fixes #3601.

Changes

Please provide a brief description of the changes here.

  • Extend public API to provide the possibility to inject SamplerDetectors functionality (based on what was implemented for Resources)
  • Add support for detecting Samplers using OTEL_TRACES_SAMPLER and OTEL_TRACES_SAMPLER_ARG env vars for always_on, always_off, traceidratio, parentbased_always_on, parentbased_always_off, parentbased_traceidratio.
  • Defaults are unchanged.

For significant contributions please make sure you have completed the following items:

  • Appropriate CHANGELOG.md updated for non-trivial changes
  • Design discussion issue
  • Changes in public API reviewed

@Kielek Kielek requested a review from a team September 7, 2022 06:34
@Kielek Kielek force-pushed the sampler-from-env-variable branch from be986a8 to 973f289 Compare September 7, 2022 06:34
@codecov
Copy link

codecov bot commented Sep 7, 2022

Codecov Report

Merging #3635 (58ebd50) into main (5208ec0) will decrease coverage by 0.41%.
The diff coverage is 86.27%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3635      +/-   ##
==========================================
- Coverage   87.35%   86.94%   -0.42%     
==========================================
  Files         282      285       +3     
  Lines       10132    10179      +47     
==========================================
- Hits         8851     8850       -1     
- Misses       1281     1329      +48     
Impacted Files Coverage Δ
...c/OpenTelemetry/Trace/Sampling/AlwaysOffSampler.cs 100.00% <ø> (ø)
...rc/OpenTelemetry/Trace/Sampling/AlwaysOnSampler.cs 100.00% <ø> (ø)
...OpenTelemetry/Trace/Sampling/ParentBasedSampler.cs 100.00% <ø> (ø)
src/OpenTelemetry/Trace/Sampling/Sampler.cs 100.00% <ø> (ø)
...OpenTelemetry/Trace/Sampling/SamplingParameters.cs 92.30% <ø> (ø)
src/OpenTelemetry/Trace/Sampling/SamplingResult.cs 88.57% <ø> (ø)
...lemetry/Trace/Sampling/TraceIdRatioBasedSampler.cs 94.44% <ø> (ø)
...lemetry/Trace/Builder/TracerProviderBuilderBase.cs 88.59% <50.00%> (-3.23%) ⬇️
...y/Trace/Builder/TracerProviderBuilderExtensions.cs 85.10% <50.00%> (-12.46%) ⬇️
...emetry/Trace/Builder/TracerProviderBuilderState.cs 90.24% <75.00%> (-4.50%) ⬇️
... and 18 more

@@ -30,7 +30,7 @@ public static void Main()
{
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("MyCompany.MyProduct.MyLibrary")
.SetSampler(new AlwaysOnSampler())
.ConfigureSampler(x => x.SetDefaultSampler(new AlwaysOnSampler()))
Copy link
Member

Choose a reason for hiding this comment

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

I think it should be

.ConfigureSampler(x => x.Clear().SetDefaultSampler(new AlwaysOnSampler()))

Can you elaborate on why you suggest using the "builder API" instead of SetSampler if the user would like to always use one explicit sampler?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in fb11564.

New API provide broader functionalities so it should be used in all examples in the repository.


double ratio = defaultRatio;

if (hasValue && double.TryParse(envVarValue, out double parsedRatio) && parsedRatio >= 0.0 && parsedRatio <= 1.0)
Copy link
Member

Choose a reason for hiding this comment

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

We should throw a FormatException if the ratio is bad. Example in other place:

throw new FormatException($"{ProtocolEnvVarName} environment variable has an invalid value: '{protocolEnvVar}'");

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have tried to avoid throwing exceptions.
I think that both solutions should be fine.

@open-telemetry/dotnet-approvers, any preferences/comments what is the better option?

Copy link
Member

Choose a reason for hiding this comment

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

Take notice that EnvironmentVariableHelper is throwing FormatException when it fails to parse the value.

@@ -335,6 +335,22 @@ Custom resource detectors can be implemented:

A demo ResourceDetector is shown [here](./MyResourceDetector.cs).

## Sampler Detector

OpenTelemetry .NET SDK provides a sampler detector for detecting sampler
Copy link
Member

Choose a reason for hiding this comment

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

mm.. I am not sure of the need of such a new api. Can we simply modify SDK to automatically pick Sampler from Env Variables?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see some benefits for having builder with detectors:

  • possibility to programmatically disable env. vars.
  • easily add more samplers supported by the env. vars. You can just implement externally support for other samplers without taking care about parsing values for common samplers. Please consider something like XRayOTelEnvVarSamplerDetector. With current design it could be chained with current CommonEnvVar Detector.

Copy link
Member

Choose a reason for hiding this comment

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

There are issues with the existing environment variable stuff. Primarily, it doesn't work with IConfiguration/IOptions. This is something I am looking at, hoping to find a new pattern that smooths all of this out. Probably first to drive #3583. I would vote to wait on this sorry @Kielek I know that is probably frustrating!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we speaking about timeframe, it will be great to include it at least based env. var. support for 1.4.0 release. We would like to give AutoInstrumentation users some flexibility here.

I know that we will need more thing configurable in the future so I will observe issue you have mentioned.

Copy link
Member

@pellared pellared left a comment

Choose a reason for hiding this comment

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

in current state: LGTM

Mainly, because it is consistent with existing API/design.

@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.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Sep 20, 2022
@github-actions
Copy link
Contributor

Closed as inactive. Feel free to reopen if this PR is still being worked on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issues and pull requests which have been flagged for closing due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for OTEL_TRACES_SAMPLER and OTEL_TRACES_SAMPLER_ARG
4 participants