Config Consistency Tests for DD_TRACE_<INTEGRATION>_ENABLED

[link04]

Motivation

Our APMAPI-284 Jira card where we need to write a test that validates the outcome of using the setting with both true and false values so that we can test if the auto instrumented library behaves as expected.

Changes

• Included the MongoDB container to the tracing_config_nondefault scenario and added the env var with the value of false and to tracing_config_nondefault_2with the value off true.
• Added a new endpoint for .NET where I run a MongoDB query to check for the version of Mongo.
• Added two tests cases where I check for spans that belong to the expected Integration by checking the operation name for now(most consistent tag based on my research), and then assert on them depending on the test.

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner. We're working on refining the codeowners file quickly.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• If PR title starts with [<language>], double-check that only <language> is impacted by the change
• No system-tests internal is modified. Otherwise, I have the approval from R&P team
• CI is green, or failing jobs are not related to this change (and you are 100% sure about this statement)
• A docker base image is modified?
  • the relevant build-XXX-image label is present
• A scenario is added (or removed)?
  • Get a review from R&P team

[mabdinur]

left some nits but overall looks good to me

[mabdinur]

nit: casing

Suggested change

	weblog_env={"DD_TRACE_HTTP_CLIENT_TAG_QUERY_STRING": "false", "DD_TRACE_Kafka_ENABLED": "true"},
	weblog_env={"DD_TRACE_HTTP_CLIENT_TAG_QUERY_STRING": "false", "DD_TRACE_KAFKA_ENABLED": "true"},

[zacharycmontoya]

This casing may actually be required for the .NET SDK to recognize the flag on Linux so we might need to keep this

[link04]

Indeed so the other languages need to add the env var as their tracer expects it as they enable the test(some languages may even have different integrations names).

[bwoebi]

@zacharycmontoya Well, the casing is required for the PHP extension to recognize the flag on Linux, but in uppercase.
If I read it correctly at least Java and Ruby are using full uppercase too. From a quick glance at docs I couldn't determine what exactly Python and node are doing.
So... we have to change this in any case in at least one place.
I'd propose to universally move to fully uppercase. I find uppercase also more intuitive, in the midst of everything else being uppercase.

[cbeauchesne]

I'd propose to universally move to fully uppercase. I find uppercase also more intuitive, in the midst of everything else being uppercase.

Agree, all our configuration env var are upper case. It looks weird to have one that mix both. By the why, is there a RFC for that ?

[link04]

So it was previously implemented like that, not sure I could find the RFC for that since is so old, but we have agreed that for these efforts of the Config Consistency RFC it should be added that we always expected a all Upper cased env var.

[mabdinur]

We should leave a comment stating that kafka is being used to validate DD_TRACE__ENABLED configurations. There's nothing special about kafka, it just an integration that is consistent across all libraries (🤞).

[bwoebi]

It's not present in PHP though.

[link04]

Yeah the plan was to use a different existing endpoint and env var for PHP since is the only one left out.

[cbeauchesne]

Testing : ok
CI: ok (failures are not related)

There is only the question of lowecase/uppercase. Not my decision here (even if I have a strong opinion 😉 ) So I let @bwoebi the charge to approve the PR.