Best Kafka management tools for insurers

Tools compared

Rank	Tool	Total (out of 110)	Out of the data path	Production access on request	Audit trail per person	Inspecting topic data	Directory and Kafka sign-in	Many teams, shared clusters	Cost a year (modelled)
1	Kpow	99	One container, state in your Kafka, not a proxy	Time-boxed temporary policies via API, staged approvals, masking per resource	Every action with the IdP user, data queries included	kJQ search across topics, on the server	SAML, OIDC, LDAP; Kerberos, SCRAM or mTLS to brokers	Tenants and per-action RBAC	$20,880
2	Kafbat UI	76	One stateless container	Per-resource RBAC, no approvals, masking for all viewers	Optional, reads at level ALL, no view	Message browsing	OAuth2, OIDC, LDAP; no SAML	Per-resource roles per cluster	$11,520
3	AKHQ	68	One stateless container	Regex groups, UI-only if JWT secret unset	Opt-in, no reads, no view	Topic data browsing	LDAP, OIDC; no SAML	Groups by resource and cluster pattern	$16,320
4	Lenses	67	HQ on PostgreSQL, agent and database per cluster	Strict global masking, no approvals	In-product audit log from Team tier	SQL over topics	SSO incl. Entra ID and Okta	Roles on groups only	$2,880 plus quoted licence
5	Confluent Control Center	45	Dedicated host, broker reporter JAR	Confluent RBAC, no DENY, no approvals	Broker principal, not always the person	Topics > Messages view	OIDC on self-managed	Admin access only, per TD Bank	$2,880 plus quoted subscription
6	Conduktor	67	Console on PostgreSQL; Gateway proxy in the data path	Per-viewer masking, cross-team access requests	70+ event types with user, in the UI	Browse and filter	LDAP, OIDC	Per user or group, most permissive grant wins	$122,880; $212,880 with Gateway Core and Protect

No tool meets every column, and insurers commonly pair a management tool for people with broker ACLs or an authorizer for services.

The tools, ranked for insurers

What insurers need from a Kafka management tool

This page is about insurers and reinsurers: life, health, motor and property insurers, reinsurers, and the in-house IT companies and broker platforms that run their systems. For banks that run Kafka as shared infrastructure for many business lines, see best Kafka management tools for banks, and for the regulation-by-regulation view across banks, payments and insurance, see best Kafka governance tools for financial services.

At an insurer, Kafka usually carries the messages between quote, policy, claims and customer systems, and between the insurer and its partners. A Rockset announcement from December 2022 describes Allianz Direct, a direct insurer in the Allianz Group, building real-time pricing, customer 360 views and fraud analytics on streaming data from Confluent Cloud, with teams building their own data products. A review of Kpow from an engineer on a project at Vhi describes a chain of applications that each consume a message and publish the next one, with external teams such as Salesforce and Cerner listening to the output, spread across five or six environments from development and training to production. When a message goes missing, arrives late or carries the wrong data, an engineer has to find it by its business reference across several topics, and that is the work a management tool is used for most days.

The quote, policy and claim messages in those topics carry names, addresses, payment details and, at a health or life insurer, medical information, which Article 9 of the GDPR treats as a special category of personal data. Engineers still need to read production topics during an incident, so the tool has to grant that access for the task and take it away afterwards, mask the sensitive fields, and record who read what.

The third requirement comes from regulation: the Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to insurance and reinsurance companies in the EU since 17 January 2025, and it asks them to manage ICT third-party risk and keep a register of information on their ICT third-party arrangements. Any Kafka tool goes through that review, and a tool that runs inside the insurer’s environment, keeps no data outside its clusters and adds nothing between applications and brokers is a smaller entry than a hosted service or a proxy that every quote and claim service has to connect through.

Each of the six criteria this page scores comes from one of those needs, and each has a detail that general lists of Kafka tools leave out.

Out of the data path. A management tool reaches a cluster in one of two ways: as an ordinary Kafka client beside the applications, or as a proxy that every producer and consumer connects through. Kai Waehner’s review of Kafka proxies lists what the second design costs: an extra network hop on every request, a component that has to be deployed highly available or it becomes a single point of failure, and a wider blast radius for a misconfiguration because control is centralised. The same review is clear about what a proxy buys, which is encryption, audit and policy applied to every client without changing the applications. Conduktor is built on that trade, with its field encryption, masking of the data itself, policy enforcement on client traffic and Virtual Clusters running through Conduktor Gateway, a proxy, while Conduktor Console connects to clusters directly, masks in its own UI and needs a PostgreSQL database. Kpow gives people RBAC, masking in inspection, temporary access, tenants and an audit log without putting anything in front of the brokers, and it does not attempt to enforce policy on applications, so the trade runs in both directions. For an insurer the difference shows up in the DORA register, because Article 28(3) of DORA asks for a register of every contractual arrangement on ICT services that separates the ones supporting critical or important functions from the rest, and a component that every quote and claim service connects through is harder to place outside those functions than a console engineers open to inspect a topic. The footprint matters for change control as well, because Claritev, a healthcare technology company that sits between insurers, providers and members and runs Kafka for claims processing, soaks each upgrade for a month in every environment before it reaches production, and at that pace a tool that upgrades by swapping one container image is a smaller change to carry through than one with a database of its own to upgrade alongside it.

Production access on request. AWS’s guidance on temporary elevated access separates persistent access, where an authorised user can invoke access at any time, from just-in-time access, where each use is tied to a business reason and granted for a limited time, and Microsoft Entra Privileged Identity Management applies the same model with time-bound, approval-based role activation. Kafka has no equivalent of its own, because a Kafka ACL allows or denies an operation for a principal on a resource and carries no end time, so on Kafka a grant that expires has to come from the management tool. The rules insurers answer to describe the same control, since Article 9(4)(c) of DORA asks financial entities to limit logical access to information assets to what is required for legitimate and approved functions and activities only, and for companies licensed under New York’s Insurance Law, 23 NYCRR 500.7 requires that privileged accounts are used only when a function needs them and that all access privileges are reviewed at least once a year. A grant that names one action on one topic and expires on its own, such as inspect on a claims topic for one hour, satisfies both and leaves no standing account for the yearly review to find. Masking is the other half of this criterion, and it has to be applied on the server, because a field that is hidden only in the browser is still in the response; the OWASP API Security Top 10 lists relying on the client to filter sensitive data as excessive data exposure.

Audit trail per person. A Kafka ACL names a principal, and when people work through a shared tool that principal is the tool’s service account, so the broker’s own records cannot say which engineer read a claim. The NORD/LB case study describes the same gap at a bank, which had no separation between human and technical users until each person signed in to the tool under their own identity and the tool applied that person’s permissions to the technical user. Regulators ask for that record as well, since 23 NYCRR 500.6 requires audit trails designed to detect and respond to cybersecurity events, and the HIPAA audit controls standard covered in the FAQ below asks a health plan to record and examine activity in systems that hold health information. In both cases a log of topic changes alone is not enough, because the access in question is usually a read.

Inspecting topic data. Search that only matches a complete value fails during an incident, because the engineer rarely has the whole identifier. The NORD/LB case study describes payloads with 10-digit partner IDs and schemas of more than 10,000 lines of JSON, where exact-match search left engineers copying payloads into a text editor to search by hand, and a claim or policy document is a payload of the same kind. The first report in an incident is also often that Kafka lost a message, and inspection is how a platform team checks it. In one of the four incidents in a talk on Kafka operational issues, the first complaint was that Kafka had lost messages, and inspecting the topic showed they were still there and had never been read. Inspection also has a part in erasure, because when a policyholder asks for their data to be erased under Article 17 of the GDPR, a record on a compacted topic is removed by writing a tombstone, a record with the same key and an empty value, and Apache Kafka’s design documentation explains that earlier records for the key go when the log cleaner next compacts the segment in the background, not when the tombstone is written. A null written through a JSON serializer is not a tombstone, as the guide to deleting records in Kafka notes, so checking the topic afterwards is how a team confirms the erasure took effect.

Directory and Kafka sign-in. This criterion covers two layers that are often confused: how the tool authenticates to the brokers and how people sign in to the tool. Apache Kafka’s security overview lists the first layer as SSL or SASL with GSSAPI (Kerberos), PLAIN, SCRAM or OAUTHBEARER, and Kerberos belongs to that layer. People sign in through SAML, OpenID Connect or LDAP, and the reason to insist on the directory is the leaver process. 23 NYCRR 500.7 also requires access to be terminated promptly after a departure, and a tool that keeps its own local accounts sits outside the process that does this, while a tool that reads roles from directory groups loses a person’s access when the directory does.

Many teams, shared clusters. Apache Kafka’s multi-tenancy documentation treats a cluster shared by several tenants as a designed mode of operation, isolated with topic naming, authentication and ACLs, and quotas, so an insurer does not need a cluster for each application team or integration partner to keep them apart. What a reviewer needs is segregation that can be shown, and permissions alone do not provide it, because RBAC answers what a person may do and not what they should see, and the totals and cluster views a partner sees also have to match what that partner is allowed to see. In Kpow each tenant sees a cluster view built only from its own topics and consumer groups, with totals such as writes per second and disk recomputed for that tenant.

What insurers use Kpow for

Seven businesses in insurance that run Kpow are named here: a health insurer, a direct insurer, a reinsurer, a life insurer, an insurer’s in-house IT company, a broker network and an identity protection business. Only one of them has described its use in public, through an engineer’s review on AWS Marketplace of a project at Vhi, so that card describes how Kpow is used and is tagged with the rubric criteria its evidence speaks to. The other six cards carry public information about the company itself, not a description of its Kpow setup.

How an insurer runs its Kafka with Kpow

The workflows below are how an insurer’s platform and application teams put Kpow to work across their Kafka clusters. Each one is built from documented Kpow features, and the Vhi review describes several of them in daily use.

Install it beside the clusters. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, inside the insurer’s own network. It connects to the brokers as an ordinary Kafka client with the same cluster security settings as any other client, and it needs no external database, because snapshots, metrics and the audit log are held in topics on the insurer’s own clusters. Quote, policy and claim services keep talking to the brokers directly. Kpow gets only the access that the cluster’s ACLs grant its own principal, and its minimum ACLs are documented, so a security team can apply least privilege to the tool itself. The server of any Kafka UI holds broker credentials, which makes it a sensitive system in its own right: GitHub Security Lab’s research into an open-source Kafka UI found instances running without authentication on internal networks and exposed to the internet, so whichever tool an insurer picks belongs on an internal network behind directory sign-in. Kafka data stays in the insurer’s environment unless the insurer connects one of Kpow’s optional AI features to a hosted model provider.

Put every environment in one view. One instance connects to self-managed Apache Kafka, Confluent Platform, Confluent Cloud and Amazon MSK together, up to 12 clusters, so development, test, training, pre-production and production clusters sit side by side and an engineer picks the environment before searching.

Trace one quote, policy or claim through the applications. When a message goes missing between two applications, an engineer opens data inspect, selects the topics the message passes through, sets a time window, and filters by key, value or header with kJQ, for example on the message’s unique reference. kJQ follows jq, a filter language many engineers already use for JSON, with the differences documented, so there is no proprietary query syntax to learn before an incident. The search runs on the server, so nobody writes a throwaway consumer against production, and the query itself lands in the audit log. The schema view shows the structure each payload should have, and in a test environment data produce sends a corrected message so the team can see how the next application handles it.

Onboard each team with its own tenant. When a new application team or integration partner needs access, the platform team adds a tenant scoped to that team’s topics, consumer groups and connectors, and maps the team’s directory group to a role through LDAP or SAML with Microsoft Entra ID. RBAC then sets Allow, Deny or Stage per action and resource, with Deny winning where policies overlap, so production can stay read-only for everyone outside the operations team.

Grant production access for one task. An engineer who needs to inspect a production topic raises a request in the insurer’s change system. Once it is approved, that system calls the Kpow API to create a temporary policy that grants inspect access on the named topics for an hour or two. The policy expires on its own, is capped at seven days by default, and is recorded in the audit log. TD Bank’s platform team describes this pattern in its talk on running Kafka at bank scale: an engineer fills in a ServiceNow form, the form calls the Kpow API, and inspect access arrives within a minute for an hour or two, which gives the bank an audit trail of every grant.

Mask policyholder and health fields. Data policies redact names, policy numbers, payment details and medical fields in Data Inspect and ksqlDB results on the server, so an engineer tracing a claim sees its structure and status without the policyholder’s personal data. The policies are built to fail securely, in OWASP’s term: if a schema changes and a masked string field becomes a nested object, Kpow falls back to redacting the whole field, and the plain String deserializer is removed from data inspect while policies are configured, because reading a structured message as raw text would bypass the redaction. An insurer that encrypts payloads itself can load its own custom SerDes so authorised users read the decrypted data while it stays encrypted on the brokers, which is how TD Bank’s platform team describes reading its message-level encrypted topics in the same talk.

Hold risky changes for a second person. With staged mutations, a role can be set to Stage on actions such as resetting a consumer group’s offsets or deleting a topic, so the request waits in Kpow until an administrator approves or denies it, and the full history lands in the audit log. Offset changes have a timing problem of their own, because Apache Kafka’s operations guide says to make sure the consumer instances are inactive before a group’s offsets are reset, which on the command line means running the reset in the gap after the consumers stop. In Kpow an offset change is scheduled and applied once the group is empty, which suits replaying a batch of claim messages after a fix, where the team wants the reset agreed and visible before the consumers are stopped.

Keep the record of who did what. The audit log records each action, data inspect queries included, with the user from the insurer’s directory and the policy that allowed it. Kpow shows the last seven days in the product and writes the record to the __oprtr_audit_log topic on the insurer’s own cluster, where Kpow’s topics default to one week of retention, so for a longer record webhooks send mutations, data inspect queries or both to Slack, Microsoft Teams or any endpoint the insurer chooses, such as its SIEM.

Watch lag during batch loads. Data loads, such as moving records off a legacy system, push large volumes through Kafka at once, and the Vhi review describes checking lag on a topic during them. Kpow publishes consumer group offsets and lag, with broker, topic and connector metrics, on Prometheus endpoints for Prometheus, Grafana, New Relic or the insurer’s own monitoring, so the owning team sees a consumer falling behind before downstream systems do. Lag counted in offsets says how many messages a group is behind and not how long, and SoftwareMill’s analysis of lag monitoring points out that the same figure can mean seconds or hours, so during a load the sign of trouble is lag that stops falling, not lag that is large. Healthy pods are also not the same as a healthy Kafka cluster, as the Claritev case study describes: Kubernetes reported every pod healthy and Prometheus raised no alert while one broker was out of sync, and the broker view in Kpow showed which one.

Govern Flink jobs the same way. Insurers that run Apache Flink beside Kafka for pricing or fraud scoring can put the same directory sign-in and Allow, Deny or Stage policies over their Flink jobs with Flex.

Keep broker ACLs for services. Kpow governs people working through Kpow, not services connecting to brokers, so broker ACLs or an authorizer remain the control for quote, policy and claim applications. Its masking is set per resource and not per viewer. Lenses’ SQL is a stronger query model than kJQ for analysts who think in SQL. One instance manages up to 12 clusters, so a larger fleet runs more than one instance.

To see these screens before installing anything, the live Kpow demo needs no signup and shows data inspect with kJQ, consumer groups, topic management and the audit log topic on two MSK clusters. A reader can check the rubric against the product there by running a kJQ search across topics, following a consumer group’s lag, and opening the __oprtr_audit_log topic on MSK Secondary to see what the audit trail records. The demo has no SSO and no data policies configured, so sign-in and masking are the two things to test in the insurer’s own environment. To run the workflows against the insurer’s own clusters, install Kpow from its container image or JAR; tenants, RBAC, temporary policies, staged mutations, masking and the audit log are Kpow Enterprise features, and Community Edition is free for 3 clusters and 10 users.

Kpow Data Inspect searching three topics at once with one kJQ filter. The topics in this demo carry airline baggage events; an insurer filters its quote, policy and claim topics the same way.

Kpow live demo

Trace a message through Kafka the way an insurer's engineers would

