Skip to content

Comments

rabbit_osiris_metrics: Use committed_offset counter#15390

Draft
the-mikedavis wants to merge 1 commit intomainfrom
md/osiris-metrics-committed-offset
Draft

rabbit_osiris_metrics: Use committed_offset counter#15390
the-mikedavis wants to merge 1 commit intomainfrom
md/osiris-metrics-committed-offset

Conversation

@the-mikedavis
Copy link
Collaborator

This change uses the committed offset as the last offset in the calculation of available offsets rather than the last-written offset. Stream readers can't access tail data until it becomes committed so this is a more accurate count for "ready" messages.

This is meant to extend #15225 so it's for v4.3.x only.

This change uses the committed offset as the last offset in the
calculation of available offsets rather than the last-written offset.
Stream readers can't access tail data until it becomes committed so this
is a more accurate count for "ready" messages.
@the-mikedavis the-mikedavis self-assigned this Feb 3, 2026
Data = osiris_counters:overview(),
_ = maps:map(
fun ({osiris_writer, QName}, #{offset := Offs,
fun ({osiris_writer, QName}, #{committed_offset := COffs,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to check the feature flag and use it to decide whether we should use offset or committed_offset?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If those values can come from other nodes, we do. If they are entirely local state, maybe not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should not crash as committed_offset is always available, but the stats will be slightly inaccurate before the changes in #15225 are enforced with the 4.3 feature flag. committed_offset is the offset of the last committed chunk pre-15225, so it is behind by the number of messages in the chunk compared to the actual last offset.

This should fix itself when the upgrade is done and after the streams restart, so I guess it is reasonable considering it is just stats.

WDYT @kjnilsson ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it is mostly informational at this point so shouldn't matter, let's not bother the ff subsystem if we don't have to.

@the-mikedavis the-mikedavis marked this pull request as draft February 4, 2026 15:02
@the-mikedavis the-mikedavis added this to the 4.3.0 milestone Feb 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants