Analytics consent
We use Google Analytics for basic traffic stats. kafkahelper stores no cluster data, config input, or personal data in the app.
Client validator
Use this page for producer and consumer properties only. The rules focus on delivery guarantees, retries, batching, timeout posture, and client observability.
Critical
2
Warnings
5
Info
2
`acks` is below `all`, so the producer can treat a write as successful before enough replicas confirm it.
Recommended change: Set `acks=all` for production producers unless you are explicitly trading durability for latency.
Why: Leader-only acknowledgement leaves a wider failure window during broker loss, ISR shrink, or leader election.
The producer can duplicate records during retries because idempotence is turned off.
Recommended change: Set `enable.idempotence=true` and keep compatible retry and in-flight settings.
Why: Transient network or broker failures often trigger retries. Without idempotence, those retries can duplicate business events.
The producer is configured to give up quickly after retriable failures.
Recommended change: Increase `retries` substantially and validate that `delivery.timeout.ms` is large enough to make those retries useful.
Why: Short outages, throttling, and leader movement are normal enough in Kafka that very small retry counts become noisy application failures.
`linger.ms` is zero, which pushes the producer toward more tiny requests.
Recommended change: Try a small positive value such as `5` to `20` ms if throughput matters more than the last few milliseconds of latency.
Why: A modest linger window usually improves compression and batch efficiency without materially changing user-visible latency in most back-end pipelines.
The producer will fill and send relatively small batches per partition.
Recommended change: Consider increasing `batch.size` if your workload is throughput-oriented and record sizes justify it.
Why: Small batches increase request count, network overhead, and broker CPU for the same amount of data.
Messages are being sent uncompressed.
Recommended change: Use `lz4` or `zstd` when possible for a better balance of throughput and network efficiency.
Why: Compression often reduces network, broker disk, and page cache pressure enough to outweigh the added CPU cost.
The producer allows many in-flight requests while idempotence is not clearly enabled.
Recommended change: Enable idempotence and keep `max.in.flight.requests.per.connection` at 5 or lower.
Why: Retries across many concurrent requests increase the chance that late successes arrive after later sends, which complicates ordering guarantees.
A `client.id` is not set, so broker metrics and logs are less useful for tracing this workload.
Recommended change: Set a stable `client.id` per service or traffic source.
Why: Named clients make quota debugging, throttling analysis, and broker request tracing much easier.
The config does not explicitly state which security protocol the client expects.
Recommended change: Set `security.protocol` deliberately so environment defaults do not surprise you.
Why: Being explicit helps prevent painful mismatches between local testing, staging, and production clusters.
