Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-4982: add listener tags to socket-server-metrics #3004

Closed
wants to merge 5 commits into from

Conversation

edoardocomar
Copy link
Contributor

Added tags

@asfbot
Copy link

asfbot commented May 9, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/3693/
Test PASSed (JDK 8 and Scala 2.11).

@asfbot
Copy link

asfbot commented May 9, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3683/
Test FAILed (JDK 8 and Scala 2.12).

@asfbot
Copy link

asfbot commented May 9, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.10/3687/
Test PASSed (JDK 7 and Scala 2.10).

@asfbot
Copy link

asfbot commented May 10, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3707/
Test FAILed (JDK 8 and Scala 2.12).

@asfbot
Copy link

asfbot commented May 10, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.11/3717/
Test PASSed (JDK 8 and Scala 2.11).

@asfbot
Copy link

asfbot commented May 10, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.10/3711/
Test PASSed (JDK 7 and Scala 2.10).

Copy link
Contributor

@ijuma ijuma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, seems fine, just left some minor comments. Can we write a simple test?

@@ -400,7 +398,7 @@ private[kafka] class Processor(val id: Int,

private val newConnections = new ConcurrentLinkedQueue[SocketChannel]()
private val inflightResponses = mutable.Map[String, RequestChannel.Response]()
private val metricTags = Map("networkProcessor" -> id.toString).asJava
val metricTags = Map("protocol" -> securityProtocol.name, "listener" -> listenerName.value, "networkProcessor" -> id.toString).asJava
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is a bit long.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@@ -105,9 +99,13 @@ class SocketServer(val config: KafkaConfig, val metrics: Metrics, val time: Time
}
}

val allIoWaitRatioMetricNames = processors.map { p =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably move this to inside the Gauge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point

@asfbot
Copy link

asfbot commented May 11, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/3766/
Test FAILed (JDK 7 and Scala 2.11).

@asfbot
Copy link

asfbot commented May 11, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3756/
Test FAILed (JDK 8 and Scala 2.12).

@asfbot
Copy link

asfbot commented May 11, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/3771/
Test PASSed (JDK 7 and Scala 2.11).

@asfbot
Copy link

asfbot commented May 11, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3761/
Test PASSed (JDK 8 and Scala 2.12).

private val metricTags = Map("networkProcessor" -> id.toString).asJava
val metricTags = Map(
"protocol" -> securityProtocol.name, "listener" -> listenerName.value, "networkProcessor" -> id.toString
).asJava

newGauge("IdlePercent",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The KIP simply mentions SelectorMetrics (in Kafka Metrics), but you have also changed the tags for IdlePercent which is a Yammer Metric. Is that intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it was intentional, as "io-wait-ratio" is still a per-network-thread metric and JConsole was grouping it with KafkaMetrics, so I didn't spot it coming from a different registry.
IMHO it would look too odd to leave that just tagged with the processor thread number. I'll clarify the KIP

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to update the compatibility section too. @junrao, is this OK?

Copy link
Contributor

@ijuma ijuma May 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edoardocomar I had a closer look and I think you misunderstood the issue. io-wait-ratio is a Selector metric. The issue that I'm raising is with regards to IdlePercent:

newGauge("IdlePercent",
  new Gauge[Double] {
       def value = {
         Option(metrics.metric(metrics.metricName("io-wait-ratio", "socket-server-metrics", metricTags))).fold(0.0)(_.value)
       }
     },
     metricTags.asScala

See the metricTags passed to it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, got it !
image

It's still a per-network-processor-thread metric. That's why the coding was intentional,
though I did not notice the new MBeanName surfacing in a different place.

I prefer the tagging, but I still could live without it here and maintain compatibility.
Please advise, @ijuma @junrao

Copy link
Contributor

@ijuma ijuma May 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You didn't do the same for NetworkProcessorAvgIdlePercent though. My preference would be to leave the Yammer metrics alone and just add the tags to the underlying SelectorMetrics, but worth waiting for @junrao's opinion.

Edit: NetworkProcessorAvgIdlePercent is not per network process, so that's OK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ijuma On second thought, as the (per-processor) IdlePercent is an alias to the (per-processor) io-wait-ratio we could leave the former unchanged for compatibility. And do the multilevel tagging only in the latter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was my suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jun also agreed that we should just add the new tag to the SelectorMetrics.


assertEquals(2, metricsNames.size)
assert(metricsNames.head.getMBeanName.endsWith("protocol=PLAINTEXT,listener=PLAINTEXT,networkProcessor=0"))
assert(metricsNames.last.getMBeanName.endsWith("protocol=TRACE,listener=TRACE,networkProcessor=1"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Kafka, we typically call it a security protocol, not just a protocol. The latter is clearly more concise though. @junrao, do you think protocol is OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as below we agreed to remove it, leaving only the listener tag

private val metricTags = Map("networkProcessor" -> id.toString).asJava
val metricTags = Map(
"protocol" -> securityProtocol.name, "listener" -> listenerName.value, "networkProcessor" -> id.toString
).asJava
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the JMX screenshot, the order is important, so you should use a LinkedHashMap. Also, it seems like listener should be the first entry as it uniquely identifies the listener.

Copy link
Contributor Author

@edoardocomar edoardocomar May 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the protocol as first one, as when using a treeview representation, allows for the listeners to be shown as children.
In fact, protocol/listener/networkProcessor is the order from the most generic to the most specific tag.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true. I guess the ideal scenario in my mind would be to just have two levels: listener name and network processor. And the security protocol would be an attribute value. However, I'm not sure how easy it is to do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could omit the securityProtocol altogether. Although that's another deviation from the KIP, as you say the listener is the main differentiator.
I started from the need to distinguish between metrics, but in our setup we have no listener labels, just protocols. That's why we initially came up with a 3-level tagging

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't find a way to add a string value ... that could be a future enhancement ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's just remove the security protocol algother. Synced with Jun and he agrees that this is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@ijuma
Copy link
Contributor

ijuma commented May 12, 2017

Do you think you'll be able to update the PR today? If so, we can probably get it merged today.

removed protol tag, 
left yammer metric with older tagging
@edoardocomar
Copy link
Contributor Author

Thanks for the detailed feedback. I've updated the PR

@edoardocomar edoardocomar changed the title KAFKA-4982: add protocol and listener tags to socket-server-metrics KAFKA-4982: add listener tags to socket-server-metrics May 12, 2017
@asfbot
Copy link

asfbot commented May 12, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/3828/
Test FAILed (JDK 7 and Scala 2.11).

@asfbot
Copy link

asfbot commented May 12, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/3816/
Test PASSed (JDK 8 and Scala 2.12).

Copy link
Contributor

@ijuma ijuma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I included a couple of minor changes as described below before merging.

@@ -400,15 +398,16 @@ private[kafka] class Processor(val id: Int,

private val newConnections = new ConcurrentLinkedQueue[SocketChannel]()
private val inflightResponses = mutable.Map[String, RequestChannel.Response]()
private val metricTags = Map("networkProcessor" -> id.toString).asJava
val metricTags = SortedMap("listener" -> listenerName.value, "networkProcessor" -> id.toString).asJava
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A LinkedHashMap is better because it makes it obvious that the order of declaration is important. With a SortedMap, adding a third key could change the order.

assertFalse(kafkaMetricNames.isEmpty)
val expectedListeners = Set("PLAINTEXT","TRACE")
kafkaMetricNames.foreach { kafkaMetricName => {
System.err.println(kafkaMetricName.tags)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was probably not intentional.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops thanks for spotting. Shame syserr/syout are't caught by something akin to a findbugs for Scala

@asfgit asfgit closed this in f21f8f2 May 13, 2017
@edoardocomar edoardocomar deleted the KAFKA-4982 branch May 15, 2017 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants