fix: offsetFetchResponse missing topic partitions #432
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Following the upgrade of the kafka_Exporter, a discrepancy in metrics was discovered, specifically involving consumer groups in an "Empty" state not being tracked. Upon examination, it was observed that the
offsetFetchResponse
did not contain necessary information for the consumer group identified as "pipes-pro-1dfe17f5-c4d9-4be2-bf46-144f03a60a36".Worth to mention this CG is committing offsets and working properly, the client is manually handling it, that is the reason it shows up in Empty state
To investigate further, the exporter was initiated with additional logging parameters to capture details about the
offsetFetchResponse
. Running the exporter command showed that the initial response had a Version 1 with empty mapping:offsetFetchResponse: &{1 0 map[]
.Upon switching to Version 4, the mapping included the requisite information, allowing for successful tracking of consumer group activities:
offsetFetchResponse: &{4 0 map[Private-Pipes-Synthetic-10-Events-Partition-Every-Second:map[0:0x40065f7b00 1:0x40065f73b0 2:0x40065f7e00 3:0x40065f7aa0 4:0x40065f7770 5:0x40065f7e60 6:0x40065f7dd0 7:0x40065f77a0 8:0x40065f7620 9:0x40065f7e90 10:0x40057f2000 11:0x40065f7da0 12:0x40065f7b60 13:0x40065f7560 14:0x40057f2030 15:0x40065f7590 16:0x40065f7b90 17:0x40065f7c50 18:0x40065f7cb0 19:0x40065f7bf0 20:0x40065f73e0 21:0x40065f75c0 22:0x40065f7ce0 23:0x40065f7bc0]]
.Moreover, it was noted that the
fetchOffsetVersion()
function, previously utilized for this purpose, had been commented out, leading to the Version being hardcoded within theOffsetFetchRequest
function.