The lag arithmetic, separated from every I/O that feeds it.
Lag is the single most important number this service publishes and it is trivially easy to get subtly wrong — off by one, negative during a reset, or fabricated for a partition nobody has ever committed to. Keeping it as a pure function over two maps is what makes those cases testable without a broker.
Lag per partition: how many records sit between the group's committed offset and the log end.
Lag per partition: how many records sit between the group's committed offset and the log end.
Two rules, both of which exist because the alternative produces a false alarm:
A partition with no committed offset is omitted, not reported as zero and not reported as end. A group that has never committed genuinely has unknown lag: reporting end pages the on-call the first time a topic is created, reporting 0 claims a consumer is caught up when it has not read a single record. Omitting it leaves a gap in the series, which is the honest rendering of "no data".
Negative differences clamp to zero. The committed offset can legitimately exceed the log end for a moment after a topic truncation, a partition reassignment, or an offset reset, and a negative lag on a dashboard is read as a broken exporter rather than as the transient it is.
Total lag across the group. The number an alert threshold is actually written against — per-partition lag answers "which one", but only the sum answers "is the consumer falling behind".
Total lag across the group. The number an alert threshold is actually written against — per-partition lag answers "which one", but only the sum answers "is the consumer falling behind".