The best Kafka tool for teams running Kafka Streams applications is one that can see inside each application, its topology, threads, state stores and lag, without sitting between the application and the brokers, decides per person who may reset an application’s offsets or delete its internal topics, records which person did it when the brokers only see a service credential, and runs as one container beside the cluster, out of the data path. Kpow with its open-source Streams Agent, Kafbat UI, AKHQ, the Kafka Streams metrics with Apache Kafka’s reset tool, Confluent Control Center and Conduktor each cover part of that. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 99 out of 110, ahead of Kafbat UI at 66 and AKHQ at 58; Conduktor, listed last, totals 59.
Tools compared
| Rank | Tool | Total (out of 110) | Out of the data path | Production access on request | Audit trail per person | Kafka Streams visibility | Directory and Kafka sign-in | Many teams, shared clusters | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 99 | One container, no external database, not a proxy; agent is a library | Offset reset and topic delete per person; temporary policies | Every reset, delete and inspect, by user | Topology, Streams metrics, activity summaries, Prometheus egress | SAML, OpenID, LDAP | Tenants per team | $7,380 |
| 2 | Kafbat UI | 66 | One container | Read-only clusters, no approvals | Opt-in log, no view in the product | Consumer group and topics only | OAuth2, OIDC, LDAP | Roles per resource | $8,640 |
| 3 | AKHQ | 58 | One container | Group roles, no approvals | Opt-in topic, no reads | Consumer group and topics only | LDAP, OIDC | Regex groups | $8,640 |
| 4 | Kafka Streams metrics and the reset tool | 51 | Nothing to deploy | Anyone with a client configuration | Broker sees a service principal | Every metric over JMX, nothing collecting it | JMX passwords and TLS | One process per application | $11,520 |
| 5 | Confluent Control Center | 43 | Dedicated host plus a metrics reporter on each broker | Confluent RBAC, no approvals | Principal-level audit logs (licensed) | Consumer group lag; Streams view unconfirmed in Confluent docs | OIDC | Admin access only, per TD Bank | $2,880 plus a quoted Confluent Platform subscription |
| 6 | Conduktor | 59 | Console on PostgreSQL; Gateway, a proxy, for data-level controls | Masking exemptions, owner approval | 70+ event types in the UI | Lineage between applications and topics | LDAP, OIDC | Groups; Virtual Clusters need Gateway | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for Kafka Streams
Rank 1 Kpow
99 out of 110 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per Kafka cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- On Kafka Streams
- Topology view, Streams metrics and Prometheus egress through the open-source Kpow Streams Agent; a Kpow Enterprise feature
- Deployment
- One container or JAR, no external database; the agent is an Apache 2.0 library in your application
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 9 out of 10
- Many teams, shared clusters
- 9 out of 10
Why these scores for Kpow
- Out of the data path 9 out of 10
- Kpow is one container or JAR whose snapshots, metrics and audit log live in topics on your own cluster, and the Streams Agent is a library inside your application that produces one snapshot a minute to a Kpow topic and never opens a connection to Kpow, so nothing sits between the application and the brokers.
- Production access on request 9 out of 10
- Offset resets and topic deletes are separate actions, GROUP_EDIT and TOPIC_DELETE, that RBAC allows or denies per person and per resource, temporary policies grant time-boxed access, staged mutations hold a change for approval, and data policies mask fields when changelog topics are inspected, though masking is per resource rather than per viewer.
- Audit trail per person 9 out of 10
- Every offset reset, group edit, topic delete and data inspect is recorded with the user from the identity provider and the policy that allowed it, with a seven-day view in the product, the record written to an audit topic on your own cluster, and webhooks that send it to a SIEM.
- Kafka Streams visibility 9 out of 10
- Each registered application appears in the Kpow Streams UI with summaries of its activity, reads and lag, a topology view on the Workflows tab, and its thread, state store and RocksDB metrics, which Kpow also serves to Prometheus at /streams/v1; it is held below 10 because every application has to add the agent and be redeployed, the snapshot arrives once a minute, and the view only holds the metrics the application records at its own recording level.
- Directory and Kafka sign-in 9 out of 10
- People sign in with SAML, OpenID or LDAP, Kpow connects to Kafka with the same SASL or TLS settings as any client, and the agent takes the standard producer security settings, with a manual key strategy for teams that do not want it to create an AdminClient.
- Many teams, shared clusters 9 out of 10
- Tenants scope each team to its own topics and consumer groups on a shared cluster, which covers a Streams application’s application.id group and its prefixed internal topics, RBAC adds Allow, Deny or Stage per action, and in a multi-cluster deployment each agent produces to the primary cluster that holds Kpow’s internal topics.
On Kafka Streams. The Kpow Kafka Streams documentation adds the agent from Maven Central as a dependency, registers each KafkaStreams instance and its Topology with a StreamsRegistry before streams.start(), and lists what it unlocks: topology visualisation, Kafka Streams metrics such as stream-thread, state store and RocksDB, activity summaries per cluster, and Prometheus egress. The agent’s source is on GitHub under the Apache 2.0 licence. The Streams UI arrived in Kpow 80.
Where it falls short. Nothing appears until the agent is added to an application’s code and the application is redeployed, and the agent is a Java library, so a Streams application written for another runtime is out of reach. Snapshots arrive once a minute rather than live. Kpow resets a group’s offsets and deletes topics, but it does not run Apache Kafka’s Streams application reset tool or clear an instance’s local state directory. The Kafka Streams UI, RBAC, masking, staged mutations and the full audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users.
Rank 2 Kafbat UI
66 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Kafka Streams
- Consumer groups and topics only; no Streams view
- Sign-in
- OAuth2, OIDC and LDAP, free
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
Why these scores for Kafbat UI
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 4 out of 10
- RBAC grants actions per resource and a cluster can be set read-only, but there is no approval step, no time-boxed grant, and its masking applies the same way to every viewer.
- Audit trail per person 6 out of 10
- Its audit log names the logged-in user and records reads when the level is set to ALL, but it writes to a topic or the console with no view in the product, so reading the trail is something you build.
- Kafka Streams visibility 3 out of 10
- A Streams application shows up only as what the brokers see: its application.id consumer group with lag, and its internal topics in the topic list; the feature list in its README describes no Kafka Streams topology or state store view.
- Directory and Kafka sign-in 7 out of 10
- It supports OAuth2 and OIDC, including Microsoft Entra ID, and LDAP or Active Directory, and its documentation does not list SAML.
- Many teams, shared clusters 6 out of 10
- Roles scope permissions per resource and list the clusters they apply to, with no tenant view of a team’s own resources.
On Kafka Streams. Kafbat UI is a general Kafka UI. A Kafka Streams application’s consumer group, offsets and lag appear on its consumer groups pages, and its repartition and changelog topics appear with the rest like any other client’s. Its README lists no Kafka Streams feature. The Kafbat UI review covers the rest.
Where it falls short. There is no view of what happens inside an application: no topology, no thread or task state and no state store metrics, so those come from the application’s own metrics elsewhere. There is no way to grant production access for an hour and have it expire or to hold an offset reset for approval. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 3 AKHQ
58 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Kafka Streams
- Consumer groups and topics only; no topology view
- Security default
- Disabled until you enable it
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Directory and Kafka sign-in
- 6 out of 10
- Many teams, shared clusters
- 5 out of 10
Why these scores for AKHQ
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 3 out of 10
- Groups bind actions to resources by regex, but there is no approval step or time-boxed grant, masking is global, and without the JWT signing secret the restriction is in the UI only.
- Audit trail per person 4 out of 10
- Audit events are opt-in to a Kafka topic, reads are not recorded, and there is no view for the trail.
- Kafka Streams visibility 3 out of 10
- A Streams application appears as its consumer group and its internal topics, and the AKHQ review on this site records that AKHQ has no Kafka Streams topology visualisation.
- Directory and Kafka sign-in 6 out of 10
- It supports LDAP, OIDC and header authentication from a proxy, does not list SAML, and ships with security disabled until you enable it.
- Many teams, shared clusters 5 out of 10
- Groups combine resource types with regex patterns on names and clusters, which limits what a role can reach, but there is no tenant view of a team’s own resources.
On Kafka Streams. AKHQ shows consumer groups with their offsets and lag and lets a permitted user update a group’s offsets, which covers the broker side of a Kafka Streams application. The AKHQ review lists Kafka Streams topology visualisation among the things AKHQ does not do.
Where it falls short. Security is off until you configure it, the audit trail is an opt-in topic that does not record reads, and nothing inside a Streams application is visible. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Compare Kpow vs AKHQAKHQ review
Rank 4 Kafka Streams metrics and the reset tool
51 out of 110 Total
- Cost a year
- $0 licence, about $11,520 in operator time (modelled)
- On Kafka Streams
- JMX metrics, Topology#describe() and the application reset tool
- Needs
- A JMX exporter, Prometheus and dashboards you build
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 3 out of 10
- Many teams, shared clusters
- 2 out of 10
Why these scores for Kafka Streams metrics and the reset tool
- Out of the data path 10 out of 10
- There is nothing to deploy beyond the applications themselves, which is the only option here that scores 10.
- Production access on request 1 out of 10
- Anyone with a client configuration and the right ACLs can run the reset tool or kafka-consumer-groups against a production application, with no approval step, no expiring grant and no masking.
- Audit trail per person 2 out of 10
- The brokers see the principal in the client configuration a person used, which is often a shared service credential, and nothing ties a reset to a named person in the directory.
- Kafka Streams visibility 5 out of 10
- Every signal exists, from thread and task metrics to state store and RocksDB statistics over JMX, and Topology#describe() prints the topology as text, but nothing collects them into one view, and each application is a separate JMX target.
- Directory and Kafka sign-in 3 out of 10
- JMX can be secured with passwords and TLS and the command-line tools take SASL or TLS client settings, but there is no SAML or OpenID sign-in.
- Many teams, shared clusters 2 out of 10
- Each application is its own process with its own metrics, and nothing marks which team owns which application, group or internal topic.
On Kafka Streams. Kafka Streams reports its metrics through JMX in a hierarchy of client, thread, task, processor node and state store levels, as the Apache Kafka monitoring documentation lists, and Kafka ships an application reset tool that rewinds input topics and deletes internal topics. Every tool on this page, Kpow’s agent included, reads from the same library.
Where it falls short. It is a toolkit, not a tool: the metrics need a JMX exporter, a metrics store and dashboards, lag has to be read from the application’s consumer group elsewhere, and the reset tool is run by hand with nothing recording who ran it. Its modelled running cost is 8 engineer-hours a month, $11,520 a year at $120 an hour.
Compare Kafka Streams
Rank 5 Confluent Control Center
confluent.io
43 out of 110 Total
- Cost a year
- $2,880 operator time, plus a Confluent Platform subscription that is quoted (modelled)
- On Kafka Streams
- Consumer group lag; a Streams topology view is credited by the Control Center review but not described in Confluent's overview
- Scope
- Confluent Platform clusters only
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 5 out of 10
- Many teams, shared clusters
- 4 out of 10
Why these scores for Confluent Control Center
- Out of the data path 4 out of 10
- It is not a proxy, but it needs a dedicated host of 4 cores, 8 GB and 200 GB and the Confluent Metrics Reporter on each broker.
- Production access on request 2 out of 10
- Access runs through Confluent RBAC role bindings, which have no DENY rules, and no approval step, time-boxed grant or masking is described.
- Audit trail per person 4 out of 10
- Confluent Server’s structured audit logs, which need the Confluent Enterprise License, record authorization decisions for the connection’s principal, which is not always the person behind a tool.
- Kafka Streams visibility 5 out of 10
- Confluent’s overview says Control Center collects metrics about brokers, topics and consumer group lag and does not describe Kafka Streams, while the Control Center review on this site credits it with Streams topology visualisation, so it is scored as partial support the reader should verify.
- Directory and Kafka sign-in 5 out of 10
- OIDC is the only single sign-on protocol on self-managed deployments, with users and groups from LDAP or OIDC through Confluent RBAC.
- Many teams, shared clusters 4 out of 10
- TD Bank’s platform team said in its talk that Control Center could only accept admin access and was not scalable for their clients, which is why those clients moved to Kpow.
On Kafka Streams. Control Center is the console Confluent ships with Confluent Platform. Confluent’s Control Center overview describes a web tool for managing and monitoring Kafka in Confluent Platform that collects metrics about brokers, topics and consumer group lag. Confluent’s overview does not describe Kafka Streams applications, so on that page a Streams application is visible through its consumer group; the Control Center review credits Control Center with Kafka Streams topology visualisation, which is why it scores as partial support here, to be verified against your Confluent Platform version.
Where it falls short. It reaches Confluent Platform clusters only, so a team that adds Confluent Cloud or moves to open-source Kafka needs a second tool. It offers no approval step or expiring grant, SAML is not available on self-managed deployments, and it is not sold separately and its price is not published.
Compare Kpow vs Confluent Control CenterConfluent Control Center review
Rank 6 Conduktor
conduktor.io
59 out of 110 Total
- Cost a year
- 25 Console seats at $1,200 is $30,000 plus $2,880 operator time, so $32,880; Gateway Core adds $60,000 and Gateway Protect, which carries encryption and masking, a further $30,000 (modelled)
- On Kafka Streams
- Consumer groups, alerts and stream lineage between service accounts and topics
- Deployment
- Console on PostgreSQL 13+; data-level controls through Gateway, a proxy
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Kafka Streams visibility ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 7 out of 10
Why these scores for Conduktor
- Out of the data path 3 out of 10
- Console needs PostgreSQL 13 or later, and its encryption, data-level masking and Virtual Clusters only work when client traffic goes through Gateway, a proxy in the data path.
- Production access on request 6 out of 10
- Masking can exempt users or groups, which beats every other tool here on who sees unmasked data, and cross-team access requests are approved by the owning team, but no expiring grant is described and topic creation that passes policy is a direct API call.
- Audit trail per person 8 out of 10
- Console logs produce, consume and admin requests across more than 70 event types with user, IP and timestamp, browsable in the UI and exported as CloudEvents.
- Kafka Streams visibility 4 out of 10
- Its stream lineage maps which service accounts or applications produce to and consume from which topics, built from Kafka ACLs or role bindings, which places a Streams application among its neighbours but does not show its topology, threads or state stores.
- Directory and Kafka sign-in 7 out of 10
- Its SSO configuration covers LDAP and OIDC, with guides for Okta, Entra ID and Keycloak, and does not describe SAML.
- Many teams, shared clusters 7 out of 10
- Permissions are set per user or group across clusters, but a user in several groups inherits the most permissive grant, and Virtual Clusters for multi-tenancy need Gateway.
On Kafka Streams. Conduktor’s stream lineage documentation describes a graph of application instances or service accounts and the topics they read and write, derived from the ACLs granted to each service account. Conduktor also publishes a tutorial for replacing a Kafka Streams filter-and-project application with a Gateway Topic View, a read-only SQL projection of a topic served through its proxy. The Conduktor review covers the rest.
Where it falls short. Console needs PostgreSQL. Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters for multi-tenancy, run in Gateway, a Kafka proxy that client applications connect through, and its Topic View tutorial moves filtering and field removal that a Streams application did into that proxy. On AWS Marketplace, Conduktor Enterprise lists Console at $1,200 a seat for the first 100 seats, Gateway Core, which carries virtual clusters, at $60,000 a year, and Gateway Protect, the add-on for encryption and masking, at a further $30,000.
Compare Conduktor vs Confluent Control CenterConduktor review
What teams using Kafka Streams need
This page is about tools that sit beside Kafka Streams applications, the Java library from Apache Kafka that teams embed in their own services, whatever Kafka those applications run against. Kafka Streams is covered in depth in Kafka Streams, the SQL layer built on it in the best Kafka tools for self-managed ksqlDB, and the broader field of Kafka tools in the best Kafka management tools. The six options are the ones Factor House’s other stream processing pages compare.
A Kafka Streams application is not a server a tool can connect to. It runs inside the team’s own process, and one setting, application.id, does four jobs: the Kafka Streams configuration reference says it is the default client.id prefix, the consumer group.id for coordination, the name of the application’s subdirectory in the state directory and the prefix of its internal topics. That is why every Kafka UI can show a Streams application’s lag, and why none can show more without help from inside the application.
Out of the data path. A Streams application already reads its input topics and writes its output, repartition and changelog topics on its own behalf. A tool whose controls work only when client traffic passes through a proxy therefore sits in front of every record the application processes, and a stateful application that depends on its changelogs then depends on the proxy staying up. What a tool needs from inside the application is the topology and the metrics, not the data. The Apache Kafka monitoring documentation lists the Streams metrics as reported by the client, not by the broker, so topology and task health need an agent in the application; Kpow’s agent produces a snapshot to a topic on the cluster once a minute and, per the Kpow Kafka Streams documentation, “does not talk directly to Kpow”. Kpow itself is one container with no external database, installed in your own environment and out of the data path. Conduktor Console also connects directly, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through, and Conduktor’s own Topic View tutorial describes moving a Streams application’s filtering and field removal into that proxy.
Production access on request. The riskiest thing anyone does to a Streams application is reset it. Apache Kafka’s application reset tool rewinds the input topics and deletes the internal topics, which also deletes their committed offsets, and its documentation warns that a typo in application.id or the wrong input topics can invalidate the application’s state or even affect other applications. A complete reset also needs each instance’s local state directory deleted before it restarts. The same steps by hand, an offset reset on the application’s group or a delete of a changelog topic, are available to anyone with a client configuration and the ACLs. What a tool adds is a permission per person and per action, an approval step for a destructive change, and access to production that expires after the task. Those controls are compared across the field in Kafka RBAC tools.
Audit trail per person. A Streams application authenticates to Kafka as its own service principal, and an engineer who resets it from the command line often does so with a shared service credential too, so the broker’s record names a credential rather than a person. The only record of which engineer rewound a group or deleted an internal topic has to come from the tool they used. The options are compared in Kafka audit logging tools.
Kafka Streams visibility. Day-to-day work on Kafka Streams is reading an application from the inside: its topology of sources, processors and sinks, the state of its threads and tasks, the size and activity of its state stores, and its lag. The monitoring documentation sets many of those metrics, from task to state store level, at debug level and says RocksDB statistics-based metrics are debug level “because collecting statistics in RocksDB may have an impact on performance” and are collected every minute, so a tool shows only what the application has been configured to record. State lives in internal topics too: the Kafka Streams topic management guide says changelog topics for key-value stores are compacted and repartition topics use delete with infinite retention, so reading a changelog is how to see what a state store holds. The ground is also moving. Apache Kafka 4.1 introduced a new Streams rebalance protocol, KIP-1071, in early access, which makes Streams task assignment part of the Kafka protocol, so a tool has to keep up with how the broker sees a Streams application as well as how the application sees itself.
Directory and Kafka sign-in. A Kafka Streams tool holds two kinds of connection: its own connection to Kafka with whatever SASL or TLS settings the cluster requires, and whatever reaches the application, an agent that uses the application’s producer settings or a JMX port with its own credentials. People then sign in through the company directory over SAML, OpenID Connect or LDAP, so a reset is tied to a named person rather than to a shared credential.
Many teams, shared clusters. Streams applications from several teams usually share a cluster, each with its own application.id, consumer group and prefixed internal topics. Each team needs its own view of its own applications, groups and topics, and permission to change only those. Teams moving stream processing to Apache Flink meet the same question there, and the best Flink tools for self-managed Apache Flink compares the tools for that.
Kpow does not win on every point. The Kafka Streams metrics and reset tool have nothing to deploy, every application has to add Kpow’s agent and be redeployed before Kpow can see inside it, and the agent is a Java library. The agent is the only Factor House code that runs inside a customer’s application, and it is open source under the Apache 2.0 licence, the same licence as Apache Kafka, so it can be reviewed like any other dependency.
I'm a huge fan of Kafka Streams. There's an incredibly elegant architecture behind it. And Flink, I was just having a phenomenal conversation in the hallway channel with … someone discussing their love for the mental model behind Flink and the clarity that it gives them and the constraints that it provides that they can program against.
Derek Troy-West, Co-founder and CEO of Factor House
Kpow customers that build on Kafka Streams
No public source names a customer that registers its Kafka Streams applications with the Kpow Streams Agent, so this section does not claim one. Funding Circle is a Kpow customer whose engineers build Kafka Streams applications and maintain an open-source Clojure library for them, which is public context about the company rather than about how it uses the agent. Factor House does not modify or extend Kafka and sells no Kafka distribution, so the agent works with whichever Kafka the application runs against. For customer accounts on specific platforms, the Confluent Platform page carries NORD/LB and TD Bank, the self-managed ksqlDB page carries NORD/LB’s query development, and the self-managed Apache Kafka page carries Gmarket and Claritev.
-
Funding Circle
- Kafka Streams
- Clojure
- Open-source Kafka library
Public context about the company. How it uses the product has not been published.
Funding Circle’s engineers maintain Jackdaw, an open-source Clojure library for Apache Kafka whose README says it can “create stream processing applications using the Streams API”, and the team has written about building Kafka Streams applications in Clojure. Funding Circle is a Kpow customer. Its public material does not say whether it registers those applications with the Kpow Streams Agent, so this card records the company’s Kafka Streams work rather than its use of the agent.
How a team runs Kpow with Kafka Streams
Installing Kpow. Kpow runs as one Docker container, a Java JAR or from the Helm charts, in the same network as the cluster. It needs no external database, because its snapshots, metrics and audit log live in topics on the Kafka cluster. The Kafka Streams UI is a Kpow Enterprise feature.
Adding the agent to an application. The kpow-streams-agent dependency comes from Maven Central. Just before streams.start(), the application creates a StreamsRegistry from its Kafka properties and registers its KafkaStreams instance and Topology, and one registry can hold several Streams instances. Once a minute the registry captures each application’s metadata and produces a snapshot to Kpow’s internal __oprtr_snapshot_state topic (Kafka Streams documentation).
Securing the agent. The registry takes the standard producer security settings, SASL, TLS keystores and truststores and OAuth token endpoints, and sets its own serializers. On a cluster with ACLs, the agent’s user needs one permission: Write on __oprtr_snapshot_state. By default the agent keys its snapshots by cluster ID through a short-lived AdminClient; a team that does not want the agent to create an AdminClient, for security reasons or because its Kafka variant reports no cluster ID, uses a manual key that matches the cluster’s ENVIRONMENT_NAME in Kpow instead. Metric filters, which work like Micrometer’s meter filters, decide which Streams metrics leave the application, down to sending the topology alone.
Several clusters. With one cluster, the application’s own Kafka properties are reused for the registry. With several, the registry produces to the primary cluster, the first in Kpow’s configuration, where Kpow’s internal topics live, while the application keeps running against its own cluster.
Reading the application. Each registered application appears in the Kpow Streams UI with summaries of its activity, reads and lag, and the Workflows tab draws its topology (Kpow 80 release notes). Kpow also collects its thread, state store and RocksDB metrics, and a changelog or repartition topic is an ordinary topic that data inspect can read, with the agent’s own snapshots findable there with a kJQ filter, as its README describes.
Resetting and repairing. The application’s application.id group is a consumer group like any other in Kpow’s groups view, where offsets can be reset to a value or a timestamp, advanced by one on a partition, or cleared, and an EMPTY group’s offsets are read straight from the AdminClient so they can still be reset when the whole application is down. Kpow’s authorization actions make GROUP_EDIT and TOPIC_DELETE separate permissions, RBAC allows or denies them per resource, staged mutations hold a change for a second person, and a temporary policy grants the access for a set time and then expires. Deleting each instance’s local state directory stays a job on the application’s hosts.
Signing people in and keeping the record. Engineers sign in through SAML, OpenID Connect or LDAP, tenants limit each team to its own topics and groups, and the audit log records every reset, delete and inspect with the user from the identity provider. A webhook sends those records to Slack, Microsoft Teams or any HTTP endpoint, such as a SIEM collector.
Alerting. Kpow serves every registered application’s Streams metrics to Prometheus at /streams/v1 and each application’s state at /streams/v1/state, which maps to the KafkaStreams.State enum, and the metrics glossary lists streams_state, streams_client_state and streams_data_points, so an application that leaves the RUNNING state is a one-line Alertmanager rule.
Kpow live demo
See the Kpow UI before you register a Kafka Streams application
The live Kpow demo runs on two Apache Kafka clusters on Amazon MSK. It shows brokers, topics, consumer groups, schema registries and the __oprtr_audit_log topic where Kpow keeps its audit trail, with no signup. Registering one of your own Kafka Streams applications with the open-source Kpow Streams Agent is the step to try next.
For platform teams choosing a tool for Kafka Streams.
Try the Kpow demoFAQ
What is the best tool for Kafka Streams?
On this page’s rubric, Kpow, with 99 of 110 points: its open-source agent sends each application’s topology and Streams metrics to a topic once a minute, Kpow shows the topology with state and lag and serves the metrics to Prometheus, every offset reset or topic delete is recorded against the person who made it, and Kpow runs as one container beside the cluster with no external database. Kafbat UI is the highest-scoring free option, though it sees a Streams application only as a consumer group and topics.
Does Kpow support Kafka Streams?
Yes, in Kpow Enterprise, through the Kpow Streams Agent, an Apache 2.0 Java library on Maven Central that each application registers with a StreamsRegistry before it starts. It unlocks topology visualisation, Streams metrics including state store and RocksDB, activity summaries and Prometheus egress (Kafka Streams documentation). The Streams UI arrived in Kpow 80.
Does the Kpow Streams Agent slow down or sit in front of my application?
It does not sit in front of anything. It is a single-threaded process inside the application that captures metadata once a minute and produces a snapshot to one Kpow topic, and it never connects to Kpow itself. Metric filters can cut what it sends down to the topology alone (Kafka Streams documentation).
Why do my RocksDB metrics not show up?
Kafka Streams records RocksDB statistics-based metrics at debug level, because collecting them may affect performance, so they are absent while the application’s metrics.recording.level is info, the default, as the Apache Kafka monitoring documentation explains. Any tool, Kpow included, shows only what the application records.
How do I reset a Kafka Streams application safely?
Run Apache Kafka’s application reset tool with the exact application.id and input topics, and delete each instance’s local state directory before restarting. The tool rewinds input offsets and deletes internal topics, and its documentation warns that wrong parameters can affect other applications. Doing the offset reset through a tool with per-person permissions and an audit trail records who did it.
Is there a free Kafka UI for Kafka Streams?
Kafbat UI and AKHQ are open source and show a Streams application’s consumer group, lag and internal topics, but not its topology or state stores. The Kafka Streams UI in Kpow is an Enterprise feature; Kpow Community Edition is free on up to 3 clusters and 10 users for the rest of Kpow. More free options are compared in the best free Kafka UI tools.
How these tools were scored
Five of the six criteria are the ones Factor House scores on every page for teams that share a Kafka cluster; the sixth is Kafka Streams visibility. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent. The weights add up to 11, so totals are out of 110.
1. Out of the data path (counts three times). The tool should run in your own environment, reach Kafka as an ordinary client, read what it needs from inside an application without carrying the application’s data, and keep no data outside your own cluster. Scored lower: tools that need an external database or a dedicated host of their own, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with a dedicated host and a component on every broker 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, which here is the Kafka Streams metrics and reset tool. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
2. Production access on request (counts twice). Whether an engineer can be granted access to production for one task and have it expire, whether permissions separate reading from resetting offsets and deleting topics, whether a destructive change can be held for a second person’s approval, and whether sensitive fields can be masked from people who do not need them.
3. Audit trail per person (counts twice). Whether the tool records each action, offset resets and topic deletes included, against the person from the identity provider, and whether that record can be read in the product and sent to the systems that keep it long term.
4. Kafka Streams visibility (counts twice). Whether the tool shows a Streams application’s topology, the state of its threads and tasks, its state store and RocksDB metrics and its lag in one place, serves those metrics to an alerting system, and reaches applications on several clusters, and what each application has to change for that to work.
5. Directory and Kafka sign-in (counts once). Whether people sign in through SAML, OpenID Connect or LDAP, and whether the tool, and anything it adds to an application, connects to Kafka with the same SASL or TLS settings as any client.
6. Many teams, shared clusters (counts once). Whether each team can be given its own view of its own applications, consumer groups and internal topics on a shared cluster, and whether one deployment reaches several clusters.
Costs are modelled for one production Kafka cluster with its Streams applications and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs carry 6 hours a month, $8,640 a year, to run, secure and keep current, and the Kafka Streams metrics with the reset tool carry 8 hours a month, $11,520, for the exporter, dashboards and scripts. Kpow’s $7,380 uses the published price of $4,500 per cluster with 100 users included. Confluent Control Center is not sold separately and comes with a Confluent Platform subscription whose price Confluent quotes rather than publishes, so its total cannot be compared with the others here. Conduktor’s Console is $1,200 a seat on AWS Marketplace, and its Gateway Core and Gateway Protect prices are added for the data-level controls; Conduktor prices Gateway per cluster with a 3-cluster minimum, and the listing does not say how many clusters that figure covers. Kpow Community Edition is free for 3 clusters and 10 users, but the Kafka Streams UI needs Kpow Enterprise. For free options compared at any team size, see the best free Kafka UI tools.
The criteria map onto the design of Kafka Streams in the figure below.
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Kafka Streams visibility counts twice, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 110. Out of the data path counts three times. A Kafka Streams application already reads and writes Kafka on its own behalf, so a tool whose controls work through a proxy sits in front of every record the application processes, and a tool that needs a database of its own is one more stateful service beside applications that already carry state. Production access on request, the per-person audit trail and Kafka Streams visibility count twice: resetting a Streams application means rewinding its consumer group and deleting its internal topics, so who may do that, and who did, has to come from the tool, and a tool that cannot see inside the application leaves the team reading JMX by hand. Directory and Kafka sign-in, and shared clusters, count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 99 out of 110. The other options follow by total. Conduktor is listed last whatever its total; on its total of 59 it would place third.
Related reading
- Kafka: the complete guide
- Kafka Streams
- Kafka Streams documentation, mapped
- Best Kafka tools for self-managed ksqlDB
- Best Kafka tools for Apache Kafka Connect
- Best Kafka tools for self-managed Apache Kafka
- Best Flink tools for self-managed Apache Flink
- Best Kafka management tools for Confluent Platform