Open weshmashian opened 7 years ago
This is great! I was just looking to go about a patch for something similar. Shame this doesn't appear to have been merged yet...
The /status endpoint would be great. Unfortunately, these changes cause influxdb-relay to randomly crash.
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66a4b4]
goroutine 39820761 [running]: github.com/influxdata/influxdb-relay/relay.(retryBuffer).post(0xc42013ca00, 0xc422eb9980, 0x1886, 0x18cd, 0xc421e90b60, 0x1e, 0xc422a5b0b0, 0x26, 0x0, 0x0, ...) /root/go/src/github.com/influxdata/influxdb-relay/relay/retry.go:76 +0xd4 github.com/influxdata/influxdb-relay/relay.(HTTP).ServeHTTP.func1(0xc423ea9120, 0xc4201518e0, 0xc422eb9980, 0x1886, 0x18cd, 0xc421e90b60, 0x1e, 0xc422a5b0b0, 0x26, 0xc420154400, ...) /root/go/src/github.com/influxdata/influxdb-relay/relay/http.go:232 +0xd3 created by github.com/influxdata/influxdb-relay/relay.(*HTTP).ServeHTTP /root/go/src/github.com/influxdata/influxdb-relay/relay/http.go:241 +0xc44
That is quite possible. I'd suggest using one of the active forks of this project.
Hey Marko,
Which fork do you suggest?
Regards,
Tim Raphael
On 20 Feb 2018, at 1:58 am, Marko Crnic notifications@github.com wrote:
That is quite possible. I'd suggest using one of the active forks of this project.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Can't really suggest any of them as I haven't tried them. Current version with this patch works for my use-case.
Hello, we're planning to maintain an active fork here: https://github.com/vente-privee/influxdb-relay.
We've done the job inspired by your PR.
This PR is now merged on https://github.com/vente-privee/influxdb-relay/tree/develop.
This adds new /status endpoint which should report current status of relay, i.e. list of endpoints, amount of buffer used and whether the buffering is active or not.
That info is crucial for implementing proper monitoring of relay, predicting acceptable downtime (as mentioned in #49) and scaling.
Side effect of this patch is refactor of jsonError function to a more general jsonResponse. We've been using a variation of this patch for a couple of months in production with no noticeable side-effects.
Example output (using sample_buffered.toml) with local1 instance being available and local2 being unreachable: