Disable/control roarr logs

[mmkal]

Is it possible to disable the roarr logs? My team are looking into using roarr but there are a lot of logs produced by slonik that we don't want to have to filter out in order to get readable outputs in CloudWatch.

Currently the only workaround I've been able to find is to create a custom global.ROARR_WRITE function which parses the JSON and skips logging if context.package === 'slonik', which seems inefficient and hacky.

Note: both this use case, and the use case of using other loggers than roarr would be solved by passing in a custom logger. I would be happy to update https://github.com/gajus/slonik/pull/158 in order to achieve this.

Edit: not a bug.

[gajus]

You can also create .roarr.js file in your repository and define a filter there.

You should definitely not being doing filtering in the process, though.

Just node your-script.js | roarr. If you are doing just filtering, the process has minimal overhead.

Happy to discuss improvements, whether to Slonik or Roarr, that do not involve replacing the logger.

[gajus]

Nothing actionable here.

[gajus]

Just in case, here is an example of .roarr.js:

https://github.com/gajus/roarr-cli#roarr-configuration-file

[mmkal]

Thanks for the reference! We ended up using pino in the end. I might (re)start a discussion about a way to bring-your-own logger that's palatable at some point! Seems weird that an existing application would have to change loggers when adding slonik.

[hjr3]

I would like a "bring your own logger" solution as well. We do things like adding a correlation/trace id to our log context so I can view all logs from a particular "trace". The current logging facility does not allow me to do that.

I (think?) I would be fine if we had to confirm to the roarr interface but could pass in our own instance of a roarr logger or some other logger that conforms to the interface.

[gajus]

We do things like adding a correlation/trace id to our log context so I can view all logs from a particular "trace". The current logging facility does not allow me to do that.

What is missing to allow you to do that?

[hjr3]

I cannot inject the logger. It is created here

[gajus]

correlation/trace id to our log context

How would injecting a logger help here?

[yosbelms]

A more efficient solution could be to allow filter logs before stringified. For that purpose the filter should be part of Roarr logger instead of Roarr cli.

I find elegant to use an env variable with Liqe filter, eg: ROARR_FILTER='NOT context.package:slonik'. The disadvantage of this approach is the Liqe dependency, but it can be used as peer dependency.

Or just globalThis.ROARR_FILTER = (msg) => ...

Or both

What do you think about this @gajus?

[gajus]

I find elegant to use an env variable with Liqe filter, eg: ROARR_FILTER='NOT context.package:slonik'. The disadvantage of this approach is the Liqe dependency, but it can be used as peer dependency.

The disadvantage of this is that you are using potentially CPU-intensive filtering logic on the same process where your primary application is running.

[yosbelms]

@gajus I agree, I will vote for the second approach globalThis.ROARR.filter = (msg) => ...

[gajus]

You can already do this with globalThis.ROARR.write

[yosbelms]

Sure, but I have to parse the JSON which is CPU-intensive only to filter. Another solution could to pass down to ROARR.write the message without serialize as the second param write = (msg, obj) => ... In this was we can use obj to filter out logs without parsing.