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

Logger prints unformatted strings after ComponentLogger addition #2389

Closed
2 tasks
rauno56 opened this issue Aug 3, 2021 · 5 comments · Fixed by #2499
Closed
2 tasks

Logger prints unformatted strings after ComponentLogger addition #2389

rauno56 opened this issue Aug 3, 2021 · 5 comments · Fixed by #2499
Assignees
Labels
bug Something isn't working good first issue Good for newcomers up-for-grabs Good for taking. Extra help will be provided by maintainers

Comments

@rauno56
Copy link
Member

rauno56 commented Aug 3, 2021

Please answer these questions before submitting a bug report.

Versions

  • @opentelemetry/api@1.0.2,
  • @opentelemetry/instrumentation@0.24.0
  • node@14

Please provide the code you used to set up the OpenTelemetry SDK

HTTP example with log level set to DEBUG works.

What did you do?

I'm running an example with HTTP instrumentation enabled. Logs show:

@opentelemetry/instrumentation-http %s instrumentation outgoingRequest http
@opentelemetry/instrumentation-http http.ClientRequest return request
@opentelemetry/instrumentation-http %s instrumentation outgoingRequest http
@opentelemetry/instrumentation-http http.ClientRequest return request
@opentelemetry/instrumentation-http %s instrumentation incomingRequest http

What did you expect to see?

Something like:

@opentelemetry/instrumentation-http outgoingRequest
@opentelemetry/instrumentation-http http.ClientRequest return request
@opentelemetry/instrumentation-http incomingRequest

Additional context

console.log only formats the first argument. Since ComponentLogger forces the first argument to now be the namespace it breaks all code that uses printf-like string formatting.
To bring back the functionality to its previous state, we should util.format the args before passing them to logProxy in DiagComponentLogger. However, that would force this behaviour on all the loggers, which I'd personally be cautious of. Unless any of the maintainers are strongly for it I'd just replace the usages of string formatting with template literals(`my log ${var}`) instead, or use util.format before passing the arguments to the logger.

Steps

  • Remove unnecessary tagging from logs from HTTP instrumentation;
  • Discussion: Should printf-like string formatting be forced to all loggers?
@rauno56 rauno56 added bug Something isn't working good first issue Good for newcomers labels Aug 3, 2021
@vmarchaud vmarchaud added the up-for-grabs Good for taking. Extra help will be provided by maintainers label Aug 7, 2021
@alisabzevari
Copy link
Contributor

I just checked the usage of %s and %d in the project and it seems to be fairly easy to replace all of them with template literals. I would also vote for using template literals since it is more like idiomatic Javascript.
Let me know if you agree, then I will create a PR to fix this.

@rauno56
Copy link
Member Author

rauno56 commented Sep 6, 2021

You mean to replace usages of %s and %d in the instrumentations(namely HTTP instrumentation) with template literals? I agree.

@alisabzevari
Copy link
Contributor

alisabzevari commented Sep 6, 2021

Yes, I searched in all the packages but we can also change it only in instrumentation packages.

@rauno56
Copy link
Member Author

rauno56 commented Sep 6, 2021

Everything that uses ComponentLogger has this problem, so, at least eventually, all of those should be changed.

@PaurushGarg
Copy link
Member

PaurushGarg commented Sep 20, 2021

@dyladan - please assign me this issue. I am working in @alolita team.
Tag: @alolita

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers up-for-grabs Good for taking. Extra help will be provided by maintainers
Projects
None yet
4 participants