Skip to content
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

Conversation

agocs
Copy link
Contributor

@agocs agocs commented Jul 12, 2021

Description

Updates the trace propagation format for botocore direct lambda invocations. The old way was:

clientContext: {
  custom:{
    _datadog: {
      x-datadog-trace-id: "",
      x-datadog-parent-id: "",
      ...
    }
  }
}

New way is:

clientContext: {
  custom: {
      x-datadog-trace-id: "",
      x-datadog-parent-id: "",
      ...
  }
}

https://docs.google.com/document/d/1pruSeesAr2bAVMtz_rUlsiBZKFoFWdB4nSq5Vuym2l8/edit?usp=sharing

Reasoning

The Go and Java runtimes only support ClientContext.custom fields of type map[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

  • Added to the correct milestone.
  • Tests provided or description of manual testing performed is included in the code or PR.
  • Library documentation is updated.
  • Corp site documentation is updated (link to the PR).

@agocs agocs requested a review from a team as a code owner July 12, 2021 18:33
@agocs agocs marked this pull request as draft July 12, 2021 18:33
Copy link
Member

@Kyle-Verhoog Kyle-Verhoog left a 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?

@agocs
Copy link
Contributor Author

agocs commented Jul 12, 2021

@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

@Kyle-Verhoog
Copy link
Member

Which way do you think the default should go? I was thinking it should favor the new, working trace propagation format.

Yup - agreed 👍

The configuration option can be added here:

# Botocore default settings
config._add(
"botocore",
{
"distributed_tracing": get_env("botocore", "distributed_tracing", default=True),
},
)
. We should offer an environment variable too

and then documented here

Configuration
~~~~~~~~~~~~~
.. py:data:: ddtrace.config.botocore['distributed_tracing']

(this will show up here: https://ddtrace.readthedocs.io/en/stable/integrations.html#botocore)

Also an upgrade release note entry would be required here which can be created with reno:

$ reno new botocore

@agocs
Copy link
Contributor Author

agocs commented Jul 12, 2021

Awesome! I appreciate it!

@agocs agocs marked this pull request as ready for review July 14, 2021 12:04
@agocs
Copy link
Contributor Author

agocs commented Jul 14, 2021

@Kyle-Verhoog Changes made! Thanks. Should I drop a link to this in the apm-python channel?

Copy link
Member

@Kyle-Verhoog Kyle-Verhoog left a 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 🙂

@@ -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
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
"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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

invoke_with_legacy_context ?

@@ -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
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

ddtrace/contrib/botocore/__init__.py Outdated Show resolved Hide resolved
ddtrace/contrib/botocore/patch.py Outdated Show resolved Hide resolved
ddtrace/contrib/botocore/patch.py Outdated Show resolved Hide resolved
agocs and others added 6 commits July 15, 2021 11:12
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
@agocs agocs requested a review from Kyle-Verhoog July 16, 2021 15:17
Copy link
Member

@Kyle-Verhoog Kyle-Verhoog left a 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:
Copy link
Member

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']
Copy link
Member

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?

Copy link
Member

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.
Copy link
Member

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

Copy link
Member

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.

@Kyle-Verhoog Kyle-Verhoog added this to the 0.51.0 milestone Jul 19, 2021
agocs and others added 4 commits July 21, 2021 11:13
…pagation_format' of github.com:DataDog/dd-trace-py into chris.agocs/update_botocore_direct_invocation_trace_propagation_format
Copy link
Member

@Kyle-Verhoog Kyle-Verhoog left a 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.
Copy link
Member

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.

agocs and others added 4 commits July 21, 2021 13:21
…pagation_format' of github.com:DataDog/dd-trace-py into chris.agocs/update_botocore_direct_invocation_trace_propagation_format
Copy link
Member

@Kyle-Verhoog Kyle-Verhoog left a 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!

@mergify mergify bot merged commit f9bab03 into master Jul 22, 2021
@mergify mergify bot deleted the chris.agocs/update_botocore_direct_invocation_trace_propagation_format branch July 22, 2021 12:15
brettlangdon added a commit that referenced this pull request Jul 27, 2021
* 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>
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.

None yet

3 participants