Add experimental support for customizing tracer log levels

[ericmustin]

What does this PR do?

Following up on Feedback from PR-718 This PR addresses the use case introduced in Issue 599 for when a user wants to forward tracer errors to their logger but ignore debug messages.

This PR adds experimental support for an experimental.ddTraceLogLevels experimental.logLevel configuration option as well as DD_TRACE_LOG_LEVEL environment variable, which allow a user to specify the specific minimum log levels that they'd like to permit from the tracer's logger. It accepts the format of an array of strings such as ['error','debug','info'] as well as a comma separated value string such as 'error,info' a string such as 'error' or 'debug'.

Motivation

Implementing feedback discussed from PR-718

• Unit tests.
• TypeScript definitions.
• TypeScript tests.
• API documentation.
• CircleCI jobs/workflows.
• Plugin is exported.

Additional Notes

I tried to incorporate the feedback from PR-718 in this pull request. A few notes.

• Some of the implementation is a bit clunky given that I am trying to target a future logger that hasn't been written or spec'd out, so I tried to leave things flexible enough that they can adjusted if there is a larger refactor of the default logger in the future. At a high level my approach was to give the user a few ways to set the tracer log levels they'd want logged, and then ideally not have to worry about changing that format if there's a larger refactor in the future / new log levels are added.

• There's some helper methods for determining if the specific log level is enabled or not (_isLogLevelEnabled ) that I'd be open to feedback on if there's a better way to approach this. I tried to write a method that would automagically determine the log level's function name that was invoking it and check if that name had been whitelisted, however the approach to doing so seemed to rely on either outdated js concepts (using something like arguments.callee ) or methods that might not play nicely when minified (specifically myFunction.name had some scary language around it in this S/O Note ). So the current approach is a bit clunky.

• Unclear how i ought to document this but happy to add docs/usage example to api/docs.md in this PR (i made the option experimental for now and it doesn't look like we really update that api/docs.md file until an option is "non-experimental").

• It's entirely possible i botched the typescript part of this, apologies if so, still need to level up with my TS.

• Any and all feedback is welcome, and generally if it's better to shelve this until there's more clarity on what logging might look like after additional log lvls have been added, thats ok too. Just trying to unblock the folks who'd been asking for it.

[ericmustin]

Looks like node-tedious tests are failing, I assume related to what's described in PR-726 , happy to update this branch once that work has been merged into master

[rochdev]

For the API docs, it should be enough to just add an entry in API.md for the new configuration option.

[ericmustin]

ergh not sure why this started a review for me but, updated PR from feedback, thanks again for taking a look!

[ericmustin]

@rochdev updated with feedback again, i think i've covered everything and appreciate the patience with all the back and forth here, feels like we're close. also my browser tests are failing for reasons i'm not entirely clear about

[rochdev]

A few small things but then it's good to go.

[ericmustin]

updated with feedback, still unclear why browser tests are failing though

[rochdev]

@ericmustin Can you try to rebase? Hopefully this will fix the browser tests since I don't see why they would fail.

[rochdev]

It looks like the build issue is because of BrowserStack credentials in CircleCI from a fork. I'll go ahead and merge it and if my theory is correct I'll contact CircleCI.