Kafka Plugin

TLS settings location

TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.

Basic accessibility observation

Resource overviews show accessible, inaccessible, or access unknown independently of metric sources. Successful access does not attest healthy membership, replication, partitions, or workloads; use domain diagnostics and alerts for those conditions. Existing liveness/readiness fields are domain evidence and do not drive the single core-owned access alarm. Unknown observations do not resolve firing incidents.

TLS

Enable skip_verify in connection settings to retain TLS encryption without verifying the server certificate. It defaults to false and does not require a CA when enabled. Mutual TLS still requires a client certificate and key when requested by the server. Keep CA-based verification enabled when server identity must be authenticated. The setting also applies to SASL OAuth token HTTPS requests.

Overview combines four compact health values, three traffic trends in one row, and total/maximum managed consumer lag (9 panels; 7 without managed collection). Other views also separate instant summaries from trends: quorum/runtime values share a compact row, Raft and latency trends use four columns, and broker or consumer-partition comparisons retain room for labels. Consumer count stays compact.

Detailed latency and runtime trend rows start collapsed. Topic-size and partition-lag/offset charts retain full width. When consumer charts are empty, inspect collection and export failures separately: collection success alone does not prove delivery.

Interpreting chart values

Broker state is a localized Kafka lifecycle name, not a quantity. Raft state is read from the active state label. Unknown codes and missing labels stay unknown; different node observations remain visible as multiple/conflicting values rather than an arbitrary numeric maximum. Normal Raft leader/follower roles can differ between nodes; a mixed-role summary alone does not mean a cluster fault. Raft current leader uses a node ID: 0 is valid and -1 means unknown. Controller count sums observed active controllers, so two simultaneous active controllers are not displayed as one.

Latency p50/p75 panels show the maximum broker quantile for each request class, not the percentile of all cluster requests. Broker traffic totals take precedence over per-topic observations for the same broker, including when the total is 0. Scrape availability requires explicit successful JMX scrape evidence for every observed broker; it does not describe broker lifecycle health.

Apply recommended mapping version kafka-prometheus-v2. Replace a saved jvm_gc_time_count panel with jvm_gc_time_rate (ms/s) and jvm_gc_collections_rate (collections/s). The former mixed-unit logical key is unsupported; other saved panel identity/layout and source binding are preserved by the common personalization contract. Counts and offsets use integer precision; percentages, bytes and rates retain meaningful decimals without trailing zeros.

The old process_cpu_load and process_cpu_load_by_node panels also require replacement. CPU cores (core-s/s) measures consumed CPU time: 1 means one fully used core, with no fixed maximum. JVM CPU capacity usage (percent) instead measures the fraction of all CPU capacity available to the JVM runtime (0–100%). The latter rejects unsupported negative values and offers separate mean and per-node panels. The two sources cannot substitute for one another.

The Kafka plugin registers an Apache Kafka cluster as one Konduo resource and exposes broker, controller, topic, partition, and consumer group state as operational evidence.

Highlights

• Uses bootstrap servers as seeds and validates broker listeners and cluster id from Kafka metadata.
• Exposes KRaft/controller roles, broker inventory, topic/partition state, consumer group lag, and offset evidence.
• Connects JMX/exporter-style metrics through a Prometheus mapping pack.
• In mixed collection mode, broker metrics stay external while Konduo collects consumer group lag through the Kafka Admin API.

Aggregate heap and open-file-descriptor percentages require a positive, matching limit for every included broker. Missing or invalid counterparts leave the aggregate as no data rather than reporting a partial-broker percentage.

Before Registration

• Prepare bootstrap servers, security protocol, SASL, TLS, and timeout settings.
• Confirm that advertised broker listeners are reachable from the Konduo backend.
• For managed consumer group lag collection, prepare Admin API access and a remote-write target.
• When Prometheus is the remote-write target, run Prometheus with --web.enable-remote-write-receiver.

Operations Tips