The live Kpow demo needs no signup. Filter topic data with kJQ across several topics, follow consumer groups and lag on two clusters, then read the audit trail on the __oprtr_audit_log topic of the MSK Secondary cluster.

For platform and application teams running Kafka under quote, policy and claim systems.

Try the Kpow demo→

FAQ

What is the best Kafka tool for an insurer?

On this page’s rubric, Kpow: it runs as one container with no external database and nothing in the data path, grants time-boxed production access through its API, masks policyholder fields in inspection, records every action and data query with the person from the insurer’s directory, searches message content across topics with kJQ, and scopes teams with tenants. Kafbat UI is the strongest free option, but it has no expiring access grants, no tenants and no view of its audit trail. For a small team that only needs to browse, search and manage topics, Kpow Community Edition is free for 3 clusters and 10 users, without the governance features scored here.

How do insurers use Kafka?

Kafka carries the messages between quote, policy, claims, billing and customer systems, and out to partners. A Rockset announcement describes Allianz Direct building real-time pricing, customer 360 views and fraud analytics on streaming data from Confluent Cloud, and an engineer on a project at Vhi describes a chain of applications whose output external teams such as Salesforce and Cerner consume. That is why a management tool for insurers has to find one message by its business reference across topics, and control who reads the personal data in them.

Does DORA apply to an insurer’s Kafka tooling?

DORA does not name Kafka or any technology. It has applied to insurance and reinsurance companies in the EU since 17 January 2025 and asks them to manage the risk of their ICT third-party providers and keep a register of those arrangements, so a Kafka management tool is part of that review. A tool that runs inside the insurer’s environment, needs no external database and sits outside the data path gives the shortest answer to what the provider can see and what fails if it does.

Does HIPAA apply to a US health insurer’s Kafka tooling?

A health plan is a covered entity under HIPAA (45 CFR 160.103), and the Security Rule’s audit controls standard (45 CFR 164.312(b)) asks it to record and examine activity in information systems that contain or use electronic protected health information. HIPAA does not name Kafka or any tool, but where member and claim messages carry health information through Kafka, a management tool that records each data inspect query with the person who ran it, masks health fields and grants production access for a task is easier to show against that standard than one that only logs a shared service account.

How can an engineer trace one claim or policy message across Kafka topics?

Search the topics on the server instead of writing a consumer. In Kpow, data inspect takes several topics at once, narrows the search to a time window and filters by key, value or header with kJQ, for example on the message’s unique reference, and the query is recorded in the audit log with the person who ran it. Data policies can mask the policyholder’s personal fields in the results.

Does New York’s cybersecurity regulation apply to an insurer’s Kafka tooling?

23 NYCRR Part 500 applies to companies that operate under a licence granted under New York’s Banking Law, Insurance Law or Financial Services Law (section 500.1), which includes insurers licensed in the state. It does not name Kafka or any tool. Section 500.7 asks a covered entity to limit access privileges to what a person’s job needs, to use privileged accounts only when a function requires them, to review all access privileges at least once a year and to end access promptly after a departure, and section 500.6 asks for audit trails designed to detect and respond to cybersecurity events. For Kafka that points to directory sign-in, production access that is granted for a task and expires, and an audit log that names the person.

How does an insurer erase a policyholder’s data from a Kafka topic?

It depends on the topic’s clean-up policy. On a compacted topic, the record is removed by producing a tombstone, a record with the policyholder’s key and an empty value, and Apache Kafka removes the earlier records for that key when the log cleaner next compacts the segment, so the erasure is not immediate. A null written through a JSON serializer is not a tombstone and deletes nothing. On a topic with time-based retention the records leave when retention expires, or sooner if the partition is truncated to an offset. Inspecting the topic afterwards is how the team confirms that the data is gone, and deleting records in Kafka covers each method.

Do insurers need a different Kafka tool from banks?

The tool can be the same, but the priorities differ. This page weights the rubric for insurers, where most of the daily work is tracing messages between applications and partners across many environments, so it weights inspecting topic data as heavily as production access and audit, and drops the on-prem plus cloud criterion that the banking page scores. The financial services page maps each regulation to a Kafka control.

How these tools were scored

Six criteria, each taken from a situation insurers have described in public or face under DORA and GDPR, score every option from 0 to 10. They are listed here in order of weight; the weights add up to 11, so the total is out of 110.

1. Out of the data path. A management tool that runs in the insurer’s own environment, connects as an ordinary Kafka client and keeps no data outside the insurer’s clusters adds nothing between the insurer’s services and its brokers and gives the shortest answer when the insurer asks which third parties can see its policyholder data. Scored lower: tools that need an external database, 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 several databases or a component on the brokers 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. 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. Can an engineer be given read access to a production topic for a task, approved and time-boxed, without a standing grant? Can production changes such as offset resets be held for a second person’s approval? And is personal and health data masked for the people who do get in? The wider set of controls over deletes and offset resets is compared in Kafka destructive operations tools, and masking in best Kafka data masking tools.

3. Audit trail per person. When people work through a shared tool, the broker only sees the tool’s service account, so only the tool’s own log can name the person. An insurer needs that log to include data reads as well as changes, so it can show who looked at a claim as well as who changed a topic, and to be readable without building a consumer first. Kafka audit logging tools compares the layers in detail.

4. Inspecting topic data. Tracing a quote, policy or claim means finding specific messages by key, value or header across several topics, on the server, without writing a consumer against production. SQL over topics scores highest, filtered search across topics next, and browsing or filtering one topic at a time a point lower. Best Kafka message search tools covers search in detail.

5. Directory and Kafka sign-in. People should sign in through the insurer’s directory, whether that is LDAP directly or SAML and OIDC in front of Active Directory or Entra ID, with directory groups mapped to roles. On the cluster side the tool has to connect the way the insurer’s clusters already authenticate clients, whether that is SASL, Kerberos or mutual TLS. Kafka SSO tools covers the protocol detail.

6. Many teams, shared clusters. Application teams and integration partners share a handful of clusters across several environments, so each team needs to be scoped to its own topics, consumer groups and connectors, and the platform team should onboard a team with a policy rather than a cluster. Reaching cloud and on-prem clusters from one deployment is not scored here; best tools to manage multiple Kafka clusters from one place compares it.

The cost figures model an insurer running 4 clusters (development, test, pre-production and production) for 100 engineers at $120 an engineer-hour, and each card prints its own assumptions. The general listicle view, without the insurance weighting, is in best Kafka management tools.

F1 What an insurer runs into, and what the Kafka tool has to do about it

What happens at an insurer What the Kafka tool has to do

Third-party review Under DORA, insurers and reinsurers manage the risk of every ICT third-party provider and keep a register of those arrangements Run inside the insurer's own environment as a Kafka client, with no external database and no vendor proxy

Tracing a message A quote, policy or claim message passes through a chain of applications and partner integrations, and an engineer has to find where it stopped Search message content across topics on the server, by a business key and a time window, without writing a consumer

Personal and health data Production topics carry policyholder details, claims and, at a health insurer, medical information Grant read access for the task and let it expire, mask sensitive fields, and hold risky changes for a second person

Who did what Security and audit ask who read or changed production data, and when Log each action and data query with the person from the directory, readable without building a consumer

Many teams and environments Application teams and integration partners share clusters across development, test, training, pre-production and production Scope each team to its own topics, consumer groups and connectors, with directory groups mapped to roles

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, Inspecting topic data 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 because DORA has applied to insurers and reinsurers in the EU since January 2025 and asks them to manage the risk of every ICT third-party provider, so a tool that sits between applications and brokers puts one more component on the path that quote, policy and claim messages take, and a tool that keeps its state in a database of its own is one more system to run and to clear through that review. Production access and the per-person audit trail count twice, because production topics carry personal and health data, and the two questions a security team asks are who could read it and who actually did. Inspecting topic data also counts twice, because tracing one quote, policy or claim message through a chain of applications and partners is the work an insurer's engineer describes doing most in the one public account of Kpow at an insurer. Directory 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 67 it would tie for fourth with Lenses.

Related reading

• Kafka: the complete guide
• Best Kafka governance tools for financial services
• Best Kafka management tools for banks
• Best Kafka message search tools
• Best Kafka data masking tools
• Best tools to manage multiple Kafka clusters from one place