Logging requestID / correlationID
Hey! I'm interested in your opinion on the best way to correlate all the logs for each request.
I am concerned that once an app is deployed in prod, the multiple logs from the server would get mixed up and be difficult to troubleshoot.
Is this something you have already dealt with in a WASP app?
Thanks!!!
7 Replies
Hi @Ramon. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Thank you for your question about logging and request correlation in Wasp applications. While this is an important topic for production applications, I don't have specific information about built-in request ID or correlation ID logging features in Wasp based on the provided knowledge sources.
Wasp is built on top of Express.js for the backend, so you could potentially implement request ID logging using Express middleware. However, the knowledge sources don't contain specific guidance on this for Wasp apps.
If you need detailed information on implementing this in a Wasp app, I'd recommend:
1. Checking the Wasp documentation for any built-in logging features.
2. Asking in the Wasp Discord community for advice from other Wasp developers who may have implemented this.
3. Exploring Express.js middleware solutions for request ID logging, which might be adaptable to a Wasp app.
I apologize that I don't have more specific information from the provided sources to answer your question about correlating logs in a Wasp app. This seems to be an area where custom implementation might be necessary, but it would be best to confirm with the Wasp community or documentation for the most up-to-date guidance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Ramon, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Hey @Ramon, thanks for the question. It's a good one too! I'm glad our users are thinking about logging stuff.
I'd probably either:
- Rederict stdout and stderr to a file, and prefix all my logs with a common string (you could use a library for this, e.g., pino), and later use grep to filter lines containing that string
- Log different events in different files instead of stdout. This way, your logs don't mix with Wasp's default logs. You can go even further, for example: have one log file for requests, another log file for jobs, or whatever makes sense for you
When dealing with logs in general (not only Wasp), I recommend filtering stuff out using
grep. And if you use a common prefix, you'll have no problems finding logs on a certain topic, regardless of everything else that's in the file.
I use this whenever I look at any kinds of logs (nginx, linux, docker, wasp, ....). I can elaborate what I mean if necessary.
Always happy to discuss logging and working with text đŸ™‚Hi @Filip, thanks for your answer!
I tried configuring pino as follows:
This adds the request ID to the HTTPS request logs but not to my own logs that I have added to the actions and queries. Do you know how to get the request ID to the WASP operations? @kapa.ai
import pino from 'pino';
const logger = pino({
level: process.env.NODE_ENV === 'production' ? 'info' : 'debug',
formatters: {
level(label) {
return { level: label };
}
}
});
export default logger;
And then the global middleware:
export const serverGlobalMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
middlewareConfig.set('logger', pinoMiddleware )
return middlewareConfig
}
const pinoMiddleware = pinoHttp({
logger,
genReqId: (req) => uuidv4(), // Pino-HTTP generarĂ¡ el request ID automĂ¡ticamente
customLogLevel: (req, res, err) => {
if (res.statusCode >= 500) return 'error';
if (res.statusCode >= 400) return 'warn';
return 'info';
},
serializers: {
req(req) {
return {
method: req.method,
url: req.url,
requestId: req.id,
};
},
res(res) {
return {
statusCode: res.statusCode,
};
}
}
});
This adds the request ID to the HTTPS request logs but not to my own logs that I have added to the actions and queries. Do you know how to get the request ID to the WASP operations? @kapa.ai
Let me check the knowledge base for you again. One moment! :books:
Sorry @Ramon, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
@Ramon do logs you seee when you run
wasp start a not really the same logs you willl see in production, it will be somewhat different!
The best way is to look into logging libraries for node/express, like morgan/winston and play with those.Thanks@martinsos! I think my current challenge is more related to the WASP implementation than the logging library.
Is there a way to access the Express.js/Node.js "req" object from a WASP operation? Or add a custom request ID in the context? I don't see how to send the request ID from the middleware to the WASP operations.
@Ramon my bad, I missed part of the convo above, I get now what you are trying to do!
Hm that is a completely valid request, being able to access
req from Operations(Query, Action), but if I am correct we don't have that yet. I just created an issue for it here: https://github.com/wasp-lang/wasp/issues/2556 . That actually shouldn't be too hard to add, we just need to forward req via context -> and make sure context has correct Typescript type. There is a small chance there is already a way to reach req from Operation and it is not well documented, so let's see what @Filip says, but I think this is correct.
In the meantime, since anyway what you wanted to do is "Get UUID from req" -> "pass UUID down" -> "pass UUID down" -> "pass UUID down" -> ..., what you can do is "Create UUID" -> "pass UUID down" -> ... . What I mean by this is that in the Operation, you can generate UUID direclty there, and then pass it down, instead of generating it in the middleware and then passing it via req. Would that good enough for your use case? I know you the loose the part where you also connect the actual HTTP request with it, but that anyway proably doesn't offer much info since it is kind of abstracted behind the Operation?
@Filip what do you think?GitHub
In Operations, allow accessing Express's
req object · Issue #2556...It would make sense that users can access it! We had one user who set up a global middleware that enriches req with unique UUID that they then use in the rest of the code when logging, to connect d...