TracingProviders: Add Dynatrace trace provider#3003
TracingProviders: Add Dynatrace trace provider#3003joaopgrassi wants to merge 1 commit intoistio:masterfrom
Conversation
istio-testing
added
do-not-merge/work-in-progress
|
Hi @joaopgrassi. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
istio-testing
removed
the
do-not-merge/work-in-progress
istio-testing
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/ok-to-test |
istio-testing
added
ok-to-test
|
Instead of adding more and more providers, it seems OTEL is the generic way to do |
|
#2998 merged, can we close this? cc @joaopgrassi |
|
@zirain yes I believe the direction is to add the opentelemetry configuration and not vendor specific. I will close this. Thanks! |
5 participants
In #47453 I proposed to add a new tracing provider in Istio for Dynatrace. The idea was to add a provider for Dynatrace that "wraps" the OpenTelemetry one in Istio, offering easy of configuration to our customers.
The community opinion was that this was not a good idea as there's a desire to decrease vendor code in MeshConfig. It was advised to simply instruct users to use the OTel provider already available today.
I opened now initial PRs to extend the OTel provider in Istio to support the new Envoy features #3002. The goal of this PR is to offer a comparison to the community of how much config going with a Dynatrace extension would be compared to extending the OpenTelemetry one. Mainly for the concern of adding more things to MeshConfig. This route is much simpler, with the caveat that it's custom tailored to Dynatrace users, whereas the one in #3002 can benefit everyone.