-
Notifications
You must be signed in to change notification settings - Fork 5
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
Increase WebSocket skipped updates metric when queue is not fetched #106
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to have a different metric for this, as ultimately we're counting different things here:
- At this point, one count means one client didn't receive one update, and the cause can be narrowed down to the sending part.
- For the other queue, one count means all clients didn't receive one update, and the cause is likely to be found elsewhere.
It's always easy to make an aggregate dashboard that shows both (or just the sum of both), but getting the individual information from a compound metric after the fact is often hard.
I think I see your point. Though, a bit of detail: when we discard an update in the main update queue (which shouldn't ever happen, now), we don't know which client is affected, but only one of them will be, under our current use, and we're sure only one path will be affected. However, I agree that it would make the information easier to see if we have two different metrics. |
There still can be multiple clients subscribed to the same path, so while indeed it likely doesn't affect all of them if we lose one update to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OpsBotPrime merge |
Pull request approved for merge by @DiegoDiverio, rebasing now. |
…ot fetched Approved-by: DiegoDiverio Auto-deploy: false
Rebased as 65259c1, waiting for CI … |
CI job 🟡 started. |
6bb3398
to
65259c1
Compare
Fixes #103.
I reused the already existing metric, because the user-facing issue would be the same, and we can easily know in which case we are looking at the size of the queue (which can be computed from other metrics).