haproxy: count available/unavailable backends #834
Merged
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/3
andup_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
up
in their state into theavailable
category, and allof the ones that are either
down
, inmaint
, or are set tonolb
in theunavailable
category. we ignoreopen
andclosed
becuase those pertain tofrontends, not backends.
all
available
backends can recieve traffic, while allunavailable
onescannot. this provides a great metric to monitor and alert on.