01
KRaft Readiness
Cluster mode, metadata version and controller quorum design, plus the inventory of clients, Connect workers, JVMs and tooling that a move to Kafka 4.x depends on.
Kafka Health Check
Kafka Health Check: KRaft Readiness, Lag and Replication Reviewed
A Kafka health check is an engineer-led review of a running cluster against how it is actually used: KRaft readiness, broker and controller configuration, replication and ISR, partition skew, consumer lag, security, retention and the monitoring that should have caught the last incident. You get a written report, a prioritised fix list and the reasoning behind each finding.
- scope areas reviewed on every cluster
- 9
- weeks from kickoff to walkthrough
- 1-4
- min emergency SLA on the support plan
- 15
Trusted for Mission-Critical Kafka by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
You run ZooKeeper-based Kafka and the move to 4.x has not been scoped
- 02
Consumer lag climbs at peak and nobody agrees whether brokers, partitions or clients are to blame
- 03
The people who built the cluster have moved on and the topology diagram is out of date
- 04
An audit or security questionnaire is asking about ACLs, TLS and authentication on the brokers
- 05
Traffic is about to grow: a launch, a new data pipeline, a change data capture rollout
- 06
You survived an incident without understanding it, and it could come back
- 07
You are choosing between support, managed Kafka and an upgrade and want the facts before the contract
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Kafka estate when the engagement closes.
Before
Nobody can say which Kafka version, mode and client libraries are in play, or what a 4.x upgrade would touch.
After
A written inventory per broker, controller and client group, with the KRaft path and the order of operations laid out.
Before
Replication and durability were set at go-live. The business assumes no data loss, and nobody has checked the settings deliver it.
After
Every topic class reviewed against the loss and availability the business expects, with the gaps listed and costed.
Before
Lag, rebalances and hot partitions show up as incidents, each treated as a one-off.
After
The structural causes named: partition counts, key skew, consumer settings and capacity, each with a fix and an owner.
Before
The team knows the cluster is fragile but cannot rank the risks or size the work.
After
A prioritised plan in three buckets: change now, change before the next growth step, and fine as it is.
Scope
What's covered
- 02
Broker and Controller Configuration
Listeners, log directories, heap and page cache, quotas and thread settings read against the hardware and the workload, with every non-default value explained or flagged.
- 03
Replication and ISR
Replication factor, min.insync.replicas and producer acks checked as a set, plus unclean leader election, rack or zone awareness, and how often the ISR actually shrinks.
- 04
Partition Layout and Skew
Partition counts per topic, key distribution, leader balance across brokers and topics nobody owns. Hot partitions look like a Kafka problem and are usually a design one.
- 05
Consumer Lag and Groups
Lag patterns over time rather than a single reading, rebalance frequency, session and poll settings, and which consumer groups cannot keep up with their topic.
- 06
ACLs, TLS and SASL
Authorizer configuration, ACL coverage and wildcard grants, TLS on client and inter-broker listeners, SASL mechanism, super users, and where credentials live.
- 07
Retention and Disk
Retention and compaction per topic against growth, log-directory headroom, and how long a broker rebuild would take after a disk failure.
- 08
Client Configurations
Producer idempotence, acks, retries and batching, consumer commit strategy, and the library versions in use. Most Kafka incidents begin on the client side.
- 09
Monitoring and Alerting Gaps
Whether under-replicated and offline partitions, ISR churn, controller health, request latency, disk and consumer lag are measured and paged on, and what would have caught the last incident.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 11 day
Intake and Scoping
We agree which clusters are in scope, the Kafka versions and deployment model (self-managed, Strimzi, Amazon MSK, Confluent), and the read-only exports we need. Delivery is remote, guided by your engineers over screen share. We take no access to your environment or code.
You receive
- Scope and cluster list
- Export checklist: broker and topic configuration, consumer group state, metrics history
- Incident history and known concerns collected
- Phase 21-4 weeks, by scope
Review
A senior Kafka engineer works through the nine scope areas against your exports and metrics, with your team in the room where a decision needs context. Findings are tested against real consumer lag and replication history, not a generic checklist.
You receive
- Inventory per broker, controller and client group
- Findings with evidence attached
- KRaft and upgrade-path notes
- Phase 3Within a week
Written Findings
The report, ranked by what is likely to fail first and under what conditions. Every finding carries the fix, the effort and the risk of leaving it.
You receive
- Written report
- Prioritised remediation list
- Monitoring gap analysis
- Phase 4At the end of the assessment
Walkthrough and Plan
A walkthrough with the engineer who did the work, then a sequenced plan your team can execute or hand to us. Remediation is scoped separately, so the report is useful whoever does the work.
You receive
- Findings walkthrough
- Sequenced plan: now, before the next growth step, fine as is
Kafka KRaft readiness: what the assessment checks
Apache Kafka 4.0, released on 18 March 2025, supports KRaft mode only. ZooKeeper mode has been removed, and a ZooKeeper-based cluster has to be migrated to KRaft before it can be upgraded to 4.0.x. A KRaft readiness assessment answers one question: what stands between this cluster and a supported 4.x release.
| Area | What Apache Kafka 4.0 requires | What we check |
|---|---|---|
| Cluster mode | KRaft only. ZooKeeper clusters must migrate to KRaft before upgrading to 4.0.x. | Current mode, metadata version, controller layout, and whether a migration is already in progress. |
| Clients | Clients, including Kafka Streams and Connect, must be on version 2.1 or higher. | Client libraries per application and per Connect worker, and which of them predate 2.1. |
| Java | Brokers, Connect and tools require Java 17. Clients and Kafka Streams require Java 11. | JVM versions across the fleet, and the applications that would need a runtime change first. |
| Controllers | Cluster metadata lives in a quorum of Kafka controllers instead of a ZooKeeper ensemble. | Controller count and placement, dedicated or combined roles, and disk for the metadata log. |
| Operations | Anything that talked to ZooKeeper has to change. | Runbooks, automation and monitoring that read ZooKeeper, and the ACL authorizer in use. |
Rule we hold
Never combine a platform migration with a version upgrade in the same production window. The health check sequences the KRaft move, the version upgrade and any client changes as separate changes.
What the Kafka health check report contains
The report is built to be read by the engineer who runs the cluster and the manager who funds the fixes. This is the outline every report follows. It is a structure, not a client document, and it carries no customer data.
| Section | Contents |
|---|---|
| 1. Summary | The findings most likely to cause an outage or data loss, in plain language, with a risk rating for each. |
| 2. Inventory | Brokers, controllers, Kafka and Java versions, operating system, disks, listeners, Connect workers and client groups. |
| 3. Findings register | One row per finding: severity, evidence, why it matters, the fix, effort and the risk of waiting. |
| 4. KRaft and upgrade path | Readiness against Kafka 4.0, the blocking items, and the order of operations. |
| 5. Monitoring gaps | What is measured and paged today, what is missing, and suggested thresholds. |
| 6. Remediation plan | Three buckets: change now, change before the next growth step, fine as it is. |
| 7. Appendix | Configuration exports and the checks run, so a second engineer can verify any finding. |
A report with a hundred undifferentiated observations has not done the hard part, which is ranking them. Ours puts the few findings that matter first and the rest in the appendix.
Where this health check stops
- Remote and read-only — We work from your exports and a screen share, guided by your engineers. We do not log in to your environment or touch your code.
- No application fixes — We tell you which client settings and patterns to change and why. Your developers make the change.
- Hosted services — On Amazon MSK or Confluent Cloud the provider owns broker operations. We review topic design, clients, ACLs and consumer lag, which remain yours.
- Remediation is separate — The report stands alone. If you want us to carry out the fixes, that is scoped and quoted as its own piece of work.
Customer Success
Real Kafka Results
See how enterprises trust AceMQ for their most critical Kafka workloads.
Producer Timeouts Traced to Controller-Leader Overload
European Hosting Provider
A five-node Kafka cluster serving 60,000 customers was timing out producers under load. The cause was topology, not capacity.
Apache Kafka
Docker
LinuxRecovering Transaction Throughput After a Kafka Rollout
Banking Transaction Platform
Throughput fell from 320,000 to roughly 45,000 transactions per hour after Kafka was introduced. The platform needed 80,000 to prove it could scale.
Apache KafkaKRaftJMeter
Real-Time Manufacturing Data Ingestion Modernization
Global Automotive Manufacturer
Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.
RabbitMQMQTTKafkaSQL Server
KubernetesMiddleware Architecture Assessment for Financial Trading
European Online Trading Platform
Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.
RabbitMQKafka
RedisChoosing Debezium + RabbitMQ over Kafka for Change Data Capture
American National Insurance
American National Insurance chose a standalone Debezium + RabbitMQ architecture for SQL Server change data capture after judging Kafka too complex to run for the job, keeping operations lean and routing flexible.
KafkaRabbitMQ
DebeziumKubernetesKafka CVE Patching and Compliance Strategy for Global Enterprise
Global Technology Enterprise
AceMQ developed a multi-technology compliance strategy covering CVE patching for Kafka alongside RabbitMQ and IBM MQ deployments, creating a unified vulnerability management approach across the entire enterprise messaging stack.
KafkaRabbitMQ
IBM MQHigh-Throughput Kafka and RabbitMQ Support for Global Payments
PagoNXT (Financial Technology)
AceMQ provided ongoing support for PagoNXT's high-throughput payments infrastructure running Kafka and RabbitMQ at 2,500 transactions per second, including load testing validation and architecture optimization.
KafkaRabbitMQKafka Architecture Assessment and Migration Advisory
Enterprise Organizations
AceMQ's Kafka assessment service evaluates streaming architecture health, identifies operational risks, and provides a structured migration or modernization roadmap for enterprises running or evaluating Kafka.
Kafka
FAQ
Questions about Kafka health check
What is a Kafka health check?
A Kafka health check is a structured review of a running cluster against how it is actually used. It covers KRaft readiness, broker and controller configuration, replication and ISR, partition skew, consumer lag, ACLs, TLS and SASL, retention and disk, client configuration and monitoring gaps, and ends in a ranked list of what will fail first and how to fix it.
Is a Kafka health check the same as a Kafka assessment, cluster audit or architecture review?
In practice they overlap. A health check, a Kafka cluster audit and a cluster review all examine the running cluster and its configuration. A Kafka architecture review looks wider, at how topics, producers, consumers and Connect pipelines fit the business problem. We scope the work to the question you are asking and say so up front.
How long does a Kafka health check take?
One to four weeks from kickoff to walkthrough, depending on how complex the estate is, which areas you want covered, and how many problems we find along the way. Intake takes a day, and the written findings arrive within a week of the review. Estates with several clusters or a Connect-heavy topology sit at the longer end, and we confirm the timeline once we know the cluster count and focus areas.
Do you need access to our production cluster?
No. We need visibility, not hands-on access. Broker and topic configuration, consumer group state, partition and replication layout and metrics history can be exported and reviewed. Read-only access speeds things up, and for regulated environments a configuration export plus a working session with your operators is normally enough.
Does it cover ZooKeeper to KRaft migration?
It covers readiness: whether the cluster, clients, Java versions and tooling can move to Kafka 4.x, and in what order. Apache Kafka 4.0 supports KRaft mode only, so a ZooKeeper-based cluster must migrate before it can upgrade. The migration itself is a separate piece of work, described in our ZooKeeper to KRaft migration guide.
How is this different from monitoring or from AceMQ's Kafka support?
Monitoring reports what is happening now. A health check tells you what will happen under conditions you have not hit yet. Support is an SLA over a cluster your team runs, with a 15-minute emergency response. The health check is a standalone engagement and is also the first step when a cluster moves onto support or managed services, so the work is not repeated.
What does a Kafka health check cost?
It is scoped on the number of clusters and the depth of review, not per broker or per topic. Send the cluster count and your deployment model and we will reply within 1 hour and follow with a written quote.
Let's talk
Book a Kafka Health Check
Tell us how many clusters you run and which Kafka version they are on. We will scope the review and reply within 1 hour and follow with a timeline and a written quote.
Get in Touch
Talk to a Kafka Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.