# Kafka 4.3 adds log-directory cordoning and storage metrics > Kafka 4.3 adds controls for log-directory placement and retention visibility, alongside deprecations that operators should map to existing dashboards. Canonical URL: https://www.devobs.io/news/news-kafka-430-cordon-storage-metrics/ By: Maya Chen Published: 2026-09-06T11:58:54.645Z Updated: 2026-09-06T11:58:54.645Z Event date: 2026-05-22 Section: Data Apache Kafka announced 4.3.0 on May 22, adding operational controls and metrics across the broker, clients and stream-processing components. The [release post](https://kafka.apache.org/blog/2026/05/22/apache-kafka-4.3.0-release-announcement/) highlights log-directory cordoning and new topic-partition retention metrics among its changes. ## Storage maintenance becomes more explicit The new `cordoned.log.dirs` configuration prevents new partitions from being placed on selected log directories. Kafka also adds metrics showing how much of a topic-partition's maximum retention is in use. Our analysis is that these features are most useful when connected to an actual maintenance procedure. Preventing new placement is one step in removing capacity; it should not be confused with evidence that existing replicas have moved or that a directory is ready to delete. A rehearsal can compare the intended destination set with actual replica placement before and after a maintenance action. Include a broker restart and a workload that creates new topics, since a configuration that looks correct at rest may be incomplete under change. ## Deprecations affect the surrounding system The announcement deprecates the Scala Streams module and existing MirrorMaker metrics, marking both for removal in Kafka 5.0. Users of the latter are directed to the new metric names. That gives teams a concrete inventory task: identify dashboards, alerts and automation tied to the older names, and verify replacements while both can still be evaluated. A successful broker upgrade does not prove an alert still fires. Start with one storage-maintenance runbook and one MirrorMaker dashboard. Map each observation to its exact configuration or metric, then test the whole workflow against a non-production 4.3 deployment before broad rollout. ## Source references -