kafka.broker.config.num_partitions

The kafka.broker.config.num_partitions metric is a gauge that reports the configured default number of partitions that will be created when a new topic is created without an explicitly specified partition count. This broker-level configuration parameter, defined by the num.partitions property in Kafka's broker configuration, serves as a fallback value and plays a crucial role in determining the initial parallelism and scalability characteristics of newly created topics. As a configuration metric rather than a runtime performance metric, it provides visibility into the cluster's default partitioning strategy, which directly impacts throughput capabilities, consumer parallelism, and the distribution of data across the broker cluster. Understanding this value is essential for capacity planning and ensuring consistency across topic creation patterns, particularly in environments where topics are created programmatically or by multiple teams without explicit partition specifications.

From an operational perspective, monitoring this metric helps ensure consistency across broker configurations in a cluster and prevents misconfiguration that could lead to suboptimal topic designs. The healthy range for this value depends heavily on workload characteristics, cluster size, and expected throughput requirements, though typical production deployments often configure values between 3 and 12 partitions as a reasonable default. Apache Kafka's documentation on topics and partitions emphasizes that partition count directly affects parallelism—more partitions enable higher throughput and more concurrent consumers, but also increase overhead in terms of file handles, memory, and replication traffic. Organizations should monitor this metric to detect configuration drift across brokers, as inconsistent values in a cluster can lead to unpredictable behavior when topics are created against different brokers.

Common troubleshooting use cases include investigating performance issues with newly created topics that may have insufficient partitions for the intended load, or auditing cluster configurations during capacity planning exercises. Alerts on this metric are typically configured to detect unexpected changes in the default partition configuration or to flag discrepancies between brokers in the same cluster, which could indicate configuration management issues. When combined with metrics tracking actual topic partition counts and consumer lag, this configuration metric helps operators understand whether default settings align with actual usage patterns and whether they should be adjusted to better match organizational needs for new topic creation.