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.

Sign up for GitHub

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

Jump to bottom

[service-bus] Make logging consistent throughout Service Bus #10638

Closed
richardpark-msft opened this issue Aug 14, 2020 · 6 comments · Fixed by #11726
Closed

[service-bus] Make logging consistent throughout Service Bus #10638

richardpark-msft opened this issue Aug 14, 2020 · 6 comments · Fixed by #11726
Assignees
@richardpark-msft
Labels
blocking-release Blocks release Client This issue points to a problem in the data-plane of the library. Service Bus
Milestone
[2020] November

Comments

@richardpark-msft
Copy link
Member

richardpark-msft commented Aug 14, 2020 •
edited
Loading

As part of #10578 we've started down the path of making the log prefix contain more information.

This makes it a bit easier to scan but also to parse since the link, connection and address fields are in the same spot for each log line.

This issue is to track the work to apply this same style across the entirety of service bus.

The format as it stands today:

[connection-id|<linktype>:linkname]

is:

  • sender: sender
  • batching: batching receiver
  • streaming: streaming receiver
  • mgmt: management link
  • session: message session

We'll also want to take this opportunity to transfer over to using Azure loggers rather than directly using debug. This is described in this issue as well (for EventHubs): #9209, which is a similar issue for EventHubs and
@ghost ghost added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Aug 14, 2020
@richardpark-msft richardpark-msft added blocking-release Blocks release Client This issue points to a problem in the data-plane of the library. Service Bus labels Aug 14, 2020
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Aug 14, 2020
@richardpark-msft richardpark-msft added this to the [2020] September milestone Aug 14, 2020
@richardpark-msft richardpark-msft mentioned this issue Aug 14, 2020
Merged
@ramya-rao-a
Copy link
Contributor

I am not completely sold on using s, br, ms etc in the logs as a replacement for sender, batchingReceiver, messageSession etc. When skimming through logs, it has been helpful in the past to search for say "sender" and then use the editor highlights on the results to quickly find places where we had logs related to the sender. Doing the same with just |s: may not have the same benefits

@richardpark-msft
Copy link
Member Author

@ramya-rao-a - I've updated them. Removing 'a' gave us some more room. What do you think of the newer names?

@ramya-rao-a
Copy link
Contributor

looking good

@ramya-rao-a
Copy link
Contributor

See #2845 for reference on log levels

@richardpark-msft richardpark-msft mentioned this issue Sep 4, 2020
Merged
richardpark-msft added a commit that referenced this issue Sep 9, 2020
@richardpark-msft
[service-bus] Logging updates (#11058)
dac8fcd 
Convert logging to use the @azure/logger rather than the debug package. This sets us up for properly logging - format changes (and error logging) will come in a future PR.

Partial fix for #10638
@ramya-rao-a
Copy link
Contributor

With #11058 we are now using @azure/logger and the expected log levels like error, warning, info and verbose
Moving this issue to the October milestone to follow up with making the logged statements themselves consistent regarding the prefix they use as well as to review the verbose logging we have

@richardpark-msft
Copy link
Member Author

Sounds good :)

@richardpark-msft richardpark-msft mentioned this issue Oct 8, 2020
Merged
richardpark-msft added a commit that referenced this issue Oct 9, 2020
@richardpark-msft
[service-bus] Updating logging to use our latest logging convention (#…
34ee768 
…11726)

Convert most logging over to print a consistent prefix and use the same methods for reporting errors.

For the most part I left things unchanged so the diff wasn't too outrageous.

However, there are some changes from before:
- Took a rough stab at having a few more client loggers rather than just shoving everything under `logger`.
- I created a ServiceBusLogger interface so we can augment the client loggers with an additional method `logError`. This
  makes it simpler to make sure you log the format consistently and to your correct logger. (the standalone `logError` always
  assumed you were going to logger)
- `ServiceBusLogger.logError` always logs the message along with the 'objectified' form of the error by appending ` : <error>`
   to each call.

Fixes #10638
@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@richardpark-msft richardpark-msft

Labels
blocking-release Blocks release Client This issue points to a problem in the data-plane of the library. Service Bus
Projects
None yet
Milestone
[2020] November
2 participants
@ramya-rao-a @richardpark-msft