-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add /status endpoint #52
base: master
Are you sure you want to change the base?
Conversation
This makes the function usable for more than just returning error responses.
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. panic: runtime error: invalid memory address or nil pointer dereference goroutine 39820761 [running]: |
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 ***@***.***> 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: