Replace info logs with debug logs

[FlyingRatBull]

Replacing the info logs with debug logs allows the usage in production environments with heavy API usage without cluttering the logs.

[stepancheg]

Should start_call be left INFO?

Generally, after startup which messages should be INFO or higher?

[FlyingRatBull]

I think as gRPC is a tool used in an application and not the main purpopse of an application that no message should be INFO. If it makes sense for an application to notify the user about gRPC startup or any other gRPC related event, it (the application) should do so by itself. But almost all the time the application is supposed to be handling any events like startups or even errors.

In other gRPC implementations there are commonly one of two approaches:

• No default logger is used and if the user wishes to, he can set one (-> no log messages by default)
• Default logger with debug/trace messages (-> no info or higher log messages by default)

[stepancheg]

OK, but what about events like:

• client connection accepted on the server
• reconnect happened on the client
• network error
• protocol error they also should be DEBUG?

[zirpu]

OK, but what about events like:

* client connection accepted on the server

* reconnect happened on the client

* network error

* protocol error
  they also should be DEBUG?

I would argue that those should default to DEBUG because the are out of the server's control. One would only turn on logging to debug the issue, not as a production log.

Though I do acknowledge that collecting metrics of those errors would be useful, filling up a log file with them would be useless in a non-debuging context.

[stepancheg]

Honestly, I never had a love for logs. Currently, different levels are useful for debugging: with env logger different logging levels are displayed in different colours.

So I have no preferences what should be logging levels for which events.

Anyway, what you say makes sense. Before applying it let's specify what events should be at which level:

• server started, client started, server shutdown — INFO
• connection opened, connection closed — DEBUG
• network error, protocol error — DEBUG
• request started, request finished — DEBUG
• frame sent, frame received — TRACE
• internal state updates — TRACE
• user errors (like incorrect API usage, or error from handler or panic) — WARN or ERROR
• no other events are logged with WARN or ERROR

This looks consistent, but usually, log filtering can be used to hide certain events. E. g. if you are not interested in request started event or connection open, you hide INFO level.

Anyway, as I said, I don't have strong preference, but I'd like to have a semi-formal description.

[FlyingRatBull]

That sounds quite good to me. Maybe in the future we can pass a logger to the client/server so the user can decide by himself, how to handle the logs or disable them completely.

[stepancheg]

Maybe in the future we can pass a logger to the client/server so the user can decide by himself, how to handle the logs or disable them completely

To avoid misunderstanding: users currently can configure the log level. E. g. if using env_logger, it can be something like

RUST_LOG=grpc=warn myexe

The discussion is about what levels should be the default.

Or I did not get your point.

[FlyingRatBull]

I meant 'user' more in the sense of the developer, using the gRPC implementation in an application. Because it depends not only on the user (which can use the env variable as pointed out by you) but also on the application itself, whether gRPC related logging is relevant or to what extent.

And yes, the discussion was about the default log levels.

[stepancheg]

Thanks!