Change typespec_client_core::http::policies::logging Request and Response log level to debug#3643
Change typespec_client_core::http::policies::logging Request and Response log level to debug#3643jlaundry wants to merge 1 commit intoAzure:mainfrom
Conversation
Signed-off-by: Jed Laundry <jlaundry@jlaundry.com>
|
Thank you for your contribution @jlaundry! We will review the pull request and get back to you soon. |
When I originally added the logging policy, I wanted the traces to be a higher visibility than the random noise of debugging so developers could see the HTTP operations without the debug spew from the service client. But I do see your point. One possible refinement (and possible feature creep) would be to make the debug level be configurable in the logging client options and then have identity use the debug logging level and other SDKs use Info. But that's probably overkill. |
It's valid. But other high-volume activity (i.e., regular polling of a Queue, pushing data to an Event Hub, sending traces to Log Analytics, etc.) may also need to be excluded, so we would probably end up the other way round, with Info as the option. In most production deployment cases, unless there was a specific issue we were trying to diagnose, I would typically expect applications to run at Info level, and not see upstream API activity unless they ran with (I'm trying to think of counter examples, low-volume operations where you may want verbose logging to know exact timestamps of when something was done: KeyVault signing/decryption operations, database schema changes, maybe DNS changes... but in all those cases, I'd expect the application to be logging those events as well.) |
When using
azure_identity, applications see Request and Response INFO log events as access tokens are refreshed, sometimes hourly(ish):Since
azure_identitydoesn't do much logging, these appear out of the blue; and apart from failures, these aren't very useful.This PR downgrades these logs to
debug, consistent with the Python SDK.I did consider a more complete PR, and the Failed response case: and either holding off logging the Request (not ideal), or re-log the Request as info... but for every use-case I can think of, the only useful info is the Timestamp and X-MS-Request-ID headers for raising a support case, both which are both in the Response anyway.