HDDS-13803. Client aware tracing#10077
Conversation
|
@sumitagrawl could you please review this. |
sreejasahithi
left a comment
There was a problem hiding this comment.
Thanks @sravani-revuri for working on this.
|
there are way too many flags that control tracing behavior, can we simplify them and have no more than 2 control switches. Also we need to make sure that documentation describes behavior of these switches. |
Thanks for the feedback @yandrey321 ! After consideration, it might be better to stick with separate configs for now. Keeping one for enabling tracing would leave another one for trace sampling ,span sampling and endpoint configuration. Combining these would make it hard to understand and use.
I have improved description for the configs to ensure their functionality is explained. Please let me know if you have any suggestions to improve this regarding the configs! |
|
@sravani-revuri We could replace the two boolean config properties with |
|
@adoroszlai , @yandrey321 , @sumitagrawl cloud you please review these changes. |
What changes were proposed in this pull request?
The Ozone client needs the flexibility to either initiate a new span or continue an existing application-level trace by creating a child span. Currently, if ozone.tracing.enabled is false, all tracing is suppressed. A specific scenario arises when the Ozone client should only trace if it's explicitly enabled to continue an application's existing trace.
ozone.tracing.enabledis True:ozone.tracing.enabledis False:application-awareis True and an active span exists: The client will create child spans using the application’sGlobalOpenTelemetrycontext. This allows Ozone operations to appear as children of the application's spans.application-awareis False: No spans are created regardless of the application context.What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-13803
How was this patch tested?
Written unit tests and existing tests.