haproxy: count available/unavailable backends #834
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
LGTM. |
currently, the haproxy check reports a count for each distinct status; this means that service backends in status 'up' will end up in different buckets then backends in status `up_1/3` and `up_2/3` (which result from backends going through the haproxy health check rise/fall intervals). if you have a large rise/fall count, there might be a huge number of separate buckets. however, often, the real concern is "how many backends can and cannot recieve new traffic". this question is what this PR is trying to answer. we group all backends that have `up` in their state into the `available` category, and all of the ones that are either `down`, in `maint`, or are set to `nolb` in the `unavailable` category. we ignore `open` and `closed` becuase those pertain to frontends, not backends. all `available` backends can recieve traffic, while all `unavailable` ones cannot. this provides a great metric to monitor and alert on.
|
this is currently running in our infrastructure without any problems |
|
Thanks @igor47 I'm merging it. |
remh
added a commit
that referenced
this pull request
Feb 24, 2014
haproxy: count available/unavailable backends
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
currently, the haproxy check reports a count for each distinct status; this
means that service backends in status 'up' will end up in different buckets
then backends in status
up_1/3andup_2/3(which result from backends goingthrough the haproxy health check rise/fall intervals). if you have a large
rise/fall count, there might be a huge number of separate buckets.
however, often, the real concern is "how many backends can and cannot recieve
new traffic". this question is what this PR is trying to answer. we group all
backends that have
upin their state into theavailablecategory, and allof the ones that are either
down, inmaint, or are set tonolbin theunavailablecategory. we ignoreopenandclosedbecuase those pertain tofrontends, not backends.
all
availablebackends can recieve traffic, while allunavailableonescannot. this provides a great metric to monitor and alert on.