DEV Community: A.D.

Kafka Consumer Lag Is the Metric Everyone Collects—and Almost Everyone Misunderstands

A.D. — Thu, 09 Jul 2026 14:06:20 +0000

Kafka Consumer Lag Is the Metric Everyone Collects - and Almost Everyone Misunderstands

Ask almost any Platform Engineer:

"How do you monitor Kafka?"

The answer is usually immediate:

"Consumer lag."

They aren't wrong.

Consumer lag is arguably the single most important operational metric in
Apache Kafka.

The surprising part is this:

Almost nobody is actually monitoring consumer lag.

They're monitoring a number.

Those are two very different things.

The Number Everyone Watches

Imagine your dashboard says:

payments-consumer
Lag: 12,487

Should you panic?

Nobody knows.

Not because Kafka is complicated.

Because lag without context is meaningless.

12,487 messages might represent:

Two seconds
Two hours
A consumer that is catching up
A consumer that has completely stopped

The number itself tells you nothing.

Imagine Driving a Car...

Imagine driving a car that only has one gauge.

Engine: 4,217

4,217 what?

RPM?

Temperature?

Horsepower?

Would you trust it?

That is how most Kafka dashboards look.

They expose lag.

They hide everything that gives lag meaning.

Offset Lag Is Not Business Lag

Offsets measure distance.

Your users experience time.

A backlog of 10,000 messages could disappear in three seconds---or
six hours.

Which one affects your SLA?

Exactly.

The Second Layer

Suppose you also monitor producer and consumer throughput.

Better?

Yes.

Enough?

No.

One partition can be completely stalled while every other partition
keeps processing normally.

Average throughput still looks healthy.

One customer waits forty minutes.

Your dashboard stays green.

The Third Layer

Now your consumer throughput drops.

Lag begins increasing.

Why?

Possible causes include:

Broker throttling
Network latency
Slow downstream database
Consumer rebalance
Poison message
GC pause
Partition skew
Producer spike

Exactly the same lag graph.

Completely different root causes.

Monitoring only the consumer process won't tell you.

Monitoring only Kafka metrics won't tell you either.

Kafka Doesn't Break All At Once

Production incidents rarely look like this:

Lag: 0 → 500,000

Instead they evolve gradually:

One partition slows down
One consumer drifts
Estimated catch-up time doubles
Lag velocity changes
A rebalance begins
Offsets continue committing
Dashboards remain mostly green

By the time someone notices,

the incident has already happened.

Consumers Can Be Healthy While Users Are Waiting

One of the biggest misconceptions is:

"If my consumer is healthy, Kafka is healthy."

Not necessarily.

Your application can be healthy.

Pods can be healthy.

CPU and memory can be healthy.

Offsets can continue committing.

Meanwhile:

Payments are delayed.
Emails are not delivered.
Notifications arrive twenty minutes late.

Your application is healthy.

Your data pipeline is not.

Kafka Is a System, Not a Process

Traditional monitoring focuses on individual processes.

Kafka behaves more like traffic.

If you monitored a highway, would you only count cars?

Or would you also monitor:

Traffic speed
Congestion
Bottlenecks
Lane imbalance
Estimated arrival time

Kafka is the same.

Lag is only one measurement of a much larger system.

What Production Teams Eventually Build

After enough incidents, experienced teams stop asking:

"What's the current consumer lag?"

Instead they ask:

Which consumer groups are drifting?
Which partitions are outliers?
Is lag growing faster than consumers can recover?
How long until everything catches up?
Is this a rebalance or a real incident?
Which tenants are affected?
Is the backlog spreading or localized?

Notice something.

None of those questions is answered by a single lag metric.

The Inception Moment

Most organizations already collect consumer lag.

Many export it to Prometheus.

Many have Grafana dashboards.

Yet when an incident begins, engineers still:

Run Kafka CLI tools
Compare partition offsets manually
Inspect consumer groups
Correlate multiple dashboards
Reconstruct the timeline

If that's your workflow,

you weren't monitoring Kafka.

You were collecting numbers.

What Changes Mature Kafka Operations

The most mature Kafka teams don't stop at collecting lag.

They monitor:

Lag trends
Recovery time
Lag velocity
Partition imbalance
Consumer health
Broker pressure
Historical behaviour
Anomalies

Eventually they realize something important:

Consumer lag is not the destination.

It is the beginning of an investigation.

The teams that operate Kafka most effectively build their observability
around answering operational questions rather than collecting isolated
metrics. Once you start thinking that way, it becomes obvious that
monitoring only consumer lag---or only the consumers themselves---can
never provide enough context to understand what's actually happening
inside a production Kafka cluster.

p.s. checkout https://klag.dev/

Kafka Consumer Lag Monitoring in 2026: Replacing kafka-lag-exporter with a Modern Alternative

A.D. — Thu, 09 Jul 2026 13:55:40 +0000

Kafka Consumer Lag Monitoring in 2026: Replacing kafka-lag-exporter with a Modern Alternative

If you operate Apache Kafka or Redpanda in production, consumer lag is one of the most important operational metrics you can monitor. It directly affects data freshness, downstream systems, SLAs and customer experience.

For years, kafka-lag-exporter was the standard Prometheus exporter for Kafka consumer lag. However, the project was archived in 2024, leaving many platform teams looking for a maintained alternative.

This article explains how Kafka consumer lag monitoring works, what to look for in a monitoring solution, common operational pitfalls, and how klag addresses those challenges.

How Kafka Consumer Lag Monitoring Works

Every consumer group periodically commits offsets. Monitoring tools compare:

Current partition offset
Last committed consumer offset

The difference is consumer lag.

However, raw offsets alone are often insufficient. A lag of 10,000 messages may be healthy if consumers process 20,000 messages per second, but critical if throughput has stalled.

Modern Kafka observability therefore benefits from:

offset lag
estimated time-to-catch-up
lag trends
consumer health
partition imbalance
throughput

Why kafka-lag-exporter Is No Longer Enough

Although it served the community well, the archived project has several practical limitations:

no active maintenance
aging dependency stack
JVM/Scala runtime
limited visibility into time-based lag
increasing compatibility risks with newer Kafka releases

For production observability pipelines, actively maintained software is increasingly important.

Choosing a Kafka Consumer Lag Monitoring Tool

When evaluating Kafka or Redpanda monitoring tools, consider:

active maintenance
low broker overhead
Prometheus metrics
OpenTelemetry support
Kubernetes friendliness
accurate time-based lag estimation
scalability to large clusters
operational diagnostics beyond raw offsets

Comparing Popular Kafka Lag Monitoring Tools

Capability	kafka-lag-exporter	klag	Burrow / KMinion
Maintained	❌	✅	Mixed
Native executable	❌	✅ GraalVM Native	Mixed
Prometheus	✅	✅	Varies
OpenTelemetry	Limited	✅	Limited
Time-based lag estimation	Limited	✅	Usually requires external queries
Hot partition detection	❌	✅	❌
MCP support	❌	✅	❌

Three Operational Problems klag Solves

1. Lower Broker Overhead

Large Kafka deployments may contain thousands of consumer groups and millions of partitions.

Instead of aggressively requesting metadata, klag batches and spaces requests to reduce broker load.

2. Better Operational Context

Beyond offsets, klag provides:

estimated catch-up time
lag velocity
hot partition detection
consumer imbalance indicators

These metrics make it easier to identify incidents before they become outages.

3. Cloud-Native and AI-Native

klag is distributed as a GraalVM native executable with approximately 50 MB memory usage, integrates with Prometheus, OpenTelemetry and Grafana, and includes a read-only MCP server that allows AI assistants to inspect consumer lag safely.

Common Kafka Consumer Lag Problems

Stalled Consumers

A consumer has stopped processing while lag continues growing.

Hot Partitions

One partition accumulates significantly more lag than others, often indicating skewed keys or insufficient parallelism.

Rebalance Storms

Frequent rebalances interrupt processing and create temporary lag spikes.

Slow Consumers

Applications remain healthy but cannot keep up with producer throughput.

Monitoring these patterns is generally more valuable than observing raw lag alone.

Typical Use Cases

Monitor Kafka consumer lag
Monitor Redpanda consumer lag
Detect stalled consumers
Estimate recovery time
Detect consumer imbalance
Find hot partitions
Export metrics to Prometheus
Export telemetry through OpenTelemetry
Enable AI-assisted operational troubleshooting through MCP

Migration

Migrating from kafka-lag-exporter is straightforward:

Deploy klag alongside the existing exporter.
Configure include/exclude filters.
Connect Prometheus or OpenTelemetry.
Import the Grafana dashboard.
Compare results before removing the legacy exporter.

Frequently Asked Questions

Is kafka-lag-exporter still maintained?

No. The project was archived in 2024.

What is a good replacement for kafka-lag-exporter?

Look for an actively maintained solution supporting modern Kafka versions, Prometheus, OpenTelemetry, Kubernetes and scalable metadata collection.

Does klag support Redpanda?

Yes. klag supports both Apache Kafka and Redpanda.

Does klag work with Prometheus and Grafana?

Yes. It exposes Prometheus metrics and includes ready-made Grafana dashboards.

Why monitor time-based lag?

