Page History

...

• We can create a new metric for it. However, it will incur more more storage cost for any metric system since we will be duplicating some request information in the new metric. It also makes it less user friendly for metric systems that can already "slice and dice" on different dimensions (tags) of metrics. In this case, it is easy to "drill down" to a tag without having to look at a completely different metric.
• Create separate meter for each version, but also keep the meter for the request type and increment both at the same time. This creates a problem for metric systems that automatically aggregate for the same metric name and create a "double count" problem.
• Use the new metrics in KIP-188. The problem is that users have to upgrade message format first before seeing the impact, which might be too late and does not help users to make informed decisions.