• A down bootstrap broker does not always mean the whole cluster is unavailable if discovered broker endpoints still work.
• Read consumer lag with total lag, max lag, member state, and offset movement together.
• Zero lag does not establish a healthy consumer: empty groups report an empty_group warning, or no_committed_offsets when partition offsets are absent. Empty groups with positive lag remain errors.
• Topic partition changes, reassignment, throttles, ACLs, and quotas run behind permission and confirmation boundaries.
• Message search is an operational helper. Even when scanning a whole topic, keep rate limiting and cancellation in mind; it is not a bulk export or ETL substitute.
• When inspecting transactional messages, distinguish read_committed from the full visibility mode. read_committed shows committed transactional records and non-transactional records only.

Operator Views

• The broker inventory shows node id, listener, KRaft role, controller state, partition and replica counts, data size, and cordon state together.
• The topic view brings partition count, replica factor, internal-topic status, config, ACLs, and message search/produce jobs into one operational surface.
• The reassignment view calculates broker drain, rebalance, and replica-change plans as dry runs before showing expected data movement and target brokers.
• The consumer group view distinguishes classic consumer groups, share groups, Connect, Schema Registry, and similar group kinds so lag and member state are easier to interpret.
• The security view exposes SCRAM users, ACLs, quotas, delegation tokens, and transactional id evidence within the operator permission boundary.
• Message view, streaming, and search expose a transaction visibility option. Selecting read_committed excludes aborted or still-uncommitted transactional records while non-transactional records remain visible.
• Topic detail exposes related ACLs and active producer evidence for the selected topic. Active producer evidence helps narrow transaction incidents by producer id/epoch, coordinator epoch, last sequence, and current transaction start offset.
• The Transactional ID view shows transactional id state, coordinator, and producer id evidence with row details, navigation to related ACLs, and active-transaction action workflows.
• SCRAM user rows can navigate to the ACL list for that principal, and creating ACLs from that context pre-fills the principal.

Message Inspection And Production

• Message view, streaming, and search configure key/value deserialization separately from transaction visibility.
• Messages from classic offset commit/group metadata records in __consumer_offsets and transaction metadata in __transaction_state are decoded automatically into group, topic/partition, committed offset, member subscription/assignment, transaction state, and producer details.
• Internal-topic tombstones are distinguished from empty byte values. Parsed keys and values render as complete JSON rather than forced binary strings, while unknown Kafka coordinator record types and malformed messages retain raw key/value hex alongside an explicit decode status.
• read_committed hides aborted or not-yet-committed transactional records. It is useful when validating why a producer reported writes that consumers cannot see.
• Custom single-message production lets the operator provide the key, value, and headers directly. Headers use one key=value entry per line and are produced as entered.
• Template production repeatedly renders built-in schemas or contribution-provided schemas. Operators configure JSON/YAML output, key strategy, message count, rate limit, and dry-run preview together.
• Completed message produce jobs can be cleared from the job queue. This only cleans Konduo job history; it does not delete Kafka topic data.
• Search result payloads expire independently from lightweight job status. A status with result_available=false and result_expired=true means the job is known but its in-memory matches have aged out or were evicted under the aggregate byte limit; it does not mean Kafka messages were deleted.
• Successful produce history has only a short visibility grace because the actual result is already in the Kafka topic. Failed/cancelled diagnostics are retained longer. All job history is process-local and disappears on plugin restart.

Diagnostics And Alerts

• Diagnostics separate broker/controller state, partition safety, under-replicated or offline partitions, consumer lag, reassignment state, and metric coverage.
• Cluster-wide defaults such as min.insync.replicas are evaluated once per Kafka cluster. If brokers report different values, diagnostics show one cluster consistency warning; topic-level overrides are still evaluated per topic.
• Kafka availability is based on metadata and advertised-listener reachability; JMX/exporter metrics are supporting evidence for load and capacity risk.
• Alert rules focus on Kafka-domain risks such as offline partitions, under-replicated partitions, controller anomalies, request-handler pressure, and consumer lag.
• If the metric source is missing or the mapping pack does not match the exporter, the plugin should report unavailable or partial evidence instead of assuming a healthy state.

Management Boundary

