Tidier gin logs

[MalinAhlberg]

Related issue(s) and PR(s)

This PR closes #1258.

Description

This is a first version of the updated gin logging, to start discussions.
Note I would like feedback on the desired result, rather than the actual implementation at this stage :) .

This version will

• not log the list of endpoints if run in production mode (or actually log level != debug)
• not log general requests to download, unless
  • the request was unsuccessful (status code >= 400)
  • the request was a request to download a file (/s3)
  • or in debug mode

In production mode, the logs looks like:

A failed request and a request to download are listed, other requests ignored.

In debug mode, the logs looks like:


Endpoints are listed, all request (except for /health) are listed.

How to test

• change log.level to a desired level in sda-download/dev_utils/config-notls_local.yaml
• start the sda services: make integrationtest-sda-s3-run
• Change to the folder sda-download and start the sda-download service using CONFIGFILE=dev_utils/config-notls_local.yaml go run cmd/main.go

[MalinAhlberg]

One suggestion (from @jbygdell) is to not log anything from gin in production, and make sure that the code logs all errors and warnings from other places instead. Any opinions on this from @aaperis @pahatz @kostas-kou @nanjiangshu ?

[pahatz]

One suggestion (from @jbygdell) is to not log anything from gin in production, and make sure that the code logs all errors and warnings from other places instead. Any opinions on this from @aaperis @pahatz @kostas-kou @nanjiangshu ?

I'm curious on how we would log them from other places and if it would propagate there all the info that might be useful when checking some error.
I don't have any preference on the solution, I would just prefer to not go on the other side and lose any error logs.

[aaperis]

One suggestion (from @jbygdell) is to not log anything from gin in production, and make sure that the code logs all errors and warnings from other places instead. Any opinions on this from @aaperis @pahatz @kostas-kou @nanjiangshu ?

from my side, I haven't found gin's logs that useful, so I agree with @jbygdell's suggestion. Could be that we can add a conditional to have gin logs turned on only if the usual logging level is set to debug.

[MalinAhlberg]

I'm curious on how we would log them from other places and if it would propagate there all the info that might be useful when checking some error. I don't have any preference on the solution, I would just prefer to not go on the other side and lose any error logs.

I believe that we would have to verify (=>new issue), or just assume, that the code already logs reasonable things from all places errors and warnings could arise. The gin logs mostly give info on what endpoints that have been requested, and what status code the call produced. As far as I know, at least, but I'm not a proficient user of these logs... If anyone is interested in these types of logs, let's keep them, otherwise this PR will make gin stop logging for production mode. It will still log as usual for debug