You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Status

Current state: "Under Discussion"

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: KAFKA-4982 [Change the link from KAFKA-1 to your own ticket]

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

SelectorMetrics like socket-server-metrics.connection-count,  socket-server-metrics.connection-close-rate etc are tagged with networkProcessor:<id> where the id of a network processor is just a numeric integer.

If you have more than one listener (eg PLAINTEXT, SASL_SSL, etc.), the id just keeps incrementing and when looking at the metrics it is hard to match the metric tag to a listener.

You need to know the number of network threads and the order in which the listeners are declared in the brokers' server.properties to properly aggregate per protocol.

On the broker side only - where multiple security protocol can coexist - 
we should add a tag showing the listener label, that would also make it much easier to group the metrics in a tool like Grafana.

 

This KIP is co-authored with Mickael Maison

Public Interfaces

  • Monitoring

The metrics in the socket-server-metrics group  will gain two new entries in their tags map, Security Protocol name and the Listener name

Proposed Changes

Example representation of the metrics in JConsole :

Current tag set : network processor id only

Proposed tag set : security protocol, listener name, network processor id


The listener tag could be omitted if it is the same as the protocol one :

 

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?

    Users currently using reporters that do not support metric tags and flatten the tags map into the metrics name, will find that the name has changed
  • The socket-server-metrics.* are not exposed as Yammer metrics which are still the most commonly consumed server-side metrics, so the impact of this change is mitigated (thanks Ismael Juma Juma)

Rejected Alternatives

 

  • No labels