• Broker drain and rebalance plans must exclude offline and cordoned brokers from new replica placement.
• Traffic rebalance planning uses only metric evidence scoped to this Kafka resource. When scoped topic or broker evidence is unavailable, the plan is rejected instead of using global metric-source series.
• When Kafka 4.3 or later exposes cordoned.log.dirs=*, drain can cordon the target broker first; uncordon remains an explicit operator action after the broker is empty.
• On Kafka 4.3.1, manually submitted reassignment plans may still target a cordoned broker. Konduo drain/rebalance plans exclude cordoned brokers from new targets, but externally submitted Kafka plans still need operator review.
• If a broker is already empty, drain is no longer useful; if it is cordoned, restore cordon before using it as a placement target again.
• Broker settings whose defaults are null, such as cordoned.log.dirs, should be restored by deleting/resetting the dynamic config entry rather than writing an empty value.
• Message search and produce jobs are operational helpers for a topic, not a replacement for bulk data recovery or stream processing.
• ACL, quota, SCRAM, and delegation-token changes directly affect Kafka security and must stay within RBAC, confirmation, and audit boundaries.

Security And Transaction Analysis

• Topic, consumer group, and transactional id ACL lists appear only when Kafka authorizer APIs are available. Treat permission errors and disabled authorizers differently from a true empty ACL list.
• Read ACL resource name, pattern type, principal, host, operation, and permission together; prefixed or wildcard ACLs can affect resources that do not have a literal ACL row.
• Transactional ID detail changes the available action: active or open transactions can be action candidates, while completed commit/abort states are not abort targets.
• Producer fencing is a strong action that forces out the current producer generation for a transactional id. Use it after confirming application restart, duplicate producer, or transaction hang evidence.

Example Workflows

• Before replacing a broker, inspect the broker inventory for partition/replica counts and data size, then review a broker-drain dry run.
• For consumer delay, compare group state, member count, partition lag, max lag, and recent offset movement.
• Before expanding a topic, compare partition changes, replica factor, broker distribution, and traffic evidence to avoid creating a new imbalance.
• For suspected authentication or authorization issues, inspect principal ACLs, SCRAM state, quotas, and transactional id evidence in that order.
• For suspected stuck transactions, inspect Transactional ID state and producer id, compare topic active producer evidence and related ACLs, then decide whether abort or fencing is appropriate.

---

Kafka Enterprise Overlay

TLS settings location

TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.

Basic accessibility observation

Resource overviews show accessible, inaccessible, or access unknown independently of metric sources. Successful access does not attest healthy membership, replication, partitions, or workloads; use domain diagnostics and alerts for those conditions. Existing liveness/readiness fields are domain evidence and do not drive the single core-owned access alarm. Unknown observations do not resolve firing incidents.

TLS

Enable skip_verify in connection settings to retain TLS encryption without verifying the server certificate. It defaults to false and does not require a CA when enabled. Mutual TLS still requires a client certificate and key when requested by the server. Keep CA-based verification enabled when server identity must be authenticated. The setting also applies to SASL OAuth token HTTPS requests.

Overview combines four compact health values, three traffic trends in one row, and total/maximum managed consumer lag (9 panels; 7 without managed collection). Other views also separate instant summaries from trends: quorum/runtime values share a compact row, Raft and latency trends use four columns, and broker or consumer-partition comparisons retain room for labels. Consumer count stays compact.

Detailed latency and runtime trend rows start collapsed. Topic-size and partition-lag/offset charts retain full width. When consumer charts are empty, inspect collection and export failures separately: collection success alone does not prove delivery.

Interpreting chart values

Broker state is a localized Kafka lifecycle name, not a quantity. Raft state is read from the active state label. Unknown codes and missing labels stay unknown; different node observations remain visible as multiple/conflicting values rather than an arbitrary numeric maximum. Normal Raft leader/follower roles can differ between nodes; a mixed-role summary alone does not mean a cluster fault. Raft current leader uses a node ID: 0 is valid and -1 means unknown. Controller count sums observed active controllers, so two simultaneous active controllers are not displayed as one.

Latency p50/p75 panels show the maximum broker quantile for each request class, not the percentile of all cluster requests. Broker traffic totals take precedence over per-topic observations for the same broker, including when the total is 0. Scrape availability requires explicit successful JMX scrape evidence for every observed broker; it does not describe broker lifecycle health.

Apply recommended mapping version kafka-prometheus-v2. Replace a saved jvm_gc_time_count panel with jvm_gc_time_rate (ms/s) and jvm_gc_collections_rate (collections/s). The former mixed-unit logical key is unsupported; other saved panel identity/layout and source binding are preserved by the common personalization contract. Counts and offsets use integer precision; percentages, bytes and rates retain meaningful decimals without trailing zeros.

The old process_cpu_load and process_cpu_load_by_node panels also require replacement. CPU cores (core-s/s) measures consumed CPU time: 1 means one fully used core, with no fixed maximum. JVM CPU capacity usage (percent) instead measures the fraction of all CPU capacity available to the JVM runtime (0–100%). The latter rejects unsupported negative values and offers separate mean and per-node panels. The two sources cannot substitute for one another.

The Kafka Enterprise overlay adds MCP descriptors and anomaly rule metadata on top of the Community Kafka plugin.

Metric interpretation

Zero lag does not establish a healthy consumer: empty groups report an empty_group warning, or no_committed_offsets when partition offsets are absent. Empty groups with positive lag remain errors.

Aggregate heap and open-file-descriptor percentages require a positive, matching limit for every included broker. Missing or invalid counterparts leave the aggregate as no data rather than reporting a partial-broker percentage.

Highlights

• Exposes monitoring overview, diagnostics, consumer groups, security operations, metrics mapping, and anomaly rules through the MCP catalog.
• Evaluates anomaly rules in declarative_metric mode by resolving Kafka logical metrics through metric-source mappings.
• Mutating workflows such as reassignment, broker drain, replica changes, topic changes, and message actions keep the existing Konduo API, RBAC, and audit boundaries.
• Treats bootstrap addresses as seeds and interprets broker inventory with advertised listener evidence.
• References Community-backed broker cordon, message inspection/production, transactional ID, active producer, and topic/group ACL evidence from MCP and incident-analysis workflows.

Common Uses

1. Inspect Kafka operational state through MCP resources and tools
2. Explore broker, partition, and consumer group state in read-oriented workflows
3. Review the Enterprise anomaly rule catalog
4. Connect dashboards and diagnostics to agent workflows

Before Registration

• Kafka connectivity and permissions follow the Community Kafka plugin settings.
• The MCP gateway and related authorization profile must be enabled before MCP descriptors are usable.
• Anomaly rules operate in environments where the Enterprise analysis engine is enabled.

Operations Tips

• Use MCP tools for operational lookup and analysis assistance; configuration changes should still follow Konduo UI and approved procedures.
• Anomaly rules do not replace alert rules; treat them as supporting signals for correlation and incident analysis.
• For consumer lag analysis, review total lag, max lag, member state, offset movement, and controller state together.
• In message view/search, read_committed excludes aborted or not-yet-committed transactional records, which helps explain producer/consumer visibility differences.
• Messages from classic offset commit/group metadata records in __consumer_offsets and transaction metadata in __transaction_state are decoded automatically into group, topic/partition, committed offset, member subscription/assignment, transaction state, and producer details.
• Internal-topic tombstones are distinguished from empty byte values. Parsed keys and values render as complete JSON rather than forced binary strings, while unknown Kafka coordinator record types and malformed messages retain raw key/value hex alongside an explicit decode status.
• Custom single-message production lets the operator provide the key, value, and headers directly. Headers use one key=value entry per line and are produced as entered.
• Template production repeatedly renders built-in schemas or contribution-provided schemas. Operators configure JSON/YAML output, key strategy, message count, rate limit, and dry-run preview together.
• Completed message produce jobs can be cleared from the job queue. This only cleans Konduo job history; it does not delete Kafka topic data.
• Search result payloads expire independently from lightweight job status. A status with result_available=false and result_expired=true means the job is known but its in-memory matches have aged out or were evicted under the aggregate byte limit; it does not mean Kafka messages were deleted.
• Successful produce history has only a short visibility grace because the actual result is already in the Kafka topic. Failed/cancelled diagnostics are retained longer. All job history is process-local and disappears on plugin restart.
• Kafka 4.3+ drain with cordoned.log.dirs=* improves placement safety, but uncordon remains an explicit recovery action after the broker is empty.

Diagnostics And Alerts

• Diagnostics separate broker/controller state, partition safety, under-replicated or offline partitions, consumer lag, reassignment state, and metric coverage.
• Cluster-wide defaults such as min.insync.replicas are evaluated once per Kafka cluster. If brokers report different values, diagnostics show one cluster consistency warning; topic-level overrides are still evaluated per topic.
• Kafka availability is based on metadata and advertised-listener reachability; JMX/exporter metrics are supporting evidence for load and capacity risk.
• Alert rules focus on Kafka-domain risks such as offline partitions, under-replicated partitions, controller anomalies, request-handler pressure, and consumer lag.
• If the metric source is missing or the mapping pack does not match the exporter, the plugin should report unavailable or partial evidence instead of assuming a healthy state.

Management Boundary

• Broker drain and rebalance plans must exclude offline and cordoned brokers from new replica placement.
• Traffic rebalance planning uses only metric evidence scoped to this Kafka resource. When scoped topic or broker evidence is unavailable, the plan is rejected instead of using global metric-source series.
• When Kafka 4.3 or later exposes cordoned.log.dirs=*, drain can cordon the target broker first; uncordon remains an explicit operator action after the broker is empty.
• On Kafka 4.3.1, manually submitted reassignment plans may still target a cordoned broker. Konduo drain/rebalance plans exclude cordoned brokers from new targets, but externally submitted Kafka plans still need operator review.
• If a broker is already empty, drain is no longer useful; if it is cordoned, restore cordon before using it as a placement target again.
• Broker settings whose defaults are null, such as cordoned.log.dirs, should be restored by deleting/resetting the dynamic config entry rather than writing an empty value.
• Message search and produce jobs are operational helpers for a topic, not a replacement for bulk data recovery or stream processing.
• ACL, quota, SCRAM, and delegation-token changes directly affect Kafka security and must stay within RBAC, confirmation, and audit boundaries.

Operational Scenarios

• Before and after broker drain or rebalance, compare broker inventory, controller state, partition distribution, and metric coverage through MCP or diagnostics routes.
• During drain/rebalance analysis, confirm that offline and cordoned brokers are excluded from new replica targets, and review externally submitted manual reassignment plans separately.
• For consumer-group incidents, distinguish classic groups, share groups, connect, and schema-registry style groups before interpreting lag and member state.
• When security failures are suspected, inspect SCRAM, ACLs, quotas, delegation tokens, and transactional ID evidence in order, then apply changes through audited action routes.
• For suspected stuck transactions, compare Transactional ID state, topic active producer evidence, and related ACLs before deciding whether abort or producer fencing is appropriate.
• If exporter label differences change metric keys at a customer site, use EE mapping pack import/export to adjust the site-specific mapping.

Boundaries

• Kafka topic, ACL, reassignment, and message-producing mutations must keep the existing Konduo API, RBAC, confirmation, and audit boundaries instead of bypassing them through MCP descriptors.
• Kafka 4.3+ cordon evidence and drain/rebalance checks are safety signals; plugin behavior should not hide limitations in Kafka's own reassignment behavior.
• ACL, SCRAM, quota, delegation-token, and transactional-id changes should run through approved action routes and audit logs, not through Enterprise analysis automation.

MCP argument and result contracts

Consumer inventory accepts optional group, its aliases consumer_group and group_id, and case-insensitive search. Security inventory accepts comma-separated scram_users and inventory search filters. Diagnostic detail accepts category, check_key, or check_category; omission selects retention_segments. Mapping-pack resolution describes target selection and its aliases. Diagnostic summary and detail also describe topics, topic, and topic_names selection. The anomaly rule tool accepts {}.

Argument-bearing routes retain compatible dynamic filters where the plugin passes an open query filter map; the advertised properties describe useful inputs without removing existing aliases. Unknown fields are rejected for explicitly argument-free tools.

Results contain route-specific diagnostic evidence, vendor inventory, optional fields, and availability states. These dynamic result shapes intentionally omit outputSchema; clients should inspect the returned structured content and status rather than assume a fixed success-only result. Tools and resources use the same instance scope, authorization, and masking. Resource-only catalogs remain available through resources/read; tools-only clients can inspect tool-backed operational routes but need resource support for the remaining metadata catalogs.