Configuration best practices in Kafka - Commands & Configuration

Introduction

Kafka needs careful setup to run smoothly and handle data well. Good configuration helps avoid crashes, data loss, and slow performance.

When setting up a new Kafka broker to handle message streaming reliably.

When tuning Kafka to handle more users or higher message volumes without delays.

When securing Kafka so only allowed users can send or read messages.

When you want to keep Kafka logs and data safe even if a server fails.

When you need to balance performance and resource use on your Kafka servers.

Config File - server.properties

server.properties

broker.id=1
listeners=PLAINTEXT://:9092
log.dirs=/var/lib/kafka-logs
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=localhost:2181
num.partitions=3
auto.create.topics.enable=false
log.cleaner.enable=true
log.cleaner.threads=2
log.cleaner.dedupe.buffer.size=134217728
log.cleaner.io.max.bytes.per.second=1048576
log.cleaner.backoff.ms=15000

broker.id: Unique ID for each Kafka broker.

listeners: Network address Kafka listens on.

log.dirs: Where Kafka stores data logs.

num.network.threads and num.io.threads: Threads for handling network and disk I/O.

socket.*: Buffer sizes for network communication.

log.retention.hours: How long logs are kept before deletion.

log.segment.bytes: Size of each log file segment.

zookeeper.connect: Address of ZooKeeper managing Kafka cluster.

num.partitions: Default number of partitions per topic.

auto.create.topics.enable: Prevents automatic topic creation to avoid mistakes.

log.cleaner.*: Settings for log compaction to save space and keep latest data.

Commands

Starts the Kafka broker using the configuration file to apply all settings.

Terminal

kafka-server-start.sh /opt/kafka/config/server.properties

Expected Output

[2024-06-01 12:00:00,000] INFO Kafka version : 3.5.0 (org.apache.kafka.common.utils.AppInfoParser)

[2024-06-01 12:00:00,001] INFO Kafka startTimeMs : 1685611200000 (org.apache.kafka.common.utils.AppInfoParser)

[2024-06-01 12:00:01,500] INFO [KafkaServer id=1] started (kafka.server.KafkaServer)

Lists all topics on the Kafka broker to verify it is running and topics are managed correctly.

Terminal

kafka-topics.sh --bootstrap-server localhost:9092 --list

Expected Output

example-topic

user-events

system-logs

→

--bootstrap-server - Specifies the Kafka server address to connect to.

Shows the current configuration of the Kafka broker with ID 1 to check applied settings.

Terminal

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 1 --describe

Expected Output

Configs for broker 1 are:

  log.retention.hours=168

  num.partitions=3

  auto.create.topics.enable=false

  log.cleaner.enable=true

→

--entity-type - Defines the type of entity to describe, here a broker.

→

--entity-name - Specifies the broker ID to show configuration for.

Key Concept

If you remember nothing else from this pattern, remember: carefully setting Kafka's configuration file ensures reliable, secure, and efficient message streaming.

Common Mistakes

Leaving auto.create.topics.enable set to true in production.

It can create unwanted topics automatically, causing confusion and resource waste.

Set auto.create.topics.enable=false to control topic creation explicitly.

Not setting unique broker.id for each Kafka broker.

Kafka brokers must have unique IDs or they will conflict and fail to start properly.

Assign a unique broker.id number to each broker in the cluster.

Using default log retention without adjusting for data needs.

Logs may fill disk space too quickly or be deleted too soon, risking data loss or downtime.

Adjust log.retention.hours and log.segment.bytes based on your data volume and storage capacity.

Summary

Create and edit the server.properties file to set Kafka broker settings.

Start the Kafka broker with kafka-server-start.sh using the config file.

Verify topics and broker configuration with kafka-topics.sh and kafka-configs.sh commands.

Practice

1. Which of the following is a key benefit of following Kafka configuration best practices?

easy

A. Allows Kafka to run without any network connection

B. Automatic code generation for Kafka producers

C. Eliminates the need for monitoring Kafka brokers

D. Improved speed, safety, and reliability of Kafka clusters

Solution

1. Step 1: Understand Kafka configuration goals

   Kafka configs are designed to improve performance, safety, and reliability.

