Schedule icon
Webhook icon
Assert icon
TopicList icon
Script icon
Loop icon
TopicDescribe icon
Get icon
Set icon
If icon
Pause icon
TopicUpdate icon
Log icon
SlackIncomingWebhook icon

Kafka Topic Dynamic Min In-Sync Replicas and Unclean Leader Election Durability Guard

Remediate Kafka topic durability risks. Audit min.insync.replicas and unclean leader election, track trends in KV, gate updates with Pause, and verify state.

Categories
DataInfrastructure

Production Apache Kafka clusters rely on topic configurations to guarantee data durability and partition integrity. Even when message producers specify acks=all, durability is only guaranteed if the topic configuration requires multiple replicas to confirm receipt before an acknowledgment is returned. When a topic with a replication factor of 3 is provisioned with default min.insync.replicas = 1, the broker permits writes to proceed when only the single partition leader has written the message. If that broker suffers an ungraceful shutdown or hardware failure before replication completes, acknowledged data is silently lost forever.

Furthermore, if unclean.leader.election.enable is set to true, a broker holding an out-of-sync replica can be elected partition leader when the leader fails. This triggers non-recoverable log truncation and permanent message divergence across consumer applications. Manually inspecting hundreds of topics across distributed clusters is error-prone, while static scripts lack multi-run persistence to distinguish transient rolling broker restarts from genuine policy violations.

This blueprint provides an automated durability guard that inspects Kafka topic configurations via the Kafka AdminClient, evaluates live min.insync.replicas and unclean.leader.election.enable settings against operational safety baselines, tracks multi-run violation persistence in Kestra KV, pauses for human approval before mutating cluster state, safely hardens topic settings via TopicUpdate, and verifies post-remediation cluster state.

How it works

  1. Operational Input Validation: The validate_inputs task (io.kestra.plugin.core.execution.Assert) validates bootstrap server connectivity strings, ensures the minimum in-sync replica floor is at least 1, and enforces positive violation thresholds.
  2. Cluster Topic Discovery: The list_topics task (io.kestra.plugin.kafka.TopicList) queries the Kafka broker via AdminClient listTopics to discover all existing topics.
  3. Internal Topic Filtering: A Python task (filter_target_topics) filters out internal system topics (such as __consumer_offsets, _schemas, and transactional state logs) while resolving the target list of user-space topics.
  4. Live Topic Metadata Inspection: A parallel loop (describe_topics) executes io.kestra.plugin.kafka.TopicDescribe against each target topic, retrieving partition counts, replication factors, and effective configuration parameters.
  5. Historical State Retrieval: The get_previous_durability_state task (io.kestra.plugin.core.kv.Get) retrieves historical audit snapshots from Kestra KV store under kafka_topic_durability_guard_state.
  6. Durability Policy Evaluation: A Python script (evaluate_durability_policy) compares live topic configurations against policy floors. It flags topics with min.insync.replicas below safe replication thresholds or with unclean.leader.election.enable: true. The script correlates findings against historical KV state, tracks consecutive violation streaks, and calculates target configuration updates bounded by each topic's replication factor.
  7. Cross-Run State Tracking: The save_durability_state task (io.kestra.plugin.core.kv.Set) updates Kestra KV with recent topic compliance metrics and consecutive violation counters.
  8. Approval-Gated Configuration Hardening: When policy violations persist and dry_run is disabled, the workflow enters pause_for_remediation_approval (io.kestra.plugin.core.flow.Pause) for operator review. Upon resumption, remediate_topics (io.kestra.plugin.kafka.TopicUpdate) applies the hardened configurations to the broker.
  9. Post-Remediation Verification & Incident Reporting: The verify_topics loop re-queries the broker with TopicDescribe, verify_durability_outcome confirms that the updated settings are active on the cluster, complete incident forensics are archived in Kestra KV, and structured alerts are dispatched to Slack.

What you get

  • Automated auditing of min.insync.replicas and unclean.leader.election.enable across all Kafka topics.
  • Protection against silent message loss and partition divergence during broker hardware failures.
  • Multi-run persistence in Kestra KV to avoid false alarms during scheduled broker rolling restarts.
  • Safety-bounded remediation logic that prevents setting min.insync.replicas higher than a topic's replication factor.
  • Operator approval gates and dry-run simulation to review proposed configuration mutations before execution.
  • Post-remediation verification confirming that updated topic configurations are actively enforced by Kafka brokers.
  • Comprehensive KV store audit manifests for compliance tracking and capacity planning.

Who it's for

  • Streaming Platform Engineers and Kafka Administrators managing high-throughput event buses.
  • Site Reliability Engineers (SREs) enforcing data durability and fault tolerance SLOs.
  • Event-Driven Architecture (EDA) teams building critical transactional messaging pipelines.

Why orchestrate this with Kestra

Kafka provides command-line utilities such as kafka-configs.sh to update topics, but lacks built-in mechanisms to audit fleets of topics on a recurring schedule, track historical violation persistence across executions, enforce operator approval gates, or coordinate multi-channel incident notifications. Writing shell scripts or standalone cron jobs creates unmonitored failure points without execution history, secret encryption, or post-change verification.

Orchestrating this guard with Kestra delivers a declarative workflow with native Kafka AdminClient integration, atomic state tracking in Kestra KV, human-in-the-loop pause-and-resume gates, encrypted secrets management, and automated Slack escalation.

Prerequisites

  • An accessible Apache Kafka cluster (version 2.4 or higher) reachable from the Kestra worker.
  • Administrative network access to Kafka bootstrap brokers on port 9092 (or custom plaintext/SSL port).
  • A Slack Incoming Webhook URL to receive durability alerts and incident notifications.

Secrets

  • SLACK_WEBHOOK_URL: Slack Incoming Webhook endpoint URL used for durability violation alerts and error notifications.
  • KAFKA_DURABILITY_GUARD_WEBHOOK_KEY: Secret authentication token protecting the on-demand webhook trigger.

Quick start

  1. Configure SLACK_WEBHOOK_URL and KAFKA_DURABILITY_GUARD_WEBHOOK_KEY in your Kestra namespace secrets.
  2. Import this blueprint and set bootstrap_servers to your target Kafka broker endpoint (e.g. localhost:9092).
  3. Run a manual execution with dry_run: true to record an initial durability baseline and review detected topic configurations.
  4. Set dry_run: false and auto_remediate: true to enable approval-gated automated topic hardening.
  5. Enable the periodic_durability_audit schedule trigger to monitor Kafka topics continuously every 30 minutes.

How to extend

  • Replication Factor Expansion: Combine with partition reassignment tools or Strimzi KafkaRebalance operators to expand single-replica topics before raising min.insync.replicas.
  • PagerDuty Incident Escalation: Integrate io.kestra.plugin.pagerduty.notifications.PagerDutyAlert to page on-call SREs when unclean.leader.election.enable: true is detected on critical transactional topics.
  • Schema Registry Integration: Pair with Confluent or Apicurio schema validation tasks to enforce end-to-end event governance alongside broker storage durability.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.