-
Notifications
You must be signed in to change notification settings - Fork 495
support serving up go-metrics as expvars #96
Conversation
// panic: http: multiple registrations for /debug/vars | ||
// http.HandleFunc("/debug/vars", e.expHandler) | ||
// haven't found an elegant way, so just use a different endpoint | ||
http.HandleFunc("/debug/vars2", e.expHandler) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this endpoint configurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would be the point of introducing variability for this?
it makes more sense to me IMHO to have some sort of "convention" for the address of a "go-metrics enabled expvar page". one thing is for sure: I couldn't find a way to take over/use
/debug/vars
. Actually now that I think about it, /debug/vars
is also fixed for convention, which I think is a good thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. Then how about just 'debug/metrics'? I'm generally not
a fan of adding numbers to variable names and urls where there's an
opportunity to have a meaningful name.
On Saturday, July 4, 2015, Dieter Plaetinck [email protected]
wrote:
In exp/exp.go
#96 (comment):
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
fmt.Fprintf(w, "%q: %s", kv.Key, kv.Value)
- })
- fmt.Fprintf(w, "\n}\n")
+}
+func Exp(r metrics.Registry) {
- e := exp{sync.Mutex{}, r}
- // this would cause a panic:
- // panic: http: multiple registrations for /debug/vars
- // http.HandleFunc("/debug/vars", e.expHandler)
- // haven't found an elegant way, so just use a different endpoint
- http.HandleFunc("/debug/vars2", e.expHandler)
what would be the point of introducing variability for this?
it makes more sense to me IMHO to have some sort of "convention" for the
address of a "go-metrics enabled expvar page". one thing is for sure: I
couldn't find a way to take over/use
/debug/vars. Actually now that I think about it, /debug/vars is also
fixed for convention, which I think is a good thing.—
Reply to this email directly or view it on GitHub
https://github.com/rcrowley/go-metrics/pull/96/files#r33890766.
Sent from Russia, with love. But also from my phone.
Any reason why this didn't get merged? |
Yes, but no relevant ones. Everyone involved in maintaining this repo has On Friday, November 13, 2015, Sargun Dhillon [email protected]
Sent from Russia, with love. But also from my phone. |
sounds like very good reasons to me. congrats to the babies and acquisitions everyone ;) |
OK finally getting back to this. I still would like to see a URL that was something more descriptive than |
there you go ^^ |
Is there anything I can do to help with in order to get this merged? |
why this is not yet on master?? |
I keep forgetting to click merge. At the office in ~10, will click. On Wednesday, January 13, 2016, El-Soufy [email protected] wrote:
Sent from Russia, with love. But also from my phone. |
support serving up go-metrics as expvars
not thoroughly tested yet, but seems to work fine so far.