Kafka monitoring integration

The New Relic Kafka on-host integration reports metrics and configuration data from your Kafka service. We instrument all the key elements of your cluster, including brokers (both ZooKeeper and Bootstrap), producers, consumers, and topics.

Read on to install the Kafka integration, and to see what data it collects. To monitor Kafka with our Java agent, see Instrument Kafka message queues.

Compatibility and requirements

Our integration is compatible with Kafka versions 0.8 or higher.

Before installing the integration, make sure that you meet the following requirements:

• If Kafka is not running on Kubernetes or Amazon ECS, you must install the infrastructure agent on a host that's running Kafka. Otherwise:
  • If running on Kubernetes, see these requirements.
  • If running on ECS, see these requirements.
• Java 8 or higher
• JMX enabled on all brokers
• Java-based consumers and producers only, and with JMX enabled
• Total number of monitored topics must be fewer than 300

For Kafka running on Kubernetes, see the Kubernetes requirements.

Prepare for the installation

Kafka is a complex piece of software that is built as a distributed system. For this reason, you’ll need to ensure that the integration can contact all the required hosts and services so the data is collected correctly.

Autodiscovery

Given the distributed nature of Kafka, the actual number and list of brokers is usually not fixed by the configuration, and it is instead quite dynamic. For this reason, the Kafka integration offers two mechanisms to perform automatic discovery of the list of brokers in the cluster: Bootstrap and Zookeeper. The mechanism you use depends on the setup of the Kafka cluster being monitored.

Bootstrap

With the bootstrap mechanism, the integration uses a bootstrap broker to perform the autodiscovery. This is a broker whose address is well known and that will be asked for any other brokers it is aware of. The integration needs to be able to contact this broker in the address provided in the bootstrap_broker_host parameter for bootstrap discovery to work.

Zookeeper

Alternatively, the Kafta integration can also talk to a Zookeeper server in order to obtain the list of brokers. To do this, the integration needs to be provided with the following:

• The list of Zookeeper hosts to contact (zookeeper_hosts).
• The proper authentication secrets to connect with the hosts.

Together with the list of brokers it knows about, Zookeeper will also advertise which connection mechanisms are supported by each broker.

You can configure the Kafka integration to try directly with one of these mechanisms with the preferred_listener parameter. If this parameter is not provided, the integration will try to contact the brokers with all the advertised configurations until one of them succeeds.

Topic listing

To correctly list the topics processed by the brokers, the integration needs to to contact brokers over the Kafka protocol. Depending on how the brokers are configured, this might require setting up SSL and/or SASL to match the broker configuration.

Broker monitoring (JMX)

The Kafka integration queries JMX, a standard Java extension for exchanging metrics in Java applications. JMX is not enabled by default in Kafka brokers, and you need to enable it for metrics collection to work properly. JMX requires RMI to be enabled, and the RMI port needs to be set to the same port as JMX.

You can configure JMX to use username/password authentication, as well as SSL. If such features have been enabled in the broker's JMX settings, you need to configure the integration accordingly.

Producer/consumer monitoring (JMX)

Producers and consumers written in Java can also be monitored through the same mechanism (JMX). JMX needs to be enabled and configured on those applications where it is not enabled by default.

Non-Java producers and consumers do not support JMX and are therefore not supported by the Kafka integration.

Connectivity requirements

As a summary, the integration needs to be configured and allowed to connect to:

• Hosts listed in zookeeper_hosts over the Zookeeper protocol, using the Zookeeper authentication mechanism (if autodiscover_strategy is set to zookeeper).
• Hosts defined in bootstrap_broker_host over the Kafka protocol, using the Kafka broker’s authentication/transport mechanisms (if autodiscover_strategy is set to bootstrap).
• All brokers in the cluster over the Kafka protocol and port, using the Kafka brokers' authentication/transport mechanisms.
• All brokers in the cluster over the JMX protocol and port, using the authentication/transport mechanisms specified in the JMX configuration of the brokers.
• All producers/consumers specified in producers and consumers over the JMX protocol and port, if you want producer/consumer monitoring. JMX settings for the consumer must be the same as for the brokers.

Install and activate

To install the Kafka integration, choose your setup:

Additional notes:

• Advanced: It's also possible to install the integration from a tarball file. This gives you full control over the installation and configuration process.
• On-host integrations do not automatically update. For best results, regularly update the integration package and the infrastructure agent.

Configure the integration

An integration's YAML-format configuration is where you can place required login credentials and configure how data is collected. Which options you change depend on your setup and preference. The entire environment can be monitored remotely or on any node in that environment.

There are several ways to configure the integration, depending on how it was installed:

• If enabled via Kubernetes: see Monitor services running on Kubernetes.
• If enabled via Amazon ECS: see Monitor services running on ECS.
• If installed on-host: edit the config in the integration's YAML config file, kafka-config.yml.

For examples of typical configurations, see the example configurations.

Commands

The configuration accepts the following commands:

• inventory: collects configuration status
• metrics: collects performance metrics
• consumer_offset: collects consumer group offset data

Arguments

The configuration accepts the following arguments:

General arguments:

• cluster_name: user-defined name to uniquely identify the cluster being monitored. Required.
• kafka_version: the version of the Kafka broker you're connecting to, used for setting optimum API versions. Defaults to 1.0.0. Versions older than 1.0.0 may be missing some features.
• autodiscover_strategy: the method of discovering brokers. Options are zookeeper or bootstrap. Defaults to zookeeper

Zookeeper autodiscovery arguments (only relevant when autodiscover_strategy is zookeeper):

• zookeeper_hosts: the list of Apache ZooKeeper hosts (in JSON format) that need to be connected.
• zookeeper_auth_scheme: the ZooKeeper authentication scheme that is used to connect. Currently, the only supported value is digest. If omitted, no authentication is used.
• zookeeper_auth_secret: the ZooKeeper authentication secret that is used to connect. Should be of the form username:password. Only required if zookeeper_auth_scheme is specified.
• zookeeper_path: the Zookeeper node under which the Kafka configuration resides. Defaults to /.
• preferred_listener: use a specific listener to connect to a broker. If unset, the first listener that passes a successful test connection is used. Supported values are PLAINTEXT, SASL_PLAINTEXT, SSL, and SASL_SSL. Note: The SASL_* protocols only support Kerberos (GSSAPI) authentication.

Bootstrap broker discovery arguments (only relevant when autodiscover_strategy is bootstrap):

• bootstrap_broker_host: the host for the bootstrap broker.
• bootstrap_broker_kafka_port: the Kafka port for the bootstrap broker.
• bootstrap_broker_kafka_protocol: the protocol to use to connect to the bootstrap broker. Supported values are PLAINTEXT, SASL_PLAINTEXT, SSL, and SASL_SSL. Note: The SASL_* protocols only support Kerberos (GSSAPI) authentication. Default: PLAINTEXT.
• bootstrap_broker_jmx_port: the JMX port to use for collection.
• bootstrap_broker_jmx_user: the JMX user to use for collection.
• bootstrap_broker_jmx_password: the JMX password to use for collection.

Producer and consumer collection:

• producers: producers to collect. For each provider a name, hostname, port, username, and password can be provided in JSON form. name is the producer’s name as it appears in Kafka. hostname, port, username, and password are optional and use the default if unspecified.
• consumers: consumers to collect. For each consumer a name, hostname, port, username, and password can be specified in JSON form. name is the consumer’s name as it appears in Kafka. hostname, port, username, and password are optional and use the default if unspecified.

JMX connection options:

• default_jmx_host: the default host to collect JMX metrics. If the host field is omitted from a producer or consumer configuration, this value will be used.
• default_jmx_port: the default port to collect JMX metrics. If the port field is omitted from a producer or consumer configuration, this value will be used.
• default_jmx_user: the default user that is connecting to the JMX host to collect metrics. This field should only be used if all brokers have a non-default username. If the username field is omitted from a producer or consumer configuration, this value will be used.
• default_jmx_password: the default password to connect to the JMX host. This field should only be used if all brokers have a non-default password. If the password field is omitted from a producer or consumer configuration, this value will be used.
• key_store: the filepath of the keystore containing the JMX client's SSL certificate.
• key_store_password: the password for the JMX SSL key store.
• trust_store: the filepath of the trust keystore containing the JMX server's SSL certificate.
• trust_store_password: the password for the JMX trust store.
• timeout: the timeout for individual JMX queries in milliseconds. Default: 10000.

Broker connection options:

• tls_ca_file: the certificate authority file for SSL and SASL_SSL listeners, in PEM format.
• tls_cert_file: the client certificate file for SSL and SASL_SSL listeners, in PEM format.
• tls_key_file: the client key file for SSL and SASL_SSL listeners, in PEM format.
• tls_insecure_skip_verify: skip verifying the server's certificate chain and host name
• sasl_mechanism: the type of SASL authentication to use. Supported options are SCRAM-SHA-512, SCRAM-SHA-256, PLAIN, and GSSAPI.
• sasl_gssapi_realm: kerberos realm. Required for SASL_SSL or SASL_PLAINTEXT
• sasl_gssapi_service_name: kerberos service name. Required for SASL_SSL or SASL_PLAINTEXT
• sasl_gssapi_username: kerberos username. Required for SASL_SSL or SASL_PLAINTEXT
• sasl_gssapi_key_tab_path: path to the kerberos keytab. Required for SASL_SSL or SASL_PLAINTEXT
• sasl_gssapi_kerberos_config_path: path to the kerberos config file. Default: /etc/krb5.conf

Collection filtering:

