Config logger system for parse server?

Hello,

It looks like parse server used the winston logger as default logger system, but if parse server as a lib, how could I config it, for example, in parse-server-example? I would like to set the rotate time, rotate file size, etc.

Thanks a lot.

1 Like

On your Parse Server configuration, you can pass the following parameters to customize how Winston logger adapter works: jsonLogs, logsFolder, verbose, logLevel, silent, maxLogFiles. You can find more details about these parameters on the following link: ParseServerOptions - Documentation

Unfortunately, those are the unique parameters available for configuration. If you want more flexibility, you can always write your own LoggerAdapter (shouldn’t be hard to be done): parse-server/LoggerAdapter.js at 4c29d4d23b67e4abaf25803fe71cae47ce1b5957 · parse-community/parse-server · GitHub

1 Like

@davimacedo Thank you so much!

BTW, for the current default implementation, is there a log id or something like that, passed through the whole life cycle for a request → functions → reponse ? So if some user got problem, we could use the log id to filter only the related info out of the log files?

You mean something to identify all logs that were generated when handling a specific request, right? As long as I know, Parse Server does not have something like that and it would be a great addition to the project imho.

Yes. Since I am new to parse server, if I would like to implement such feature, where could I start from?

Basically we need generate a UUID when the request coming, and pass this UUID through the whole life cycle till response to the client, and during the life cycle, it could be easily passed to the logger …

Thanks a lot.

Honestly I don’t think it is a small change, but I encourage you to start opening an issue and checking the source code on Parse Server repo: GitHub - parse-community/parse-server: API server module for Node/Express

1 Like

Added the issue here:

I’m moving the discussion from the GitHub issue back into the forum, because I think this still requires some more abstract deliberation.

I wonder whether such a feature should be part of Parse Server, because a request begins from a recipient perspective as soon as it reaches your infrastructure public gateway, and that’s way before Parse Server. The request may even never reach Parse Server, but the client still gets a response. That means that a request ID that is assigned by Parse Server will always leave you with an incomplete trace.

The usual approach is to assign a request ID early in your infrastructure, ideally already at the gateway. If you want to start even earlier, you can add a UUID on the client side and send it as part of the request, so you have it even at the client side and the user can tell you the request ID for you to troubleshoot. You could look into the Idempotency feature of Parse Server, which makes the client SDK send a UUID with a request, maybe you can repurpose that for logging. I don’t think assigning a request UUID beginning at Parse Server has a practical application in a professional production environment.

For example, you can add a AWS ALB trace ID, which adds a request header to a request beginning at the ALB. This trace ID will be available as header in Cloud Code requests and it should be possible to output that to the logger, or even append it to a ParseObject. I think @xeoshow’s question can be simplified as how to log a request http header in the Parse Server logs, which I think is easily solvable and I think actually already done by default.

If the request UUID should be sent from the client with every request, a PR in the SDK could be a solution that allows to add custom header with every request, possibly as a callback option during SDK initialisation.

A more professional approach is to use a trace tool like NewRelic or netdata which gives a 360° view, including the client, the server and any infrastructure component in between, combined with respective resource and performance data.

1 Like

I think we can add a new unique request id to the request object of Parse cloud function if it doesnt already exist (i.e. dont do anything if the request id was added through express middleware)
without this feature logging cloud function code is difficult