-
Notifications
You must be signed in to change notification settings - Fork 441
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
Consider redirecting console.log to context.log #162
Comments
Yes, I'm aware of this - I did the original Zumo console.log after all :) The thing is, context.log logs to per function log file (for streaming logs). I was hesitant to replace console becuase then any other libraries that people pull in that might be doing console.log would also get dumped to that log stream. |
Yeh, it can be bad overriding the default behavior. Some users might be using a logging library that has already overridden the default console.log behavior. One could argue that we should actually log this sort of output to our log stream. Perhaps overriding console.log to redirect to context.log as well as calling into the console object. |
Thus far I've tried to avoid playing any of the fancy redirection games that have bitten us in the past. I don't think context.log is so bad, since in the users mind they're logging for their particular function, whereas console.log is usually interpreted as global logs, which these aren't. |
Sure, but doesn't console.log do nothing in the context of functions? |
One thing to consider here is that we could bind the console.log per-function and the context.log per execution. We could then have the log stream spit out both flavors of logs - one would be correlated to an execution, while one is within the function space with just a timestamp. That experience would make more sense to users, I think. |
console.log is a global - you can't really bind to it "per-function". If you swap something into the global, it affects ALL functions. |
@mathewc do we capture console.log output in any way? It doesn't seem to be the case, even with diagnostics logs enabled and set to verbose. I understand the per-function log issues, but it seems that having a global dump for console.log somewhere would be helpful for user debugging. |
No not captured currently. For Node.js apps running under IIS Node (the standard configuration when running Node on App Service) the diagnostics settings you mentioned above would cause the logs to go to disk. However, that's not how we run functions. |
So, is there a recommendation here for people using packages that write to console.log? |
@martinpeck you could try to add your own hook to console.log which redirects to context.log or a file. We are working on addressing this in the |
Is there any update on this? |
Just an aside to this, how should I handle logging stuff that may happen outside of an Azure function call? Assuming that, on a Consumption plan, as long as the server hasn't gone cold, a timer could still trigger code to run, what is the right way to handle this logging out of band from a trigger? |
Azure has really dropped the ball on logging... |
My team has had a lot of problems getting We also have a support case open because we're getting logs appearing against the wrong functions in the Azure Portal, making debugging challenging. |
- Once redis/ioredis#1822 is fixed, remove patch to ioredis - Once Azure/azure-functions-host#162 is fixed, remove patch to nitro that wraps console log. - Once unjs/nitro#1753 is merged and released, remove corresponding patch to nitro - Once lucia-auth/lucia#1153 is fixed, rename models/fields in prisma - Once lucia-auth/lucia#1155 is merged and released, remove custom h3 lucia middleware - Once lucia-auth/lucia#1074 is fixed, remove lucia types shims - Enable CSRF protection in lucia (but then login doesn't work anymore...)
So used to using console.log, it can be difficult to pick up when we incorrectly use console instead of context. We could possible provide a stubbed console "pseudo global" that redirects calls to context.log.
The text was updated successfully, but these errors were encountered: