ADOT version outdated

[bonclay7]

Deploying a copilot service and using AWS X-Ray with the config below:

observability:
  tracing: awsxray

launches an ADOT collector v0.17.0 when the latest ADOT release (including X-Ray W3C support) is v0.35.0

Can we have this updated please?

[mhausenblas]

ADOT PM here. Thanks @bonclay7 and I'd recommend to do this after we've released Logs GA support, in a few weeks time.

[Lou1415926]

Hi @bonclay7 and @mhausenblas 👋🏼 We decided to hardcode the version because ADOT image's major version was and is still version 0, which means that there is no guarantee in backward compatibility. We want to avoid breaking customer's application unintentionally, so we opted not to always stay on the latest ADOT version.

And I saw #5486 - thank you very much for the contribution, we love contributions ❤️ Out of the same concern that I just described, I have a slightly different proposal: we should let users decide on their own which version to use and whether to bump the version.

There are two ways to accomplish this proposal: yaml patch, and manifest.

YAML Patch

People could use this yaml patch to bump their ADOT version:

- op: replace
  path: /Resources/TaskDefinition/ContainerDefinitions/2/Image # The number 2 may vary - depends on the number of container definitions that come before "aws-otel-collector".
  value: public.ecr.aws/aws-observability/aws-otel-collector:v0.35.0

Manifest

We could opt to introduce a manifest field to specify the version. For example (this is not a design, just an example):

observability:
  tracing:
    awsxray:
      adot_version: 0.35.0

I hesitate to introduce this field right now, because I believe that the decision of "what goes into the manifest" is driven by - among other things - a) how frequent a user wants to configure the field b) how much impact it has on the architecture, or in anther word, the use cases.

I would like to wait for more users to jump in and share that they need to change the version (answers criteria a), or be confident that the versions change have large differences that it affects the general usability on common use cases.

Therefore, my suggestion is that we encourage users to use the YAML patch once they need to upgrade the ADOT version.

[bonclay7]

Thanks for this! I missed the notification I'll close #5486 for now. Option two sounds really awesome! For example 1, is this something doable now? and where/how?

[KollaAdithya]

Hi @bonclay7

For option1, Copilot released yaml patches and CDK overrides in v1.27.0

1. You can run copilot svc override --tool yamlpatch and use the below patch as mentioned by @Lou1415926

- op: replace
  path: /Resources/TaskDefinition/Properties/ContainerDefinitions/2/Image # The number 2 may vary - depends on the number of container definitions that come before "aws-otel-collector".
  value: public.ecr.aws/aws-observability/aws-otel-collector:v0.35.0

2. Run copilot svc deploy to apply the patch.

Docs to refer to :

Yaml Patches - https://aws.github.io/copilot-cli/docs/developing/overrides/yamlpatch/ CDK Overrides - https://aws.github.io/copilot-cli/docs/developing/overrides/cdk/

[bonclay7]

Thanks @KollaAdithya I think Properties was missing in the example above, the correct patch should be

- op: replace
  path: /Resources/TaskDefinition/Properties/ContainerDefinitions/2/Image # The number 2 may vary - depends on the number of container definitions that come before "aws-otel-collector".
  value: public.ecr.aws/aws-observability/aws-otel-collector:v0.35.0

[mhausenblas]

From ADOT side we're good to go ahead, we're launched.