Skip to content
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

console.log in Node.js Azure Function does not output anywhere #1396

Open
wpitallo opened this issue Nov 14, 2019 · 6 comments
Open

console.log in Node.js Azure Function does not output anywhere #1396

wpitallo opened this issue Nov 14, 2019 · 6 comments

Comments

@wpitallo
Copy link

How do we get console.log in a Node.js Azure function. I have been looking everywhere and cant seem to find out how to do this anywhere. I get that you can use context.log. But what if we need to log from dependencies etc. I really find it hard to believe that that console.log does not show up anywhere in a node.js azure function. Its a real deal breaker...

@sadranyi
Copy link

Aside the context, I believe you can instrument Application insights or some other 3rd party logging tools to to that. I personally use sentry.

@bnb
Copy link

bnb commented Nov 21, 2019

You'll probably want to use context.log() – there's some more context here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#writing-trace-output-to-the-console

@BrianRosamilia
Copy link

This is possible with something like this @wpitallo

https://github.com/BrianRosamilia/azure-function-log-intercept/blob/master/index.js

If you're feeling adventurous you can try out the npm package I made to fix this https://www.npmjs.com/package/azure-function-log-intercept

It was frustrating my team as well.

@orvillelim
Copy link

+100

peterblazejewicz added a commit to peterblazejewicz/DefinitelyTyped that referenced this issue Jul 4, 2021
peterblazejewicz added a commit to peterblazejewicz/DefinitelyTyped that referenced this issue Jul 27, 2021
sandersn pushed a commit to DefinitelyTyped/DefinitelyTyped that referenced this issue Jul 27, 2021
@nicholasdavidbrown
Copy link

nicholasdavidbrown commented Dec 13, 2023

Hi all, thanks @BrianRosamilia for the interceptor. It served me well for the past 12 months :) , however recently I've migrated the functions from V3 to V4.

I rewrote the log intercepter to use the new @azure/functions type like so:

import { InvocationContext } from "@azure/functions";

type LogMethod = 'log' | 'info' | 'warn' | 'error';

function interceptor(context: InvocationContext) {
    const methods = ['log', 'info', 'warn', 'error'];
    return methods.forEach((m: LogMethod) => higherOrderLog(m, context));
}

const higherOrderLog = (name: LogMethod, context: InvocationContext) => {
    const logFn = (...params: any[]) => {
        if (context[name]) {
            context[name](...params);
        }
        else if (context.log[name]) {
            // Must check context.log for some methods (currently warn, info, error)
            context.log[name](...params);
        }
    };

    console[name] = logFn;
};

export = interceptor;

It passes the tests. But when I use it, I get:

Warning: Unexpected call to 'log' on the context object after function execution has completed. Please check for asynchronous calls that are not awaited. Function name: {name}. Invocation Id: {id}.

I guess my question is, was there any fundamental changing to the logging between V3 and V4?

I'm not a huge fan of feeding the context through all of my functions if I can avoid it.

Thanks

@BrianRosamilia
Copy link

@nicholasdavidbrown Pretty slick code. Everyone using my library gets spammed by that and I don't think it actually changed between v3 and v4 as I've seen that message for years now.

Someone made a DefinitelyTyped definition for consuming my package, btw. Not sure if that would help your use case enough since you have added some nice typing to the core of my code.

I thought about overriding console.warn to just not output those messages. It's completely possible, but I didn't feel like playing whack-a-mole with the Microsoft warnings, but this might be a great use case for you since you are already hacking on what I started :D let me know if you have additional thoughts (but maybe move them to my repo so we don't notify everyone in this thread). It actually might make a great optional setting, a PR would be great but maybe I can work on it if you think its valuable enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants