This enables the infrequent use of more complex Prometheus types, such as
timeseries with high/irregular label cardinality, without needing to
discover and implement generic abstracted type like LabelMap for each one.
Signed-off-by: David Anderson <danderson@tailscale.com>
When the request comes in say over http://mon, the current
implementation would rewrite it https://mon which causes the cert
validation to fail. This PR keeps the existing behavior intact but also
allows passing in a FQDN to the handler to reroute to the correct
hostname.
Related to https://github.com/tailscale/tailscale/pull/4208#pullrequestreview-913832340
Signed-off-by: Maisem Ali <maisem@tailscale.com>
A new package can also later record/report which knobs are checked and
set. It also makes the code cleaner & easier to grep for env knobs.
Change-Id: Id8a123ab7539f1fadbd27e0cbeac79c2e4f09751
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It was accidentally deleted in the earlier 0022c3d2e (#2143) refactor.
Lock it in with a test.
Fixestailscale/corp#2503
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
To be scraped in the Go expvar JSON format, as a string is involved.
For a future tool to record when processes restarted exactly, and at
what version.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
We want to use tsweb to format Prometheus-style metrics from
our temporary golang.org/x/net/http2 fork, but we don't want http2
to depend on the tailscale.com module to use the concrete type
tailscale.com/metrics.LabelMap. Instead, let a expvar.Map be used
instead of it's annotated sufficiently in its name.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
A previously added metric which was float64 was being ignored in tsweb, because it previously
only accepted int64 and ints. It can be handled in the same way as ints.
Signed-off-by: julianknodt <julianknodt@gmail.com>
This change is to make JSONHandler error handling intuitive, as before there would be two sources of HTTP status code when HTTPErrors were generated: one as the first return value of the handler function, and one nested inside the HTTPError. Previously, it took the first return value as the status code, and ignored the code inside the HTTPError. Now, it should expect the first return value to be 0 if there is an error, and it takes the status code of the HTTPError to set as the response code.
Signed-off-by: Daniel Chung <daniel@tailscale.com>
This lets servers using tsweb register expvars
that will track the number of requests ending
in 200s/300s/400s/500s.
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
There's often some useful piece of information in there not already
repeated in the internal error.
Signed-off-by: David Crawshaw <crawshaw@tailscale.com>
The name's been bugging me for a long time.
I liked neither the overlap between tsweb.Handler and http.Handler,
nor the name "ServeHTTPErr" which sounds like it's an error being
returned, like it's an error handler and not sometimes a happy path.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It's technically weird to return a tsweb.Error with no child err,
but it's a sensible thing to want to do, and we shouldn't panic
if it happens.
Signed-off-by: David Anderson <dave@natulte.net>
Handler is like http.Handler, but returns errors. ErrHandler
converts back to an http.Handler, with added error handling
and logging.
Signed-off-by: David Anderson <dave@natulte.net>
Basically, don't trust the OS-level link monitor to only tell you
interesting things. Sanity check it.
Also, move the interfaces package into the net directory now that we
have it.
David Anderson
Maisem Ali
Josh Bleecher Snyder
Brad Fitzpatrick
nicksherron
slowy07
julianknodt
chungdaniel
David Crawshaw
halulu
Zijie Lu
David Anderson