Skip to content

Conversation

bboreham
Copy link
Contributor

@bboreham bboreham commented Jun 29, 2020

This reverts #2802.

Operators need to know why the flush queue is growing at that time, not at a later time when the queue has cleared.

This reverts commit d16b681.

Make the metric useful again.

Signed-off-by: Bryan Boreham <[email protected]>
@pstibrany
Copy link
Contributor

pstibrany commented Jun 29, 2020

This reverts #2802.

Operators need to know why the flush queue is growing at that time, not at a later time when the queue has cleared.

This change makes the metric less useful.
If you have an enormous queue you want to know why now, not in two hours when it is flushed.

Fair enough, but isn't this metric useful too? I mean we can keep the current metric, and re-add metric that counts them when enqueing.

@bboreham
Copy link
Contributor Author

Sure, we can have both.

@pracucci
Copy link
Contributor

Sure, we can have both.

Agree on having both.

@pracucci
Copy link
Contributor

pracucci commented Aug 5, 2020

Closing because superseded by #2818.

@pracucci pracucci closed this Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants