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

feat(api): Optionally suppress warning about logger being overwritten #3366

Merged

Conversation

SimenB
Copy link
Contributor

@SimenB SimenB commented Oct 31, 2022

Which problem is this PR solving?

We use pino as logger, meaning we want it instrumented. And once it is instrumented, we'd like to use it as the logger for open telemetry. But up until instrumentation is done, we'd like to have a logger active.

diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.INFO);

// create provider

registerInstrumentations({
  tracerProvider: provider,
  instrumentations: [new PinoInstrumentation()],
});

provider.register();

const pino = require('pino');

const logger = pino();

diag.setLogger(
  {
    error: (msg, ...args) => logger.error(util.format(msg, args)),
    // etc.
  },
  DiagLogLevel.INFO,
);

However, this triggers the override warning. This PR adds an optional flag to suppress this warning when the caller knows it'll override one.

Fixes # N/A

Short description of the changes

This PR adds an optional flag to suppress a warning about overwritten logger when the caller knows it'll override one.

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • Made the change in my node_modules and verified warning is no longer printed

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@SimenB SimenB requested a review from a team as a code owner October 31, 2022 08:58
@vmarchaud
Copy link
Member

Maybe we could have an options object instead of a single param ? That would avoid breaking changes later on

@SimenB
Copy link
Contributor Author

SimenB commented Oct 31, 2022

Sure 👍 log level should probably be merged with that in a future major?

@vmarchaud
Copy link
Member

Sure +1 log level should probably be merged with that in a future major?

I admit i'm not sure if its something that we want actually, we'll see other opinion on this

@vmarchaud vmarchaud requested a review from a team October 31, 2022 09:44
@codecov
Copy link

codecov bot commented Oct 31, 2022

Codecov Report

Merging #3366 (c96858a) into main (c6ff50e) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head c96858a differs from pull request most recent head 455e948. Consider uploading reports for the commit 455e948 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3366      +/-   ##
==========================================
- Coverage   93.25%   93.24%   -0.02%     
==========================================
  Files         247      247              
  Lines        7341     7344       +3     
  Branches     1509     1511       +2     
==========================================
+ Hits         6846     6848       +2     
- Misses        495      496       +1     
Impacted Files Coverage Δ
api/src/diag/types.ts 100.00% <ø> (ø)
api/src/api/diag.ts 100.00% <100.00%> (ø)
...-trace-base/src/platform/node/RandomIdGenerator.ts 87.50% <0.00%> (-6.25%) ⬇️

@SimenB
Copy link
Contributor Author

SimenB commented Oct 31, 2022

Where should I add a changelog entry? https://github.com/open-telemetry/opentelemetry-js/blob/main/api/CHANGELOG.md seems autogenerated

@dyladan
Copy link
Member

dyladan commented Nov 1, 2022

Where should I add a changelog entry? main/api/CHANGELOG.md seems autogenerated

It was, but now we have to manually add entries. Add an ## Unreleased section at the top for these changes.

Comment on lines 74 to 75
logLevel: DiagLogLevel = DiagLogLevel.INFO,
options: LoggerOptions = {}
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Wonder if we want to add a third parameter or make the second parameter an overload?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated the type

Copy link
Contributor Author

Choose a reason for hiding this comment

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

happy to make it an overload if you want? 🙂

Copy link
Member

Choose a reason for hiding this comment

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

We are avoiding overloading API methods that need to be implemented in SDK libraries. However, this method is not part of an interface that needs to be implemented in SDKs.

So I believe it would be intuitive to be overloaded as an option bag.

Copy link
Member

@dyladan dyladan Nov 2, 2022

Choose a reason for hiding this comment

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

the self.logger use is done there intentionally to aid with code minification. what help do you need?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if you revert the last commit, you can see the typescript errors

Copy link
Member

Choose a reason for hiding this comment

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

if you revert the last commit, you can see the typescript errors

The compilation errors can be suppressed if the two method declarations are merged into a single one, e.g.

  /**
   * Set the global DiagLogger and DiagLogLevel.
   * If a global diag logger is already set, this will override it.
   *
   * @param logger - [Optional] The DiagLogger instance to set as the default logger.
   * @param logLevelOrOptions - [Optional] And object which can contain `logLevel: DiagLogLevel` used to filter logs sent to the logger. If not provided it will default to INFO. The object may also contain `suppressOverrideMessage: boolean` which will suppress the warning normally logged when a logger is already registered.
   * @returns true if the logger was successfully registered, else false
   */
  public setLogger!: (logger: DiagLogger, logLevelOrOptions?: DiagLogLevel | LoggerOptions) => boolean;

As for why those methods need to be defined in this non-conventional way, I traced back to #1880 and didn't find an explanation. Maybe @MSNev can chime in and share more about it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, I've blocked this PR as we should NOT convert the property into a function as this becomes less compressible through minification.

And then will cause me to re-implement this original change again in the sandbox to have it contributed back here.

Copy link
Contributor

Choose a reason for hiding this comment

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

This pattern has major implications on the overall browser bundle sizes (depending on the module format and ES level being targetted). And this is one of the techniques that I WILL be investigating the viability and performing across the entire JS and Contrib codebases in the sandbox (when I get it going -- HOPEFULLY shortly)

@SimenB
Copy link
Contributor Author

SimenB commented Nov 2, 2022

changelog entry added

@SimenB SimenB force-pushed the optionally-suppress-diag-override-warning branch from 709e1d1 to 50fed69 Compare November 2, 2022 10:59
@naseemkullah
Copy link
Member

Could we not just lower the log level to debug/trace for that message? Is it easy to accidentally overwrite the logger?

api/src/api/diag.ts Outdated Show resolved Hide resolved
@legendecas
Copy link
Member

@naseemkullah Could we not just lower the log level to debug/trace for that message? Is it easy to accidentally overwrite the logger?

I'd find the example shown in the OP is persuading to suppress the message entirely: the override is intentional so there is no need to log anymore.

Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you for refactoring the type interfaces!

@legendecas
Copy link
Member

hi @dyladan, as @SimenB requested at #3388 (comment), do you think it is possible for us to include this PR in #3340? Or should we go ahead as the release has been proposed for weeks?

@dyladan
Copy link
Member

dyladan commented Nov 8, 2022

Let's include it

@dyladan
Copy link
Member

dyladan commented Nov 8, 2022

I updated some of the typedoc comments.

api/src/diag/types.ts Outdated Show resolved Hide resolved
Copy link
Contributor Author

@SimenB SimenB left a comment

Choose a reason for hiding this comment

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

I think?

api/src/diag/types.ts Outdated Show resolved Hide resolved
api/src/diag/types.ts Outdated Show resolved Hide resolved
@dyladan dyladan merged commit baf0fee into open-telemetry:main Nov 8, 2022
@SimenB SimenB deleted the optionally-suppress-diag-override-warning branch November 8, 2022 20:12
@SimenB
Copy link
Contributor Author

SimenB commented Nov 8, 2022

🎉

@naseemkullah
Copy link
Member

@naseemkullah Could we not just lower the log level to debug/trace for that message? Is it easy to accidentally overwrite the logger?

I'd find the example shown in the OP is persuading to suppress the message entirely: the override is intentional so there is no need to log anymore.

Intentional things can be debug logged though, just wondering if there is any reason it was logged as warn

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

6 participants