go: net/http: do not log error in http.Server for TCP probes
What version of Go are you using ?
1.10.x
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using?
N/A
What did you do?
Kubernetes apiserver is based on http.Server with a TLS config. If you put a Loadbalancer in front of it which implements basic TCP probing for the load balancing you end up being flooded by the following message:
I0810 08:34:34.483565 1 logs.go:49] http: TLS handshake error from 168.63.129.16:64551: EOF
Which originates from:
What did you expect to see?
I was hoping we could avoid logging an error for opened and closed tcp sockets.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 12
- Comments: 18 (8 by maintainers)
Commits related to this issue
- Uses debug log for `http: TLS handshake error ... EOF` See * https://github.com/golang/go/issues/26918 * https://github.com/kubernetes/kubernetes/pull/91277 Signed-off-by: Alexander Yastrebov <alexa... — committed to zalando/skipper by AlexanderYastrebov 3 years ago
- Uses debug log for `http: TLS handshake error ... EOF` See * https://github.com/golang/go/issues/26918 * https://github.com/kubernetes/kubernetes/pull/91277 Signed-off-by: Alexander Yastrebov <alexa... — committed to zalando/skipper by AlexanderYastrebov 3 years ago
- Uses debug log for `http: TLS handshake error ... EOF` (#1904) See * https://github.com/golang/go/issues/26918 * https://github.com/kubernetes/kubernetes/pull/91277 Signed-off-by: Alexander Yast... — committed to zalando/skipper by AlexanderYastrebov 3 years ago
@kayrus I hope you are joking about effectiveness 😃
As per https://pkg.go.dev/log#Logger
the solution could look like:
I wouldn’t be either. Fortunately nobody mentioned a regexp here. 😃
IMO, a better way to monitor an HTTP server is to send an HTTP request.
Back in the day, the HTTP load balancer I wrote for LiveJournal got its most notable improvements when we started making load balancing decisions based on which backend could reply to an quick dummy
OPTIONS * HTTP/1.1HTTP request rather than just accept TCP. Because we wanted to see that we were talking to the real server in userspace and not just the kernel’s TCP accept backlog.Ever since then when I want to see if an HTTP server is up I don’t trust that just its TCP port is replying. Who knows what that’ll be. Maybe that’s just systemd or something else listening for you and handing your (possibly failing to start) program a file descriptor.
In fact, Go’s HTTP server handles
OPTIONS *requests by default:Or, if you want the server to close the connection for you and not have to require a Hostname, use HTTP/1.0 (with its implicit
Connection: close):We’d use a func rather than a channel, but I really don’t want to add new API if we can help it.
And we already have a place we send non-fatal errors: the logger. Because we never call
log.Fatal.Or what sort of current error today do you consider fatal?