-
Notifications
You must be signed in to change notification settings - Fork 149
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
add support for ignore: *
#82
Comments
Can you make a few example of this?
Il giorno lun 21 ott 2019 alle 19:27 Stephan Meijer <
notifications@github.com> ha scritto:
… Quite often I just want to print the message, not the data objects.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#82?email_source=notifications&email_token=AAAMXYYRC6ZCVWD6AV7BE4DQPXYA5A5CNFSM4JDC5MEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HTI2XDQ>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMXY7HUCYGU6WN75F67YDQPXYA5ANCNFSM4JDC5MEA>
.
|
httpLogger.info(
{
method: req.method,
path: req.url,
referer: ref,
user: req.user,
},
'http request %s: %s',
req.method,
req.url,
); This would output something like:
Which is a bit much and hard to scan. We don't always need that detailed info in the console while developing. If I need the details, I'll make sure to hit a breakpoint. Simply logging the formatted message, would be more informative. I see the console more as a global overview of data streams. And use the debugger to dive into details. So reducing that output to something like this (in
Also, if info messages can be logged as a single line, errors would have less chance to be missed. I now get so much data at certain moments, that it's easy to miss the errors. |
Pretty printing in production is recommended against, however you can use
pino-colada for reduced output
…On Mon, 21 Oct 2019 at 20:46, Stephan Meijer ***@***.***> wrote:
httpLogger.info(
{
method: req.method,
path: req.url,
referer: ref,
user: req.user,
},
'http request %s: %s',
req.method,
req.url,
);
This would output something like:
INFO [18:29:08.552]: http request GET: /index.htm
method: "GET"
path: "/index.htm"
referer: "http://localhost:3000/blog/ssfTKLgj58vc5fbYj/comment/ljrVbFMILabWQKV6o"
user: {
"id": "jWmre2l5sTAh3KfpQ",
"username": "smeijer",
"email": ***@***.***",
"ip_address": "127.0.0.1"
}
INFO [18:29:08.552]: http request GET: /favicon.ico
method: "GET"
path: "/favicon.ico"
referer: "http://localhost:3000/blog/ssfTKLgj58vc5fbYj/comment/ljrVbFMILabWQKV6o"
user: {
"id": "jWmre2l5sTAh3KfpQ",
"username": "smeijer",
"email": ***@***.***",
"ip_address": "127.0.0.1"
}
INFO [18:29:08.552]: http request GET: /logo.png
method: "GET"
path: "/logo.png"
referer: "http://localhost:3000/blog/ssfTKLgj58vc5fbYj/comment/ljrVbFMILabWQKV6o"
user: {
"id": "jWmre2l5sTAh3KfpQ",
"username": "smeijer",
"email": ***@***.***",
"ip_address": "127.0.0.1"
}
Which is a bit much and hard to scan. We don't always need that detailed
info in the console while developing. If I need the details, I'll make sure
to hit a breakpoint. Simply logging the formatted message, would be more
informative. I see the console more as a global overview of data streams.
And use the debugger to dive into details.
So reducing that output to something like this (in NODE_ENV !== production),
would be very helpful:
INFO [18:29:08.552]: http request GET: /index.htm
INFO [18:29:08.552]: http request GET: /favicon.ico
INFO [18:29:08.552]: http request GET: /logo.png
Also, if info messages can be logged as a single line, errors would have
less chance to be missed. I now get so much data at certain moments, that
it's easy to miss the errors.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#82?email_source=notifications&email_token=AAJCWPFQ3A5GIOHMVH65NM3QPX2GZA5CNFSM4JDC5MEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3L5IA#issuecomment-544652960>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJCWPCNI2YKC5XBZP6C7V3QPX2GZANCNFSM4JDC5MEA>
.
|
I understand, and I agree. But piping to |
Some additional context, an abstracted version of my logger configuration: import pino from 'pino';
import noir from 'pino-noir';
import pico from 'picoid';
const base = {
sid: pico(),
hostname: process.env.HOST_NAME,
appname: process.env.APP_NAME,
instance: ~~process.env.INSTANCE_ID,
release: process.env.VERSION,
};
const redact = noir([...], '***');
const prettyPrint = process.env.NODE_ENV === 'development'
? {
colorize: true,
levelFirst: true,
translateTime: 'HH:MM:ss.l',
ignore: 'sid,appname,instance,release,ns,headers',
}
: false;
const logger = pino({
level: process.env.LOG_LEVEL || 'info',
serializers: redact,
base,
prettyPrint,
}); |
Redaction is embedded in pino now, check out http://getpino.io/#/docs/redaction. I’d be happy to support more customization to pino-pretty tbh, would you like to send a PR? |
I'm +1 on this. Would be a great way to get an overview of the logs in a single terminal window, right now it can become quite few log lines if the log lines has quite many attributes |
Would you like to send.a PR? |
Quite often I just want to print the message, not the data objects.
The text was updated successfully, but these errors were encountered: