Increase WebSocket skipped updates metric when queue is not fetched #106
Conversation
There was a problem hiding this comment.
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 |
|
@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. |
OpsBotPrime
force-pushed
the
dd/subscriber-metrics
branch
from
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).