roadrunner icon indicating copy to clipboard operation
roadrunner copied to clipboard

[💡 FEATURE REQUEST]: Filter logs

Open devnev opened this issue 1 year ago • 12 comments

Plugin

Logger

I have an idea!

In short, add an option to discard logs matching certain properties/patterns.

Motivation:

I have a global loadbalancer set up, which sends health checks to determine if the backend service is healthy. Previously these were handled by an nginx, with access logs disabled for that particular route. I've now changed the loadbalancer so the healthcheck traverses the full stack, all the way into the PHP worker managed by roadrunner. Now roadrunner is logging these requests, causing a lot of noise between logs of actual traffic. It would be great to be able to stop roadrunner from even emitting these logs.

devnev avatar Nov 26 '24 01:11 devnev

Hey @devnev 👋🏻 Could you please share your RR configuration (.rr.yaml)?

rustatian avatar Nov 26 '24 07:11 rustatian

@rustatian I'm probably going to have to redact some of it, is there any particular bit you're looking for?

devnev avatar Nov 26 '24 08:11 devnev

Yeah, logs section

rustatian avatar Nov 26 '24 08:11 rustatian

Logs section is

logs:
  encoding: json
  level: info
  mode: production

devnev avatar Nov 27 '24 03:11 devnev

I think that you may simply use channels. info is needed only for the worker logs (if you need them), for the other plugins you may error log level.

rustatian avatar Nov 27 '24 07:11 rustatian

I don't think that works for me as I want to have the http logs in general but filter out certain logs (namely successful healthcheck requests)

devnev avatar Nov 27 '24 08:11 devnev

Yeah, in that case it makes sense.

rustatian avatar Nov 27 '24 10:11 rustatian

I'm actually having the same (or actually more of an issue, same cause but harder to mitigate) with metrics. My RR metrics now include the healthcheck traffic, which makes them less useful.

Would it be possible to run two http server in RR on different ports, with separable logs and metrics? Or otherwise have the status plugin direct healthchecks to the servers? The definiton of ready as currently provided by the status plugin is not particularly useful, in fact I even consider it actively harmful.

devnev avatar Dec 02 '24 08:12 devnev

The status plugin reports RR metrics directly to the Prometheus server. In connection with the Grafana you may filter out not needed data and draw only useful for you.

rustatian avatar Dec 02 '24 09:12 rustatian

I'm using the status plugin, but the exported metrics don't (and can't) include the HTTP URI that would be needed to filter them.

devnev avatar Dec 02 '24 13:12 devnev

Not sure I'm following. The status plugin works by the pull model. It does not send any metrics, metrics are pulled from it. Usually by the local exporter or configured prometheus server. These metrics contains only runtime/workers metrics, not logs.

rustatian avatar Dec 02 '24 18:12 rustatian

I'm sending healthcheck requests into the actual worker, to make sure the worker is able to process requests. Because these are http requests received by roadrunner and passed into the worker, these requests appear in logs, and are counted in metrics. I would like to have logs and metrics that exclude these healthcheck requests. For logs, I can post-process the logs to filter out the healtcheck URI. For metrics though, there is no way to exclude the healthcheck requests, as they are aggregated into the request counter and latency histogram metrics without any way of distinguishing them.

And my suggestion is to follow one of two possible approaches:

  • Allow creating more http listeners in the http plugin, with a label to distinguish them in the metrics
  • Allow the status plugin to forward healthcheck requests to the servers as part of its healthcheck
    • This might be a server plugin feature rather than a status plugin feature?
    • There also need to be two separate types of healthcheck, one for liveness and one for readiness, not sure if RR is handling this at all right now.

devnev avatar Dec 03 '24 03:12 devnev