[Feature Request] Improve logging
See original GitHub issueLogging at LogLevel.Info
is too verbose and the logs are unstructured. A simple request to get a token using a client secret logs 18 events. In a service that requests many tokens, writing 18 events per token request adds a lot of noise to the service logs.
Logs are sent to the LogCallback
delegate as an unstructured string. In a service that has structured logs, passing the date, time, OS version and library version as a single string on each request adds a lot of duplication and makes the logs hard to integrate with other service logging.
Describe the solution you’d like
- Change
LogLevel.Info
to log just a summary of a token request, for example one event when the request is started containing the request details and a second event when the request succeeds / fails containing the response details and the caching behavior - Move the logs for each step of the token acquisition process to
LogLevel.Verbose
- Pass the log details to
LogCallback
as a structure rather than a string, separating out the various parts into fields - Give event names or event IDs to the various events to allow services to filter events
Describe alternatives you’ve considered
- Parsing the log string with a regular expression to extract the useful data
- Only writing logs at
LogLevel.Warning
andLogLevel.Error
to service logs and logging requests by injecting a handler into the HTTP pipeline
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Feature Request: Improve MultiFile Logging · Issue #149
Firstly please let me thank you for an awesome tool! I'm trying to set up a An Azure DevOps pipeline that will sign...
Read more >How Feature Flags Can Improve Your Logging - Split Software
In this post, we will discuss how feature flags can help you improve your logging strategy. As a result, you can update variables...
Read more >How We Manage Feature Requests at Float
We log every feature request! How do I know if my request is being worked on? We track which users have requested specific...
Read more >How to Collect and Manage Feature Requests in SaaS
In this article, we'll cover several methods for collecting and managing feature requests to meet customer expectations for your SaaS.
Read more >7 Useful Tips to Manage Feature Requests
Managing feature requests can be one of the most challenging aspects of the product manager's role. In this post, we'll show you how...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry I wasn’t clear - I would prefer not to write code that listens on an AzureEventSource and a logging callback from MSAL.
Does my code need to change if I flip that setting you mention?
The location of AAD/MSAL/Azure in the greater Microsoft organization is not relevant to most consumers of the SDK. I just want to add value to my customers by consuming the services. Increasing the amount of code that I need to write and maintain is not a goal of any SDK.
If you are making changes to the logging capabilities of this library, I strongly urge you to consider adopting an approach that simplifies the task of the consumers
We’ve added a new logging mechanism -
WithLogging(IIdentityLogger)
. This allows you to dynamically set the event level. It also exposes correlation ID separately.Please set the level at Warning and change it to Verbose if you run into issues.