[processor/tailsampling] Support extensions#42573
Merged
Merged
Conversation
Contributor
|
Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib. Important reminders:
A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better! |
Contributor
|
Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib. Important reminders:
A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better! |
csmarchbanks
force-pushed
the
tsp-extensions
branch
from
1618cfc to
d0fb27f
Compare
yvrhdn
reviewed
Sep 9, 2025
Allow the Tail Sampling Processor to use extensions that implement an interface simply containing NewEvaluator. To use an extension all that needs to be done is specify the extension's type/name such as my_extension or my_extension/my_name in the type field of the policy configuration. When configuration is loaded/updated the extension will be called in order to create a new evaluator. Extensions can be configured in two places. First, in the extensions section like all other extensions. This is useful for configuration such as if an extension needs to connect to an external service. In addition, an object can defined under the "extension" key the policy config for anything related to one instance. This is useful when reusing the same extension e.g. different params for different services.
This matches all of the other policy types where the key for the
configuration matches the type of the policy. E.g. you configure
ottl_condition by setting ottl_condition: {...}
It can be useful for an instance of an evaluator to know the name of the policy for debugging or reporting purposes. Since a single type can be used multiple times with different configuration.
csmarchbanks
force-pushed
the
tsp-extensions
branch
2 times, most recently
from
e8f1241 to
e6fe359
Compare
csmarchbanks
force-pushed
the
tsp-extensions
branch
from
c435ece to
89593d7
Compare
csmarchbanks
force-pushed
the
tsp-extensions
branch
from
89593d7 to
a3ea3df
Compare
yvrhdn
approved these changes
Sep 11, 2025
Contributor
|
@portertech please review as codeowner, thanks! |
portertech
approved these changes
Sep 18, 2025
Contributor
Author
|
This has codeowner approval now, anything else needed before merge? |
ArthurSens
added
ready to merge
atoulme
approved these changes
Oct 4, 2025
Contributor
|
Thank you for your contribution @csmarchbanks! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. |
This was referenced Apr 10, 2026
atoulme
pushed a commit
that referenced
this pull request
Apr 23, 2026
…47535) #### Description Replaces @Logiraptor with @csmarchbanks as a codeowner of the tail sampling processor as I have been more active recently and @Logiraptor is working on other efforts. In addition, adds @carsonip as a new code owner. Some of my TSP efforts: * #42573 * #44878 * #45286 * #46161 TSP work that @carsonip has done: * #43561 * #46762 * #42326
AndrewCharlesHay
pushed a commit
to AndrewCharlesHay/opentelemetry-collector-contrib
that referenced
this pull request
Apr 23, 2026
…pen-telemetry#47535) #### Description Replaces @Logiraptor with @csmarchbanks as a codeowner of the tail sampling processor as I have been more active recently and @Logiraptor is working on other efforts. In addition, adds @carsonip as a new code owner. Some of my TSP efforts: * open-telemetry#42573 * open-telemetry#44878 * open-telemetry#45286 * open-telemetry#46161 TSP work that @carsonip has done: * open-telemetry#43561 * open-telemetry#46762 * open-telemetry#42326
gracewehner
pushed a commit
to gracewehner/opentelemetry-collector-contrib
that referenced
this pull request
Apr 29, 2026
…pen-telemetry#47535) #### Description Replaces @Logiraptor with @csmarchbanks as a codeowner of the tail sampling processor as I have been more active recently and @Logiraptor is working on other efforts. In addition, adds @carsonip as a new code owner. Some of my TSP efforts: * open-telemetry#42573 * open-telemetry#44878 * open-telemetry#45286 * open-telemetry#46161 TSP work that @carsonip has done: * open-telemetry#43561 * open-telemetry#46762 * open-telemetry#42326
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Allow the Tail Sampling Processor to use extensions that implement an interface simply containing NewEvaluator. To use an extension all that needs to be done is specify the extension's type/name such as my_extension or my_extension/my_name in the type field of the policy configuration. When configuration is loaded or updated NewEvaluator will be called.
Extensions can be configured in two places. First, in the extensions section like all other extensions. This is useful for configuration such as if an extension needs to connect to an external service. In addition, configuration can be defined in the policy config under a key matching the type of the extension for anything related to one instance, following the pattern for all other policy types. This is useful when reusing the same extension e.g. different params for different services. For example:
What this ends up with is that extensions look exactly like all other policy types with no need for users to know about some sort of extension container.
I have tested this out with an extension in a custom build and it is working well, I am sure we will iterate on the interfaces a bit as we write more. Specifically a way to stop the extension when policies are updated may be necessary to clean up any background processes. @yvrhdn is working on an extension we plan to add to contrib as well.
Link to tracking issue
Part of #31582