DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
Add a metric for each production feature (i.e. metadata.version , kraft.version , transaction.version , group.version , eligible.leader.replicas.version , share.version, and sharestreams.version ).
This can be accomplished via one generic "feature level" metric that is tagged by feature. Using a generic metric allows for new production features to automatically expose their feature level going forward.
| Name | Type | Description |
|---|---|---|
| kafka.server:type=MetadataLoader,name=FeatureLevel,featureName=X | Integer | The value of the feature level for a feature named "X". |
The default value of this metric should be the default value of the featureThis metric will report the finalized feature level for each production feature. If the feature level is not set, the metric will return a value of 0.
Compatibility, Deprecation, and Migration Plan
We might want to will deprecate the kafka.server:type=MetadataLoader,name=CurrentMetadataVersion metric since this per-feature tagged metric can also expose the current metadata versionexposes this value, and the previous metric can be removed starting in 5.0.
Test Plan
We will add junit tests to verify the new metrics.
Rejected Alternatives
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other wayRunning kafka-feature describe on every node is one way to track migration, but it is not straightforward to monitor since it is not a metric.