Make configuration of /metrics http request/response logging

[yortch]

We are using OPA Agent version 0.49. We have prometheus enabled with log-level set to info. We have a ServiceMonitor that is scraping metrics from the "/metrics" endpoint. Scraping interval is set at 15 seconds and we cannot make it much less infrequent. However the problem at hand is that our logs are becoming too verbose because these entries are INFO level. We would like a way to make disable entries for the /metrics endpoint or perhaps these entries should be logged only at debug level.

Sample entries from OPA agent log:

{"client_addr":"ip:port","level":"info","msg":"Received request.","req_id":14,"req_method":"GET","req_path":"/metrics","time":"2022-06-02T15:17:26Z"} {"client_addr":"ip:port","level":"info","msg":"Sent response.","req_id":14,"req_method":"GET","req_path":"/metrics","resp_bytes":2940,"resp_duration":1.281055,"resp_status":200,"time":"2022-06-02T15:17:26Z"}

[anderseknert]

Hi @yortch!

Is there any particular reason you want to log at INFO level? Our usual recommendation is to log at ERROR level for production environments, and use the decision logging capabilities of OPA to send decision logs to a remote server / control plane.

The access logs are generally noisy, and I think that even at INFO level, we might want to provide an option to have those turned off.

[yortch]

There are some info level entries that we’d like to preserve, for instance bundle loading entries. INFO level seems to be working for us in terms of verbosity except for these metrics entries. Since this customer is adopting OPA for the first time they feel more comfortable going live with INFO level and will consider changing to WARN later on.

Thank you, Jorge

On Jun 7, 2022, at 8:56 AM, Anders Eknert @.***> wrote:

 Hi @yortch!

Is there any particular reason you want to log at INFO level? Our usual recommendation is to log at ERROR level for production environments, and use the decision logging capabilities of OPA to send decision logs to a remote server / control plane.

The access logs are generally noisy, and I think that even at INFO level, we might want to provide an option to have those turned off.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[anderseknert]

Thanks Jorge!

Yeah I think we're basically mixing two different loggers at INFO level currently — the first one being the application logs where things like bundle activation is logged, and the other logger is the "access logger" printing all the incoming requests... would disabling the access logger be a viable solution to you?

[yortch]

Yes, disabling the access logger should be a viable solution.

Thank you, Jorge

On Jun 13, 2022, at 11:06 AM, Anders Eknert @.***> wrote:

 Thanks Jorge!

Yeah I think we're basically mixing two different loggers at INFO level currently — the first one being the application logs where things like bundle activation is logged, and the other logger is the "access logger" printing all the incoming requests... would disabling the access logger be a viable solution to you?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[yortch]

Another viable solution could be to allow writing the access logs into a separate log file.

Thank you, Jorge

On Jun 13, 2022, at 10:11 AM, Jorge Balderas @.***> wrote:

Yes, disabling the access logger should be a viable solution.

Thank you, Jorge

On Jun 13, 2022, at 11:06 AM, Anders Eknert @.***> wrote:

 Thanks Jorge!

Yeah I think we're basically mixing two different loggers at INFO level currently — the first one being the application logs where things like bundle activation is logged, and the other logger is the "access logger" printing all the incoming requests... would disabling the access logger be a viable solution to you?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[ashutosh-narkar]

Closing this in favor of https://github.com/open-policy-agent/opa/issues/4744