CC @neild @bradfitz

Do you have a suggested API? Thanks.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Do you have a suggested API? Thanks.

In the spirit of minimal change and consistency with the google.golang.org/grpc/grpclog package, I'd suggest it could be as simple as http2.SetLogger(l Logger) that updates a package global, where Logger is identical to grpclog.LoggerV2.

I would then personally be ok with all logs going to debug, but otherwise the implementer will need to determine the right log level for every existing log line. Then the default implementation can log in whatever format makes sense, probably the same as it does today if compatibility is important.

Alternatively (I can spec this out with more effort if interested), each struct in the package could have a Logger field with the same interface and optionally a (new) constructor to set the logger. However, without a corresponding change to grpclog to wire through the user-provided logger I think the utility of this would be limited, since as the package states very few people are using the http2 package directly.

Adding grpclog.LoggerV2 to any package in std is a non-starter. That's an enormous interface. What about *log.Logger instead (from the standard log package)? Or just an io.Writer?

We are also thinking about whether to revamp logging in std generally. Maybe we should hold this for that work. /cc @jba

Getting useful log information and directing it to a desired location are reasonable desires, but I don't think slapping an additional public API on the http2 package's existing logs is the right thing to do. What about net/http and HTTP/1 logs? TLS? Are there other standard library packages that should have logging? What kinds of events should we be logging in all of these?

The http2 package has the ability to emit debug logs, but they're extremely ad hoc and there pretty much only for debugging the HTTP/2 implementation.

What about *log.Logger instead (from the standard log package)? Or just an io.Writer?

An interface would be better than *log.Logger IMO. io.Writer would be totally fine! Let me know if you want me to come up with a more complete proposal based on that.

What about net/http and HTTP/1 logs? TLS?

Well, as someone who works on those at the protocol level I'd say yes (if it's a cheap language addition) but I recognize that's relatively niche.

The http2 package has the ability to emit debug logs, but they're extremely ad hoc and there pretty much only for debugging the HTTP/2 implementation.

Just to provide a counter example, I got to this point because I was debugging random stalls over a high-throughput gRPC connection and it turned out the HTTP/2 debug logs held the key to the fix:

2022/05/06 18:45:48 http2: Framer 0xc0000f0c40: wrote WINDOW_UPDATE len=4 (conn) incr=4107

Seeing a flood of these told me I needed to increase initial connection window sizes on both ends; I think the only way I could have tackled this problem without logs was to start trying knobs until something panned out.

We should probably put this on hold until we have a clearer story about what to do about logging generally, starting with package log.

Placed on hold.
— rsc for the proposal review group