Summaries as implemented cannot be aggregated in a meaningful
way. Partitoning them by status code and method only made sense if we
were interested in the individual latency and size of e.g. GET request
that result in status 503. In general, that's not the case. Most of
the time, the user will be interested in the latency and size of _all_
HTTP requests.
(With future changes to client_golang, we will consider making the
HTTP instrumentation configurable, e.g. to handle the case where the
user is only interested in the latency of successful requests.)
computeApproximateRequestSize is run in a goroutine, but the
handlerFunc that runs in parallel may modify the URL, which is also
needed by computeApproximateRequestSize. So get the URL length
beforehand.
Change-Id: Idb84735845afe7be4ef79b3d642d5764f6d26a7c
Also, remove quotes from the Content-type header. It's not illegal to
have quotes there, but they are not needed, and at other places, we
are not using them. So fewer characters and more consistency.
Change-Id: If7a78bde85154163e4426daec493d973213e83e9
Also, fix seconds to microseconds fot the http instrumentation to
match the metric name.
Fix Desc.String().
Simplify http error display.
Change-Id: Ib7397f4eac1eeed92b291e1c9cc88c080aee99ca
This rewrite had may backs and forths. In my git repository, it
consists of 35 commits which I cannot group or merge into reasonable
review buckets. Gerrit breaks fundamental git semantics, so I have to
squash the 35 commits into one for the review.
I'll push this not with refs/for/master, but with refs/for/next so
that we can transition after submission in a controlled fashion.
For the review, I recommend to start with looking at godoc and in
particular the many examples. After that, continue with a line-by-line
detailed review. (The big picture is hopefully as expected after
wrapping up the discussion earlier.)
Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
Bjoern Rabenstein