Consider redirecting console.log to context.log

[danderson00]

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.

[mathewc]

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.

[danderson00]

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.

[mathewc]

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.

[danderson00]

Sure, but doesn't console.log do nothing in the context of functions?

[christopheranderson]

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.

[mathewc]

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.

[mamaso]

@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.

[mathewc]

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.

[martinpeck]

So, is there a recommendation here for people using packages that write to console.log?

[mamaso]

@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 beta version of functions.

[pgraham]

Is there any update on this?

[nevercast]

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?

[wpitallo]

Azure has really dropped the ball on logging...

[igilham]

My team has had a lot of problems getting console.log to work correctly on Linux Consumption Plan apps in either the V1 or V3 runtime. Either the documentation or the service implementing this is incorrect (see discussion with the docs team.

We also have a support case open because we're getting logs appearing against the wrong functions in the Azure Portal, making debugging challenging.