ocis logs are inconsistent

[micbar]

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce

Steps to reproduce the behavior:

1. Set ocis log level to warning
2. Start ocis

Expected behavior

I can see a json formatted log output
I can see only log entries which have the warning level or higher

Actual behavior

1. There are non-json formatted log entries

2023/06/07 07:43:58 http: TLS handshake error from 172.18.0.2:43396: EOF

2023/06/07 07:52:22 http: proxy error: unsupported protocol scheme ""

3. There are info log level messages

{"level":"info","time":"2023-06-07T07:52:20.425745096Z","caller":"github.com/cs3org/reva/[email protected]/pkg/storage/utils/decomposedfs/migrator/0001_create_spaces_directory_structure.go:33","message":"Migrating spaces directory structure..."}
{"level":"info","time":"2023-06-07T07:52:20.426674504Z","caller":"github.com/cs3org/reva/[email protected]/pkg/storage/utils/decomposedfs/migrator/0002_move_spacetypes_to_indexes.go:31","message":"Migrating space types indexes..."}
{"level":"info","root":"/var/lib/ocis/storage/metadata","time":"2023-06-07T07:52:20.426987636Z","caller":"github.com/cs3org/reva/[email protected]/pkg/storage/utils/decomposedfs/migrator/0003_switch_to_messagepack_metadata.go:45","message":"Migrating to messagepack metadata backend..."}

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Add any other context about the problem here.

[2403905]

1. There is no way to change the NATS logs format to json. It is not supported Support structured logging nats-io/nats-server#1240

2. When creating a new Migrator in a decomposedfs, there is nothing to grab to get the logger configuration. https://github.com/cs3org/reva/blob/85eb1beacb5efe9cf145536b3d40d889d2d12f03/pkg/storage/utils/decomposedfs/decomposedfs.go#L146

[dragonchaser]

1. is output from the http lib, directly send to stdout, can't be avoided (for now)
2. We do not have information about the log level at that point, either pass it to reva (would require lots of changes in reva [lots of effort]) or remove the message. If the message gets removed we loose information about the migration progress which is also not a good idea. We suggest to close the ticket as WONTFIX.

@micbar can you please decide?

[micbar]

hmm, ugly but currently not avoidable.

Closing

[micbar]

Re opening.

@rhafer told me that we can maybe catch that.

@xoxys FYI

[rhafer]

The http: proxy error stuff is coming from here: https://github.com/golang/go/blob/master/src/net/http/httputil/reverseproxy.go#L307 It's possible to set a custom logger for the reverse proxy.

The other one is coming somewhere else from net/http, but I think it's also possible to override the loggers from http client/server.

[aduffeck]

#10743 and cs3org/reva#4996 fixes all unstructured logging issues except for the http.Server ones in our http services. Fixing these isn't easy even though http.Server has an ErrorLogger field, because the servers are instantiated by go-micro which doesn't expose that setting to us.