Skip to content

HDDS-13803. Client aware tracing#10077

Open
sravani-revuri wants to merge 6 commits intoapache:masterfrom
sravani-revuri:HDDS-13803
Open

HDDS-13803. Client aware tracing#10077
sravani-revuri wants to merge 6 commits intoapache:masterfrom
sravani-revuri:HDDS-13803

Conversation

@sravani-revuri
Copy link
Copy Markdown
Contributor

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.

  • When ozone.tracing.enabled is True:
    • The client uses the standard Ozone-initialized tracer (existing behavior).
  • When ozone.tracing.enabled is False:
    • If application-aware is True and an active span exists: The client will create child spans using the application’s GlobalOpenTelemetry context. This allows Ozone operations to appear as children of the application's spans.
    • If no active span exists: No spans are created (standalone tracing remains off).
    • If application-aware is 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.

@sravani-revuri
Copy link
Copy Markdown
Contributor Author

@sumitagrawl could you please review this.

Copy link
Copy Markdown
Contributor

@sreejasahithi sreejasahithi left a comment

Choose a reason for hiding this comment

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

Thanks @sravani-revuri for working on this.

Comment thread hadoop-hdds/common/src/main/java/org/apache/hadoop/hdds/tracing/TracingUtil.java Outdated
Comment thread hadoop-hdds/common/src/main/java/org/apache/hadoop/hdds/tracing/TracingUtil.java Outdated
@yandrey321
Copy link
Copy Markdown

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.

@sravani-revuri
Copy link
Copy Markdown
Contributor Author

there are way too many flags that control tracing behavior, can we simplify them and have no more than 2 control 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.

Also we need to make sure that documentation describes behavior of these switches.

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!

@adoroszlai
Copy link
Copy Markdown
Contributor

@sravani-revuri We could replace the two boolean config properties with ozone.tracing.mode enum of { OFF, CLIENT, FULL } (feel free to improve these names), default to CLIENT. We just need to set FULL if ozone.tracing.enabled=true, for compatibility.

@sravani-revuri
Copy link
Copy Markdown
Contributor Author

sravani-revuri commented Apr 23, 2026

@adoroszlai , @yandrey321 , @sumitagrawl cloud you please review these changes.

@adoroszlai adoroszlai requested review from sumitagrawl and removed request for sreejasahithi April 23, 2026 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants