-
Notifications
You must be signed in to change notification settings - Fork 126
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
Demonstrate file based configuration of RuleBasedRoutingSampler #227
base: main
Are you sure you want to change the base?
Demonstrate file based configuration of RuleBasedRoutingSampler #227
Conversation
Very interesting @jack-berg. Thanks for putting this together. I am one of many users of OTEL who wanted this feature implemented to exclude certain URL endpoints.
I am new to this project so apologies for my lack of knowledge but I'm eager to help contribute to the relevant repositories to support the integration of this feature. Could you briefly elaborate on which specific repositories require these changes to implement this feature, or any other guidance for a new contributor like myself. Thanks! |
Sure - I left a list of the required pieces in the PR description. A lot of the work is done, but we need review on the critical path. The critical path is something like:
|
Sounds like there is a lot of work already done, thanks @jack-berg! Looks like there is not much to do code-wise. |
Part of incorporating [OTEP #225](open-telemetry/oteps#225) into the specification. Followup to #3744. This defines how file configuration works with custom SDK extension components (Samplers, Exporters, etc). It defines the concept of a Component Provider: - Component providers are registered with the type of extension component they provide and a name. Component providers are registered automatically or manually based on what is idiomatic in the language. - Component providers have a Create Plugin method, which passes configuration properties as a parameter and returns the configured component - When Create is called to interpret a file configuration model, and it comes across a reference to a extension component which is not built-in, it invokes Create Plugin on the corresponding component provider. If no corresponding component provider exists, or if Create Plugin returns an Error, Create returns an error. Prototype implementation in java here: open-telemetry/opentelemetry-java-examples#227 cc @open-telemetry/configuration-maintainers
…lemetry#3802) Part of incorporating [OTEP open-telemetry#225](open-telemetry/oteps#225) into the specification. Followup to open-telemetry#3744. This defines how file configuration works with custom SDK extension components (Samplers, Exporters, etc). It defines the concept of a Component Provider: - Component providers are registered with the type of extension component they provide and a name. Component providers are registered automatically or manually based on what is idiomatic in the language. - Component providers have a Create Plugin method, which passes configuration properties as a parameter and returns the configured component - When Create is called to interpret a file configuration model, and it comes across a reference to a extension component which is not built-in, it invokes Create Plugin on the corresponding component provider. If no corresponding component provider exists, or if Create Plugin returns an Error, Create returns an error. Prototype implementation in java here: open-telemetry/opentelemetry-java-examples#227 cc @open-telemetry/configuration-maintainers
This demonstrates how file based configuration can be used to easily configure RuleBasedRoutingSampler to drop spans with match a particular pattern. It requires changes to several repos, but if the changes were adopted and file configuration and
RuleBasedRoutingSampler
were enabled in the java agent, this would effectively solve Exclude URLs from Tracing (the most upvoted open issue in opentelemetry-java-instrumentation).Other required changes:
If we do all this, we can reference RuleBasedRoutingSampler in file configuration, and specify its configuration with an ergonomic scheme that matches the programatic API:
I have all these changes made locally and published to maven local. I've updated the example to include spring boot, and the spring boot actuator which adds a health check endpoint (and various other /actuator.* endpoints) that users often want to drop.
If I run the app, and curl the health check endpoint we wish to drop (
curl localhost:8080/actuator/health
) and an application endpoint we wish to keep (curl localhost:8080/ping
), we can see in the application output that we see the desired outcome:Notice I log the
OpenTelemetrySdk#toString()
at application start and we seeRuleBasedRoutingSampler
with our desired config.Notice that we only see the
LoggingSpanExporter
print the span forhttp.target=/ping
, and NOT forhttp.target=/actuator/health
.Let me know what you think! Hoping we can use this as a catalyst for landing these updates, and for ultimately packaging file based configuration and rule based routing sampler with the java agent.