[
https://issues.apache.org/jira/browse/KAFKA-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354376#comment-14354376
]
Jay Kreps commented on KAFKA-1930:
----------------------------------
Hey [~gwenshap] this is wheel reinvention, no question. However, there was
definitely a significant period of pain that lead to it.
Embedding that library in the client was a real disaster, arguably the single
biggest source of issues/complaints we had as it broke compatibility and then
forced each client user to try to reconcile conflicting versions with weird
classpath hacks if our version differed from theirs. I feel pretty strongly we
should stick with our "no dependencies" policy for client code. We also had a
variety of memory related issues related to how histograms work. In the end it
was the Yammer metrics users who most wanted us to get rid of it because it
tended to be they who would deal with all the incompatibilities.
I think there is a real difference here between internal apps that just need to
work in a single dropwizard version and embedded library code like ours that
ends up getting embedded in every version of everything. It just totally
changes the meaning and impact of dependencies.
I agree that the integrations are nice, but JMX is far and away the most common
monitoring for java apps and is, if anything, better supported than the yammer
metrics apis as a system for getting values out of apps. There is integration
for every major metrics system. So I don't think we need to ship a ton of
integrations. People who want something off the shelf can use JMX integration,
and people who want to do something custom can plug in.
We need a windowed counter implementation for quotas in any case, which has
very particular requirements to do right, so I suspect we would end up
reinventing for that in any case.
I also think the current metrics code is better in a number of technical ways
but I guess that may be a side-effect of having written it. In any case, the
primary argument I think would be to pull up the metrics in jconsole for the
old producer and for the new producer and compare what you get.
> Move server over to new metrics library
> ---------------------------------------
>
> Key: KAFKA-1930
> URL: https://issues.apache.org/jira/browse/KAFKA-1930
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jay Kreps
>
> We are using org.apache.kafka.common.metrics on the clients, but using Coda
> Hale metrics on the server. We should move the server over to the new metrics
> package as well. This will help to make all our metrics self-documenting.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
