update logs #485
update logs #485
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Approving on condition that this not go to prod as is, since we don't want to be logging request details there. Note you can theoretically enable debug logging inside the nypldataapiclient via log_level option to the constructor, so you could do:
const nyplApiClient = new NyplApiClient({
...
log_level: process.env.NYPL_API_LOG_LEVEL || 'error'
})
And for sierra-client you may be able to use setLogLevel
|
Are you saying that the logs would be too noisy in production? They log to cloudwatch when not running locally or on Vercel. |
|
Ok... final form is using homebaked logs and checking env for log level. The nypl data client logs are suuuper noisy, printing entire response bodies. I cut a ticket to make quieter info level logs with request urls, but for now, this will have to do. |
| const transports = [ | ||
| new winston.transports.Console({ level: "debug" }), | ||
| new winston.transports.Console({ level: process.env.LOG_LEVEL || "error" }), |
There was a problem hiding this comment.
I honestly do not know. Looks like maybe? I have not touched this file before.
logger.js
Outdated
| @@ -42,21 +42,22 @@ const initializeLogger = () => { | |||
| } | |||
| return JSON.stringify(logObject) | |||
| }) | |||
|
|
|||
| console.log(process.env.LOG_LEVEL || "error") | |||
There are mysterious errors blocking hold requests in QA. Updating the logs for more granularity to investigate. Also added client-level logging to nypl client gets and posts, and sierra client gets, posts and puts. I did most of the updated requests, and they work! However, I would appreciate some scrutiny on my instance method manipulation.