How to squelch Netty debug Logs? (Set Log Level)

[theronic]

How do I disable noisy DEBUG logs like these:

│ 11:33:51.444 [grpc-nio-worker-ELG-1-2] DEBUG i.g.n.s.i.g.netty.NettyClientHandler - [id: 0x4ecdf329, L:/127.0.0.1:62354 - R:localhost/127.0.0.1:50051] INBOUND HEADERS: streamId=109 headers=GrpcHttp2ResponseHeaders[grpc-status: 0, grpc-message: , io.spicedb.respmeta.cachedoperationscount: 0, io.spicedb.respmeta.dispatchedoperationscount: 7] padding=0 endStream=true
│ 11:33:51.446 [grpc-nio-worker-ELG-1-2] DEBUG i.g.n.s.i.g.netty.NettyClientHandler - [id: 0x4ecdf329, L:/127.0.0.1:62354 - R:localhost/127.0.0.1:50051] OUTBOUND HEADERS: streamId=111 headers=GrpcHttp2OutboundHeaders[:authority: localhost:50051, :path: /authzed.api.v1.PermissionsService/ExpandPermissionTree, :method: POST, :scheme: http, content-type: application/grpc, te: trailers, user-agent: grpc-java-netty/1.55.1, grpc-accept-encoding: gzip, authorization: Bearer spicedb] streamDependency=0 weight=16 exclusive=false padding=0 endStream=false
│ 11:33:51.446 [grpc-nio-worker-ELG-1-2] DEBUG i.g.n.s.i.g.netty.NettyClientHandler - [id: 0x4ecdf329, L:/127.0.0.1:62354 - R:localhost/127.0.0.1:50051] OUTBOUND DATA: streamId=111 padding=0 endStream=true length=42 bytes=00000000250a02200112170a06736572766572120d6e6f742d6d792d7365727665721a067265626f6f74
│ 11:33:51.447 [grpc-nio-worker-ELG-1-2] DEBUG i.g.n.s.i.g.netty.NettyClientHandler - [id: 0x4ecdf329, L:/127.0.0.1:62354 - R:localhost/127.0.0.1:50051] INBOUND WINDOW_UPDATE: streamId=0 windowSizeIncrement=42

I'm using the Java AuthZed client from Clojure. I see that authzed-java uses java.util.logging.Logger, which according to this answer on SO supports a logging.properties file, but then you have to pass an argument to the Java call. I'm not sure how to do this.

[tstirrat15]

My last company was a clojure shop... I'm trying to remember how we approached this problem.

One piece of it is that authzed-java is a relatively thin wrapper around grpc-java, so the solution is gonna operate at that level. It also looks like Netty uses SLF4J, which is going to attempt to attach to whatever logging backend you're currently running, which may or may not be java.util.logging.Logger.

There's an issue here that may be helpful: https://github.com/grpc/grpc-java/issues/3033#issuecomment-309567676

Let me know what you find, though - this seems like it'd be something useful to have documented in an FAQ.