-
Notifications
You must be signed in to change notification settings - Fork 375
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
Move _dd.apm.enabled
tag in tracing root span
#4141
base: master
Are you sure you want to change the base?
Conversation
BenchmarksBenchmark execution time: 2024-12-10 15:36:54 Comparing candidate commit eeffb42 in PR branch Found 1 performance improvements and 0 performance regressions! Performance is the same for 30 metrics, 2 unstable metrics. scenario:profiler - sample timeline=false
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4141 +/- ##
==========================================
+ Coverage 97.77% 97.78% +0.01%
==========================================
Files 1357 1355 -2
Lines 81973 82015 +42
Branches 4168 4173 +5
==========================================
+ Hits 80145 80195 +50
+ Misses 1828 1820 -8 ☔ View full report in Codecov by Sentry. |
# We add this metric when ASM standalone is enabled to make sure we don't bill APM | ||
if Datadog.configuration.appsec.standalone.enabled | ||
request_span.set_metric(Tracing::Metadata::Ext::TAG_APM_ENABLED, 0) | ||
end |
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.
In #3965 @anmarchenko mentioned tracing gaining a dependency on appsec and that pattern appears to continue here. I my opinion it would be better for tracing to provide hooks that appsec will hook into to avoid tracing referencing appsec in code, but I am not developing either part of the library.
I do also find it hard to ascertain whether the code behaves correctly - this PR sets APM enabled to 0 from tracing, but it is not clear from the diff where/under what conditions APM enabled is set to 1 (or if that happens at all).
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.
Can you elaborate the reason about tagging a rack
span specifically?
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.
The env var name DD_EXPERIMENTAL_APPSEC_STANDALONE_ENABLED
is temporary, and what Standalone Appsec actually does is disabling tracing (or more precisely rate-limiting it at 1 trace per minute), and when 'Appsec' is activated along 'Standalone Appsec' (as Standalone Appsec does not in fact activate Appsec by itself), it force-keep traces that contains Appsec events.
There is a RFC currently being reviewed to find the final name for this env var, which will most likely be DD_TRACE_APM_ENABLED
. When it will be approved, I will also change the configuration from Datadog.configuration.appsec.standalone.enabled
to something like Datadog.configuration.tracing.apm.enabled
, which will make more sense and show that there is no dependency from appsec in tracing (but the other way will be true, which already is anyway)
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.
Can you elaborate the reason about tagging a rack span specifically?
For now, the only product other than tracing that uses traces is Appsec, and in Appsec we only instrument rack-based apps (Rails, Sinatra, Rack itself...)
But maybe we could tag somewhere else, like in http frameworks, now that we have moved this part in tracing. What do you think of adding that tag on the HTTP level ? Or should we stick to Rack, and maybe also add other frameworks like sidekiq ?
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.
I understand this is experimental feature but similar concern with shotgun surgery and product coupling has been raised in the previous pull request code review, that signals the severity of design issue.
- It is hard to make sense of the convention and logic using
Datadog.configuration.tracing.apm.enabled
, which APM includes multiple products includingprofiling
. - I can see similar approach like
rack
, that AppSec contains the 3rd party patches that depends on TraceOperation. - Or maybe other kinds of dependency injection mechanism
Overall, the requirements (some kinds of hook systems, perhaps could be encompassed by @lloeki 's Instrumentation API ?) are not clear and I am afraid that if we are indifferent now could cast a long shadow in the future.
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.
does it make sense to find the root span here and not the rack span?
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.
Yes, this is changed in e0c503a
Note that "non-billing" naming is temporary.
.github/workflows/system-tests.yml
Outdated
@@ -11,7 +11,7 @@ on: | |||
env: | |||
REGISTRY: ghcr.io | |||
REPO: ghcr.io/datadog/dd-trace-rb | |||
SYSTEM_TESTS_REF: main # This must always be set to `main` on dd-trace-rb's master branch | |||
SYSTEM_TESTS_REF: igor/standalone-sca # This must always be set to `main` on dd-trace-rb's master branch |
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.
reminder: please change this branch to master before merging
# We add this metric when ASM standalone is enabled to make sure we don't bill APM | ||
if Datadog.configuration.appsec.standalone.enabled | ||
request_span.set_metric(Tracing::Metadata::Ext::TAG_APM_ENABLED, 0) | ||
end |
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.
does it make sense to find the root span here and not the rack span?
As of 27th. of November, the scope of this PR has been changed to moving all "non-billing" mode code to Tracing part. |
_dd.apm.enabled
tag in tracing Rack middleware_dd.apm.enabled
tag in tracing root span
7ee5c9f
to
e6639a4
Compare
Datadog ReportBranch report: ✅ 0 Failed, 22057 Passed, 1458 Skipped, 6m 10.58s Total Time ⌛ Performance Regressions vs Default Branch (1)
|
2061cce
to
e8acbf8
Compare
… non-billing mode
c28f69f
to
3142efb
Compare
👋 Hey @DataDog/ruby-guild, please fill "Change log entry" section in the pull request description. If changes need to be present in CHANGELOG.md you can state it this way **Change log entry**
Yes. A brief summary to be placed into the CHANGELOG.md (possible answers Yes/Yep/Yeah) Or you can opt out like that **Change log entry**
None. (possible answers No/Nope/None) Visited at: 2024-12-10 15:07:36 UTC |
84c2916
to
eeffb42
Compare
# unless specific distributed tags are present. These tags can come from upstream | ||
# services, or from the service itself. | ||
# For now, only '_dd.p.appsec=1' is supported. | ||
def non_billing_reject? |
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.
This method name contains two negatives. I would prefer something like should_send?
for example but before renaming let's figure out the overall name for the setting.
@@ -12,6 +12,7 @@ module Ext | |||
ENV_OTEL_TRACES_EXPORTER = 'OTEL_TRACES_EXPORTER' | |||
ENV_HEADER_TAGS = 'DD_TRACE_HEADER_TAGS' | |||
ENV_TRACE_ID_128_BIT_GENERATION_ENABLED = 'DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED' | |||
ENV_APM_ENABLED = 'DD_EXPERIMENTAL_APPSEC_STANDALONE_ENABLED' # Temporary until RFC decides final name |
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.
Could we highlight that "temporary" nature in the name? It's a big ask to name it ENV_APM_ENABLED
, but actually check for standalone feature
P.S let's do it only if it makes sense (merged before RFC is in final state)
What does this PR do?
_dd.apm.enabled
tag to spans in tracing root spans.It does NOT change the env var DD_EXPERIMENTAL_APPSEC_STANDALONE_ENABLED to a new one (as the discussion is still ongoing and most likely will stay continue until next quarter)
Motivation:
During the review of Standalone SCA system-tests, I found out that enabling 'Standalone Appsec Billing' (
DD_EXPERIMENTAL_APPSEC_STANDALONE_ENABLED=true
) and disabling 'Appsec Threats' (DD_APPSEC_ENABLED=false
) would make the tests fails as_dd.apm.enabled
is set in appsec Rack middleware.This is not correct as this tag is suppose to communicate to the Agent that we should not bill for APM traces, and Standalone Appsec Billing will still limit the number of traces to 1 per minute to keep services alive on the backend side even if Appsec Threats is not enabled, thus the traces must contain that tag. But appsec can have a lot of different service as root span, so we must add it in other integrations too.
Change log entry
None.
How to test the change?
Standalone SCA system-tests (./run.sh SCA_STANDALONE) should XPASS (or pass if force executed)