2. Step 2: Evaluate each option

   Only Improved speed, safety, and reliability of Kafka clusters correctly states the benefits of good Kafka configs.

3. Final Answer:

   Improved speed, safety, and reliability of Kafka clusters -> Option D

4. Quick Check:

   Kafka config benefits = Improved speed, safety, reliability [OK]

Hint: Remember: good configs make Kafka faster and safer [OK]

Common Mistakes:

• Thinking configs generate code automatically
• Assuming configs remove need for monitoring
• Believing Kafka works offline without network

2. Which of the following is the correct syntax to set a Kafka configuration property in a properties file?

easy

A. bootstrap.servers = localhost:9092

B. bootstrap.servers: localhost:9092

C. bootstrap.servers -> localhost:9092

D. bootstrap.servers localhost:9092

Solution

1. Step 1: Recall Kafka config file syntax

   Kafka uses key=value pairs in properties files.

2. Step 2: Match syntax to options

   Only bootstrap.servers = localhost:9092 uses the correct key=value format.

3. Final Answer:

   bootstrap.servers = localhost:9092 -> Option A

4. Quick Check:

   Kafka config syntax = key=value [OK]

Hint: Kafka configs use key=value pairs, not colons or arrows [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using arrow symbols
• Omitting the equals sign

3. Given the following Kafka producer configuration snippet, what will be the value of acks used by the producer?

acks=all
retries=3
linger.ms=5

medium

A. "all" meaning the leader waits for all replicas to acknowledge

B. "0" meaning no acknowledgments are required

C. "1" meaning only the leader acknowledges

D. An error because "all" is not a valid value

Solution

1. Step 1: Understand the meaning of acks=all

   In Kafka, acks=all means leader waits for all replicas to confirm the message.

2. Step 2: Check options against this meaning

   "all" meaning the leader waits for all replicas to acknowledge correctly describes acks=all behavior.

3. Final Answer:

   "all" meaning the leader waits for all replicas to acknowledge -> Option A

4. Quick Check:

   acks=all means wait for all replicas [OK]

Hint: Remember: acks=all waits for all replicas to confirm [OK]

Common Mistakes:

• Confusing acks=all with acks=0 or acks=1
• Thinking 'all' is invalid
• Assuming no acknowledgments are needed

4. You have set log.retention.hours=168 in your Kafka broker config, but logs are not retained for 7 days as expected. What is a likely cause?

medium

A. The log.retention.hours value must be set in minutes

B. The log.retention.bytes setting is limiting retention by size

C. Kafka does not support retention configuration

D. The broker needs to be restarted for changes to take effect

Solution

1. Step 1: Understand retention config interaction

   Kafka retention can be limited by time or size; size limit can override time.

2. Step 2: Analyze options

   The log.retention.bytes setting is limiting retention by size correctly identifies size limit as a possible cause.

3. Final Answer:

   The log.retention.bytes setting is limiting retention by size -> Option B

4. Quick Check:

   Retention limited by size overrides time [OK]

Hint: Check size limits when time-based retention seems ignored [OK]

Common Mistakes:

• Assuming retention.hours must be in minutes
• Believing Kafka ignores retention settings
• Forgetting to restart broker (not always needed)

5. You want to safely update Kafka broker configurations without downtime. Which approach follows best practices?

hard

A. Update configs on all brokers simultaneously and restart all at once

B. Stop the entire Kafka cluster, update configs, then restart all brokers

C. Update configs on one broker at a time, restart it, then move to next

D. Change configs dynamically without any restarts or backups

Solution

1. Step 1: Understand safe config update practices

   Updating one broker at a time avoids cluster downtime and data loss.

2. Step 2: Evaluate options for safety and availability

   Update configs on one broker at a time, restart it, then move to next follows the best practice of rolling updates with restarts.

3. Final Answer:

   Update configs on one broker at a time, restart it, then move to next -> Option C

4. Quick Check:

   Rolling updates = safer config changes [OK]

Hint: Update brokers one by one to avoid downtime [OK]

Common Mistakes:

• Restarting all brokers simultaneously causing downtime
• Stopping entire cluster unnecessarily
• Changing configs without backups or restarts