Time estimates help operators understand business impact far better than offset counts alone.

Final Thoughts

Kafka consumer lag monitoring has evolved beyond exporting offset counts. Modern platform teams increasingly need scalable collection, operational diagnostics, cloud-native deployment and actionable telemetry.

If you're replacing an archived exporter or building a new Kafka observability stack, evaluate tools based on measurable operational capabilities—not just whether they expose lag metrics.

klag just got a bunch better — here’s what’s new.

A.D. — Sun, 07 Jun 2026 20:28:45 +0000

Over half year ago I’ve open sourced klag, a lightweight Kafka consumer lag exporter. I’ve been working in data streaming systems and data infrastructure for over a decade and it’s an ultimate tool, I wish I had sooner.

Klag (pronounced “kay-lag”) docker image has been downloaded over 2,000 times, repo has passed 70 ⭐️, contributions started flowing in. So what has been added recently?

🤖 Talk to your lag

klag now ships an MCP server. Point your AI agent at it and just ask: "which consumer groups are falling behind right now?"
No PromQL. No squinting at dashboards. Debugging a backlog at 2am is now a conversation instead of a query-writing exercise. This is the feature I'm most excited about — lag monitoring goes from read this to ask this.

⚡ Native builds — no JVM, instant startup

There's now a native image build. Same exporter, compiled ahead-of-time, near-instant startup, smaller footprint.
If klag is a tiny always-on sidecar whose whole job is to scrape offsets and emit numbers — and it should be — this is the build you want. No JRE dragging along.

🎯 Smarter group filtering

You can now exclude groups, not just include them. Want myapp-* but not the noisy canary groups? Done. Comma-separated globs, includes and excludes, exactly where you'd expect them.

📦 One-command install

The Helm chart is on ArtifactHub and the Grafana dashboard is public and ready to drop in. No git clone, no hardcoded datasource UIDs. helm install and you've got lag metrics flowing into Grafana in minutes.

🙌 ...and it's not just me anymore

People are showing up with PRs that fix real edges in real clusters — full KAFKA_* passthrough, older-broker compatibility, more accurate time-based lag, and more. That's exactly the feedback loop I wanted.

Introducing klag: The Kafka Lag Exporter I Always Wanted.

A.D. — Tue, 27 Jan 2026 20:32:13 +0000

TL;DR: please welcome github.com/themoah/klag — a new Kafka lag exporter with multiple sink options and even more visibility into your Kafka consumers.

Kafka lag exporter was very cool. I couldn't imagine running serious kafka-based workload without it. And then the repo got archived. So I had no other choice: I had to build my own kafka lag exporter. Better one. With all the features that I was missing.

It's fast, lightweight and very extendable, built atop Java 21, vert.x library and micrometer. It's already supporting otlp, datadog and prometheus.

So what is a kafka lag?

Basically, it’s the number of records (messages) that haven’t been processed by a consumer group — the downstream service. In general, you expect it to be zero or close to it. If it’s growing fast — something is wrong. Decreasing lag is the best indicator that you’ve successfully identified and fixed the issue.

Simple, right?

But let’s not forget: scale and distributed systems can make even the simplest problem incredibly hard. Processing metrics in a timely manner on huge clusters with hundreds of brokers, thousands of consumer groups, and millions of partitions is no joke.

The missing features.

Lag velocity.

Measuring the speed of lag change (growth or decline) is the key. Finding the right threshold, based on amount of records is a long story of trial and error. Lag has been growing without control for last period of time? That's really requires attention.

Hot partitions.

One partition can generate lots of headache, skew in processing, late data and other bad impacts. 100+ partitions topic might have an average lag under the threshold, but a single outlier partition can break your data pipeline.

Stale groups.

Reduce the noise. Inactive groups require cleanup, which can be very tricky.

Splitting the requests.

Huge cluster with thousands of topic-partitions and tens (or hundreds) of consumer groups create some enormous amount of metrics, which will overload your Kafka (and Zookeeper if you are still using it) cluster. Chunking request into mini sub-groups reduces the load on the cluster.

What's next ?

Planned next features:

Advanced filtering: whitelist (or blacklist) topics and/or consumer groups.
Support running with multiple metrics reporters.
More metrics sinks - stasD, cloudwatch and others.

Feature requests and feedback is always welcome.
(If you are running klag in production - i'd love to share your story or add a link to the Readme).

Hi, I'm A.D.

A.D. — Sun, 15 Jan 2017 15:42:35 +0000

I have been coding for 5+ years.

You can find me on Twitter as @themoah

I live in Tel-Aviv.

I work for ClickTale

I mostly program in these languages: Scala, C#, Python, JS.

I am currently learning more about ML.

Nice to meet you.