Client metrics monitoring in Kafka - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start the Kafka consumer with the correct group ID.

Kafka

kafka-console-consumer --bootstrap-server localhost:9092 --topic metrics --group [1]

Drag options to blanks, or click blank then click option'

Aconsumer-1

Bmetrics-group

Cgroup-0

Ddefault

Attempts:

3 left

💡 Hint

Common Mistakes

Using an invalid or empty group ID causes the consumer to fail.

Confusing topic name with group ID.

The --group option sets the consumer group ID. Here, consumer-1 is the correct group name to start consuming metrics.

2fill in blank

medium

Complete the command to produce a JSON metric message to the Kafka topic.

Kafka

echo '{"metric":"cpu_usage","value":75}' | kafka-console-producer --bootstrap-server localhost:9092 --topic [1]

Drag options to blanks, or click blank then click option'

Ametrics

Balerts

Cevents

Dlogs

Attempts:

3 left

💡 Hint

Common Mistakes

Sending metrics to the wrong topic causes data loss.

Misspelling the topic name.

The --topic option specifies the Kafka topic to send messages to. Here, metrics is the correct topic for client metrics.

3fill in blank

hard

Fix the error in the consumer command to correctly read from the beginning of the topic.

Kafka

kafka-console-consumer --bootstrap-server localhost:9092 --topic metrics --group consumer-1 --[1]

Drag options to blanks, or click blank then click option'

Astart-from-beginning

Bfrom-beginning

Cread-from-start

Dconsume-all

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect flag names causes the consumer to fail.

Omitting the flag reads only new messages.

The correct option to read all messages from the start is --from-beginning. Other options are invalid and cause errors.

4fill in blank

hard

Fill both blanks to configure the Kafka consumer to use a specific offset reset policy and enable auto commit.

Kafka

kafka-console-consumer --bootstrap-server localhost:9092 --topic metrics --group consumer-2 --consumer-property auto.offset.reset=[1] --consumer-property enable.auto.commit=[2]

Drag options to blanks, or click blank then click option'

Aearliest

Blatest

Ctrue

Dfalse

Attempts:

3 left

💡 Hint

Common Mistakes

Setting offset reset to latest misses old messages.

Disabling auto commit causes manual offset management.

The auto.offset.reset should be set to earliest to start from the beginning if no offset is found. The enable.auto.commit should be true to commit offsets automatically.

5fill in blank

hard

Fill all three blanks to create a Kafka topic with 3 partitions, replication factor 2, and a retention time of 7 days.

Kafka

kafka-topics --create --bootstrap-server localhost:9092 --topic client-metrics --partitions [1] --replication-factor [2] --config retention.ms=[3]

Drag options to blanks, or click blank then click option'

A3

B2

C604800000

D86400000

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect retention time causes data to expire too soon or never.

Setting replication factor higher than cluster size causes errors.

Partitions should be 3, replication factor 2 for fault tolerance, and retention time set to 7 days in milliseconds (7*24*60*60*1000 = 604800000).

Practice

1. What is the main purpose of client metrics monitoring in Kafka?

easy

A. To configure Kafka brokers for better storage

B. To track real-time performance data like message counts and errors

C. To manage user access permissions

D. To backup Kafka data automatically

Solution

1. Step 1: Understand client metrics monitoring

   Client metrics monitoring collects data about Kafka client performance such as message counts, latency, and errors.

2. Step 2: Identify the main purpose

   The main goal is to observe client behavior in real time to improve reliability and troubleshoot issues quickly.

3. Final Answer:

   To track real-time performance data like message counts and errors -> Option B

4. Quick Check:

   Client metrics = performance data tracking [OK]

Hint: Client metrics = real-time client performance data [OK]

Common Mistakes:

• Confusing client metrics with broker configuration
• Thinking metrics manage user permissions
• Assuming metrics handle data backup

2. Which of the following is the correct way to enable client metrics reporting in a Kafka producer configuration?

easy

A. "client.metrics.enabled=yes"

B. "enable.metrics=true"

C. "metrics.recording.level=DEBUG"

D. "metrics.sample.window.ms=30000"

Solution

1. Step 1: Review Kafka producer metric configs

   Kafka uses properties like "metrics.sample.window.ms" to control metrics sampling intervals.

2. Step 2: Identify valid configuration syntax

   "metrics.sample.window.ms=30000" is a valid setting to enable metrics sampling every 30 seconds.

3. Final Answer:

   "metrics.sample.window.ms=30000" -> Option D

4. Quick Check:

   Correct metric config syntax = "metrics.sample.window.ms=30000" [OK]

Hint: Look for valid Kafka metric property names [OK]

Common Mistakes:

• Using non-existent properties like enable.metrics
• Wrong boolean values like 'yes' instead of true/false
• Confusing logging level with metrics config

3. Given the following Kafka consumer metrics output snippet:
{"records-consumed-total": 1500, "fetch-latency-avg": 25, "fetch-errors-total": 0}
What does this tell you about the consumer's performance?

medium

A. The consumer has consumed 1500 records with an average fetch latency of 25 ms and no fetch errors

B. The consumer has 1500 fetch errors and average latency of 0 ms

C. The consumer has not consumed any records yet

D. The consumer is experiencing high fetch errors

Solution

1. Step 1: Interpret each metric value

   "records-consumed-total": 1500 means 1500 messages consumed; "fetch-latency-avg": 25 means average fetch latency is 25 milliseconds; "fetch-errors-total": 0 means no fetch errors.

2. Step 2: Summarize consumer performance

   The consumer is working well, consuming messages with reasonable latency and no errors.

3. Final Answer:

   The consumer has consumed 1500 records with an average fetch latency of 25 ms and no fetch errors -> Option A

4. Quick Check:

   Metrics values = The consumer has consumed 1500 records with an average fetch latency of 25 ms and no fetch errors [OK]

Hint: Check counts and latency values carefully [OK]

Common Mistakes:

• Misreading zero errors as errors present
• Confusing latency with error count
• Assuming no records consumed when count is positive

4. You configured Kafka client metrics but see no metrics reported. Which of the following is the most likely cause?

medium

A. Metrics reporting interval is set too high, delaying output

B. Kafka broker is down

C. Client metrics are disabled by default and need explicit enabling

D. Network firewall blocking Kafka ports

Solution

1. Step 1: Understand default client metrics behavior

   Kafka clients do not always enable metrics reporting by default; explicit configuration is often required.

2. Step 2: Evaluate other options

   Broker down or firewall issues affect connectivity but not metrics reporting directly; reporting interval delays metrics but does not stop them completely.

3. Final Answer:

   Client metrics are disabled by default and need explicit enabling -> Option C

4. Quick Check:

   Metrics disabled by default = Client metrics are disabled by default and need explicit enabling [OK]

Hint: Check if metrics are explicitly enabled in config [OK]

Common Mistakes:

• Assuming broker status affects client metrics directly
• Ignoring need to enable metrics explicitly
• Blaming network issues without checking configs

5. You want to monitor Kafka producer client metrics to detect high message send latency and errors in real time. Which approach is best to achieve this?

hard

A. Configure the producer to expose JMX metrics and use a monitoring tool to collect and alert on latency and error metrics

B. Increase the producer batch size to reduce latency

C. Enable debug logging on the Kafka broker

D. Use Kafka Connect to export metrics to a database

Solution

1. Step 1: Identify how to access client metrics

   Kafka producer clients expose metrics via JMX (Java Management Extensions), which can be collected by monitoring tools.

2. Step 2: Choose the best monitoring approach

   Using JMX with a monitoring tool allows real-time collection and alerting on latency and errors, which fits the requirement.

3. Step 3: Evaluate other options

   Increasing batch size affects performance but not monitoring; debug logging on broker does not monitor client metrics; Kafka Connect exports data but is not the direct way to monitor client metrics.

4. Final Answer:

   Configure the producer to expose JMX metrics and use a monitoring tool to collect and alert on latency and error metrics -> Option A

5. Quick Check:

   JMX metrics + monitoring tool = Configure the producer to expose JMX metrics and use a monitoring tool to collect and alert on latency and error metrics [OK]

Hint: Use JMX metrics with monitoring tools for real-time alerts [OK]

Common Mistakes:

• Confusing performance tuning with monitoring setup
• Relying on broker logs for client metrics
• Using Kafka Connect for direct client metric monitoring