• collect_broker_topic_data: signals if broker and topic metrics are collected. Options are true or false, defaults to true. Should only be set to false when monitoring only producers and consumers, and topic_mode is set to all.
• local_only_collection: collect only the metrics related to the configured bootstrap broker. Only used if autodiscover_strategy is bootstrap. Default: false
• consumer_group_regex: regex pattern that matches the consumer groups to collect offset statistics for. This is limited to collecting statistics for 300 consumer groups. Note: consumer_groups has been deprecated, use this argument instead.
• topic_mode: determines how many topics we collect. Options are all, none, list, or regex.
• collect_topic_size: collect the metric Topic size. Options are true or false, defaults to false. topic_size is a resource-intensive metric to collect.
• topic_list: array of topic names to monitor. Only in effect if topic_mode is set to list.
• topic_regex: regex pattern that matches the topic names to monitor. Only in effect if topic_mode is set to regex.
• topic_bucket: used to split topic collection across multiple instances. Should be of the form <bucket number>/<number of buckets>. Default: 1/1.

Labels

Labels are optional tags which help to identify collection data. Some examples are included below.

• env: label to identify the environment. For example: production.
• role: label to identify which role is accessing the data.

Example configuration

integration_name: com.newrelic.kafka
instances:
  - name: kafka-metrics
    command: metrics
    arguments:
      zookeeper_hosts: '[{"host": "localhost", "port": 2181}]'
      producers: '[{"name": "my-producer", "host": "my-producer.my.localnet", "port": 9989}]'
      consumers: '[{"name": "my-consumer", "host": "my-consumer.my.localnet", "port": 9987}]'
      topic_mode: List
      collect_topic_size: false
      topic_list: '["topic_1", "topic_2"]'
    labels:
      env: production
      role: kafka
  - name: kafka-inventory
    command: inventory
    arguments:
      zookeeper_hosts: '[{"host": "localhost", "port": 2181}]'
      topic_mode: Regex
      topic_regex: 'topic_[0-9]+'
    labels:
      env: production
      role: kafka

integration_name: com.newrelic.kafka
instances:
  - name: kafka-metrics
    command: metrics
    arguments:
      zookeeper_hosts: '[{"host": "localhost", "port": 2181}]'
      topic_mode: List
      collect_topic_size: false
      topic_list: '["topic_1", "topic_2"]'
    labels:
      env: production
      role: kafka
  - name: kafka-inventory
    command: inventory
    arguments:
      zookeeper_hosts: '[{"host": "localhost", "port": 2181}]'
      topic_mode: List
      topic_list: '["topic_1", "topic_2"]'
    labels:
      env: production
      role: kafka

integration_name: com.newrelic.kafka
instances:
  - name: kafka-metrics
    command: metrics
    arguments:
      producers: '[{"name": "my-producer", "host": "my-producer.my.localnet", "port": 9989}]'
      topic_mode: List
      topic_list: '["topic_1", "topic_2"]'
    labels:
      env: production
      role: kafka

integration_name: com.newrelic.kafka
instances:
  - name: kafka-metrics
    command: metrics
    arguments:
      consumers: '[{"name": "my-consumer", "host": "my-consumer.my.localnet", "port": 9987}]'
      topic_mode: List
      topic_list: '["topic_1", "topic_2"]'
    labels:
      env: production
      role: kafka

integration_name: com.newrelic.kafka
- name: kafka-consumer-offsets
  command: consumer_offset
  arguments:
    zookeeper_hosts: '[{"host": "localhost", "port": 2181}]'
    consumer_group_regex: 'consumer_group_a.'
  labels:
    env: production
    role: kafka

For more about the general structure of on-host integration configuration, see Configuration.

Find and use data

Data from this service is reported to an integration dashboard.

Kafka data is attached to the following event types:

• KafkaBrokerSample
• KafkaTopicSample
• KafkaProducerSample
• KafkaConsumerSample
• KafkaOffsetSample

You can query this data for troubleshooting purposes or to create charts and dashboards.

For more on how to find and use your data, see Understand integration data.

Metric data

The Kafka integration collects the following metric data attributes. Each metric name is prefixed with a category indicator and a period, such as broker. or consumer..

KafkaBrokerSample event

KafkaConsumerSample event

KafkaProducerSample event

KafkaTopicSample event

KafkaOffsetSample event

Inventory data

The Kafka integration captures the non-default broker and topic configuration parameters, and collects the topic partition schemes as reported by ZooKeeper. The data is available on the Inventory UI page under the config/kafka source.

Troubleshooting

Troubleshooting tips:

$ echo ":" | nrjmx -hostname HOSTNAME -port PORT -v -username USERNAME -password PASSWORD

KRB Error: (6) KDC_ERR_C_PRINCIPAL_UNKNOWN Client not found in Kerberos database

$ kinit -k -t KEY_TAB_PATH USERNAME

$ klist |grep "Default principal:"

Default principal: johndoe@a_realm_name

Check the source code

This integration is open source software. That means you can browse its source code and send improvements or create your own fork and build it.