-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
chore: Update ObservationHelper to allow sampling of spans #37345
Conversation
WalkthroughThe changes in this pull request focus on the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
app/server/appsmith-server/src/main/java/com/appsmith/server/helpers/ObservationHelperImpl.java (1)
Increased Trace Data Volume Due to Forced Sampling
The
createSpan
method now forces sampling on all spans, which overrides existing sampling configurations (commonConfig.isTracingDetail
). This could lead to increased trace data volume.
- Consider reverting to conditional sampling based on configuration.
🔗 Analysis chain
Line range hint
26-42
: Verify impact on trace data volumeThe createSpan method now forces sampling on all spans which could significantly increase the volume of trace data collected. Please verify:
- The impact on your tracing backend system's capacity
- Any cost implications of increased trace volume
- Whether selective sampling based on span name or context would be more appropriate
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other sampling configurations that might conflict rg -l "sampled\(" | xargs rg "commonConfig.*isTracingDetail|sampling.*configuration" # Look for other span creation points ast-grep --pattern 'spanBuilder().setParent($$$).name($$$).start()'Length of output: 274
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
app/server/appsmith-server/src/main/java/com/appsmith/server/helpers/ObservationHelperImpl.java
(1 hunks)
@@ -32,6 +32,7 @@ public Span createSpan(String name) { | |||
return Span.NOOP; | |||
} else { | |||
TraceContext traceContext = tracer.traceContextBuilder() | |||
.sampled(true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider making sampling configurable instead of hardcoding
While forcing sampling on can help with debugging, it may impact performance in production. Consider making this configurable through CommonConfig similar to how isTracingDetail() is used.
Here's a suggested approach:
+ private final boolean forceSampling;
+
+ public ObservationHelperImpl(Optional<Tracer> tracer, CommonConfig commonConfig) {
+ this.commonConfig = commonConfig;
+ this.tracer = tracer.orElse(Tracer.NOOP);
+ this.forceSampling = commonConfig.isTracingDetail();
+ }
TraceContext traceContext = tracer.traceContextBuilder()
- .sampled(true)
+ .sampled(forceSampling)
.traceId(contextMap.get(TRACE_ID))
Committable suggestion skipped: line range outside the PR's diff.
Failed server tests
|
Description
Tip
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.
Fixes #
Issue Number
or
Fixes
Issue URL
Warning
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.
Automation
/ok-to-test tags=""
🔍 Cypress test results
Caution
If you modify the content in this section, you are likely to disrupt the CI result for your PR.
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit
New Features
Bug Fixes