-
Notifications
You must be signed in to change notification settings - Fork 394
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
Update trace propagation format for botocore direct invocations #2639
Update trace propagation format for botocore direct invocations #2639
Conversation
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'm thinking we should leave the old method behind a configuration option since a bunch of users will not be on the latest version of the serverless client(s) 🤔
Thoughts @agocs?
@Kyle-Verhoog I can get behind that. I considered it, but initially decided against it as this is such a niche change. Definitely happy to add that parameter though. Which way do you think the default should go? I was thinking it should favor the new, working trace propagation format. Oh, and is this the extent of the configuration, or is there a config file hiding somewhere I don't know about? https://docs.datadoghq.com/tracing/setup_overview/setup/python/?tab=otherenvironments#configuration |
Yup - agreed 👍 The configuration option can be added here: dd-trace-py/ddtrace/contrib/botocore/patch.py Lines 35 to 41 in 7e1d82a
and then documented here dd-trace-py/ddtrace/contrib/botocore/__init__.py Lines 16 to 20 in 7e1d82a
(this will show up here: https://ddtrace.readthedocs.io/en/stable/integrations.html#botocore) Also an $ reno new botocore |
Awesome! I appreciate it! |
…ion_trace_propagation_format
@Kyle-Verhoog Changes made! Thanks. Should I drop a link to this in the apm-python channel? |
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.
👍 solid tests - thanks for also keeping a test with the old setting! Just some suggestions around the user-facing aspects 🙂
ddtrace/contrib/botocore/patch.py
Outdated
@@ -37,6 +37,9 @@ | |||
"botocore", | |||
{ | |||
"distributed_tracing": get_env("botocore", "distributed_tracing", default=True), | |||
"clientcontext_custom_add_datadog_object": get_env( | |||
"botocore", "clientcontext_custom_add_datadog_object", default=False |
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.
"botocore", "clientcontext_custom_add_datadog_object", default=False | |
"botocore", "legacy_context", default=False |
Not 100% about this suggesting.. aiming toward something less verbose - I don't think the name has to divulge the implementation details here... unless we're planning in the future to change this implementation again 😬
@DataDog/apm-python any ideas for naming here?
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.
invoke_with_legacy_context
?
ddtrace/contrib/botocore/__init__.py
Outdated
@@ -24,6 +24,25 @@ | |||
|
|||
Default: ``True`` | |||
|
|||
.. py:data:: ddtrace.config.botocore['clientcontext_custom_add_datadog_object'] | |||
|
|||
When a tracing a directly invoked lambda function, the trace context is added to the |
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 description is awesome but probably a bit too verbose for users who might get lost in the details. The important part is the version support listed below. WDYT about trimming it down?
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.
👍
Mutate client_context_object instead of returning Co-authored-by: Kyle Verhoog <kyle@verhoog.ca>
Co-authored-by: Kyle Verhoog <kyle@verhoog.ca>
…pagation_format' of github.com:DataDog/dd-trace-py into chris.agocs/update_botocore_direct_invocation_trace_propagation_format
…ion_trace_propagation_format
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.
nice! just some last concerns about the release note but otherwise lgtm!
@@ -0,0 +1,4 @@ | |||
--- | |||
features: |
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 should be an upgrade
-level note mentioning the change and the backwards compatibility option as users using older python/node lambda client versions will have a breaking change
@@ -24,6 +24,19 @@ | |||
|
|||
Default: ``True`` | |||
|
|||
.. py:data:: ddtrace.config.botocore['invoke_with_legacy_context'] |
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 think I'm good with this name.
@DataDog/apm-python thoughts?
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.
👍🏻
--- | ||
features: | ||
- | | ||
botocore: added `invoke_with_legacy_context` configuration setting, which is disabled by default. This configuration setting is to preserve a legacy behavior in which, when tracing a direct lambda invocation, trace context was propagated by storing it in a `_datadog` object in `context.clientContext.custom`. This must be set to True if you are invoking Lambda functions instrumented with datadog-lambda-python < v41 or datadog-lambda-js < v3.57.0. However, if set to True, invocations to Go or Java Lambda functions may fail. |
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'd probably trim this down as well. From the user standpoint they just need to know that context management support has been added for newer lambda libraries and that there is a legacy configuration option in-case they wish to run an older version.
👍 for mentioning the specific versions of each library.
Would also be good to explicitly show the configuration options, something like:
Legacy support for older libraries is available with ddtrace.config.botocore.invoke_with_legacy_context = True or by setting the environment variable DD_BOTOCORE_INVOKE_WITH_LEGACY_CONTEXT=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.
I'd like to see it explicitly mentioned that the propagation will break for users using datadog-lambda-python < v41 or datadog-lambda-js < v3.57.0
first and then mention the introduction of the legacy setting that can be used to support these older versions.
…ion_trace_propagation_format
…pagation_format' of github.com:DataDog/dd-trace-py into chris.agocs/update_botocore_direct_invocation_trace_propagation_format
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.
Just one more thought on the release note!
--- | ||
features: | ||
- | | ||
botocore: added `invoke_with_legacy_context` configuration setting, which is disabled by default. This configuration setting is to preserve a legacy behavior in which, when tracing a direct lambda invocation, trace context was propagated by storing it in a `_datadog` object in `context.clientContext.custom`. This must be set to True if you are invoking Lambda functions instrumented with datadog-lambda-python < v41 or datadog-lambda-js < v3.57.0. However, if set to True, invocations to Go or Java Lambda functions may fail. |
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'd like to see it explicitly mentioned that the propagation will break for users using datadog-lambda-python < v41 or datadog-lambda-js < v3.57.0
first and then mention the introduction of the legacy setting that can be used to support these older versions.
…ion_trace_propagation_format
…pagation_format' of github.com:DataDog/dd-trace-py into chris.agocs/update_botocore_direct_invocation_trace_propagation_format
…ion_trace_propagation_format
…ion_trace_propagation_format
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.
👏 thanks for bearing with my nitty documentation feedback @agocs!
* Update trace propagation format for botocore direct invocations * Update client context format in one other place * Add config for add_datadog_object * Refactor modify_client_context and inject_trace_to_client_context * black * default false * Add a test for the config flag * Document the config variable * Add release notes * add a bunch of newlines for flake8 * Defaut -> Default * add js and clientContext to wordlist * Update ddtrace/contrib/botocore/patch.py Mutate client_context_object instead of returning Co-authored-by: Kyle Verhoog <kyle@verhoog.ca> * Update ddtrace/contrib/botocore/patch.py Co-authored-by: Kyle Verhoog <kyle@verhoog.ca> * Trimmed down on excess documentation * rename config value to BOTOCORE_INVOKE_WITH_LEGACY_CONTEXT * run black * Remove clientContext form wordlist * Improve documentation * upgrades -> upgrade * re-write release notes * fix spelling of fnuctions Co-authored-by: Kyle Verhoog <kyle@verhoog.ca> Co-authored-by: Brett Langdon <brett.langdon@datadoghq.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Description
Updates the trace propagation format for botocore direct lambda invocations. The old way was:
New way is:
https://docs.google.com/document/d/1pruSeesAr2bAVMtz_rUlsiBZKFoFWdB4nSq5Vuym2l8/edit?usp=sharing
Reasoning
The Go and Java runtimes only support
ClientContext.custom
fields of typemap[string]string
. C.f. :In order to pass trace contexts to directly invoked Go and Java lambda functions, we can write the trace context key:values to ClientContext.custom rather than creating a ClientContext.custom._datadog object like we've been doing.
Backwards compatibility
This is, strictly speaking, a breaking change in how we add trace context to direct invocations. The Python and JS repos have already been updated to accept the new format:
They both check for the old and new formats.
Checklist