-
Notifications
You must be signed in to change notification settings - Fork 845
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
Logging request id #601
Comments
Let me generalize this proposal a little bit. |
Fastify already creates a child logger for every request. If you want to fetch such logger, you can easily store it in cls-hooked, and get the logger from there. |
@mcollina any thoughts on having dynamic |
Or maybe an additional handle that makes // pino config
{
base: object | () => object
baseFn: boolean
} if We could go even further and drop |
Because of the way pino is designed internally, doing such a change would be drastic and we will lose most of our throughput. We are not keen on losing it. Our suggested and preferred way is to create a child logger to wrap this info. Storing this in the cls is fine because you will have to use cls anyway to store the traceId. |
Yeah, it's possible, but it adds slightly more boilerplate. // Pre-configured instance of pino
import { logger } from 'utils/logger'
class Controller {
method1 () {
logger.info()
}
method2 () {
logger.info()
}
...
} If we store the logger itself in cls it means we have to get it every controller before we can use it import { getLogger } from 'utils/cls'
class Controller {
method1 () {
const logger = getLogger()
logger.info()
}
method2 () {
const logger = getLogger()
logger.info()
}
} |
You can easily achieve it using a I would recommend you to wrap pino and the cls-hooked based solution in a module, it seems pretty useful, and a feature that a lot of people would enjoy. |
Thank you for all the comments, I'm going to read about cls-hooked and proxy and try to do it. :) |
@Karina246 you can try cls-proxify now. It even has a demo for your very case. I'm going to enhance the documentation later, but it already covers basic usage. |
I'm happy to help! I think we can close this issue, feel free to reopen if you think it's not resolved. |
@mcollina I added live demos of how to use cls-proxify with pino and fastify, pino and express. Would you consider adding cls-proxify to Pino Ecosystem list? |
Of course! Send a PR |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hello,
I’m using Pino with Fastify and I like to have a request id property in all logs that occur during the request lifecycle.
I’ve set the genReqId option like:
And when I’m using req.log.info everything seems to work!
But I don’t want to pass the req.log as an argument to all the functions in the system that needs to log. I want to write my logs in the form of logger.info, So I’m looking for a different solution.
One thing I had in mind is when creating a new instance of the logger to do something like this:
And when I log a message, the request_id function will be evaluated at log time.
Currently the behaviour is that the base properties are evaluated once at the construction time.
Any ideas?
The text was updated successfully, but these errors were encountered: