Investigate if we can add metrics for HTTP ReadHeaderTimeout for Workhorse
The following discussion from !179305 should be addressed: - [ ] @ashmckenzie started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179305#note_2321499325): > Let's see. From https://ieftimov.com/posts/make-resilient-golang-net-http-servers-using-timeouts-deadlines-context-cancellation/, I see: > > ![image](/uploads/d4efc6e193dbe6e938a79d6d59b73b23/image.png) > > I got confused between `ReadTimeout` and `ReadHeaderTimeout`. Setting a 90-second `ReadTimeout` had me much more concerned. https://pkg.go.dev/net/http says this: > > ```go > // ReadHeaderTimeout is the amount of time allowed to read > // request headers. The connection's read deadline is reset > // after reading the headers and the Handler can decide what > // is considered too slow for the body. If zero, the value of > // ReadTimeout is used. If negative, or if zero and ReadTimeout > // is zero or negative, there is no timeout. > ReadHeaderTimeout time.Duration > ``` > > Yeah, I think 90 seconds **should** be more than enough. I wish we'd be able to see these metrics to get a better idea where we are today.
issue