After you have deployed your cluster in production, there are some tools and best
practices to keep your cluster running in good shape. This section talks about
configuring settings dynamically, changing logging levels, partition reassignment
and deleting topics.
Logging
Apache Kafka® emits a number of logs. The location of the logs depends on the packaging
format - kafka_logs_dir
will be in /var/log/kafka
in rpm/debian and $base_dir/logs
in the archive format. The default logging level is INFO
. It provides a moderate
amount of information, but is designed to be rather light so that your logs are
not enormous.
When debugging problems, particularly problems with replicas falling out of ISR,
it can be helpful to bump up the logging level to DEBUG
.
The logs from the server go to logs/server.log
.
You could modify the log4j.properties
file and restart your nodes — but that
is both tedious and leads to unnecessary downtime.
Controller
Kafka elects one broker in the cluster to be the controller. The controller is
responsible for cluster management and handles events like broker failures,
leader election, topic deletion and more.
Since the controller is embedded in the broker, the logs from the controller are
separated from the server logs in logs/controller.log
. Any ERROR
, FATAL
or WARN
in this log indicates an important event that should be looked at by
the administrator.
State Change Log
The controller does state management for all resources in the Kafka cluster. This
includes topics, partitions, brokers and replicas. As part of state management,
when the state of any resource is changed by the controller, it logs the action
to a special state change log stored under logs/state-change.log
. This is
useful for troubleshooting purposes. For example, if some partition is offline
for a while, this log can provide useful information as to whether the partition
is offline due to a failed leader election operation.
Note that the default log level for this log is TRACE
.
Request logging
Kafka has the facility to log every request served by the broker. This includes
not only produce and consume requests, but also requests sent by the controller
to brokers and metadata requests.
If this log is enabled at the DEBUG
level, it contains latency information
for every request along with the latency breakdown by component, so you can see
where the bottleneck is. If this log is enabled at TRACE
, it further logs
the contents of the request.
We do not recommend you set this log to TRACE
for a long period of time as
the amount of logging can affect the performance of the cluster.
Admin operations
This section covers the various admin tools that you can use to administer a Kafka
cluster in production. There are still a number of useful operations that are not
automated and have to be triggered using one of the tools that ship with Kafka
under bin/
Adding topics
You have the option of either adding topics manually or having them be created
automatically when data is first published to a non-existent topic. If topics
are auto-created then you may want to tune the default topic configurations used
for auto-created topics.
Topics are added and modified using the topic tool:
bin/kafka-topics --bootstrap-server localhost:9092 --create --topic my_topic_name \
--partitions 20 --replication-factor 3 --config x=y
The replication factor controls how many servers will replicate each message that
is written. If you have a replication factor of 3, then up to 2 servers can fail
before you will lose access to your data. We recommend you use a replication factor
of 2 or 3 so that you can transparently restart machines without interrupting data
consumption.
The partition count controls how many logs the topic will be sharded into. There
are several impacts of the partition count. First each partition must fit entirely
on a single server. So if you have 20 partitions the full data set (and read and
write load) will be handled by no more than 20 servers (no counting replicas).
Finally the partition count impacts the maximum parallelism of your consumers.
The configurations added on the command line override the default settings the
server has for things like the length of time data should be retained. The complete
set of per-topic configurations is documented here.
Modifying topics
You can change the configuration or partitioning of a topic using the same topic tool.
To add partitions you can do
bin/kafka-topics --bootstrap-server localhost:9092 --alter --topic my_topic_name \
--partitions 40
Be aware that one use case for partitions is to semantically partition data, and
adding partitions doesn’t change the partitioning of existing data so this may
disturb consumers if they rely on that partition. That is if data is partitioned
by hash(key) % number_of_partitions then this partitioning will potentially be
shuffled by adding partitions but Kafka will not attempt to automatically redistribute
data in any way.
To add configs:
bin/kafka-configs --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name my_topic_name --add-config x=y
To remove a config:
bin/kafka-configs --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name my_topic_name \
--deleteConfig x
Note that Kafka does not currently support reducing the number of partitions for a topic.
Deleting topics
You can also delete a topic using the topic tool:
bin/kafka-topics --bootstrap-server localhost:9092 --delete --topic my_topic_name
Graceful shutdown
The Kafka cluster will automatically detect any broker shutdown or failure and elect
new leaders for the partitions on that machine. This will occur whether a server
fails or it is brought down intentionally for maintenance or configuration changes.
For the later cases Kafka supports a more graceful mechanism for stoping a server
then just killing it. When a server is stopped gracefully it has two optimizations
it will take advantage of:
- It will sync all its logs to disk to avoid needing to do any log recovery when
it restarts (i.e. validating the checksum for all messages in the tail of the
log). Log recovery takes time so this speeds up intentional restarts.
- It will migrate any partitions the server is the leader for to other replicas
prior to shutting down. This will make the leadership transfer faster and
minimize the time each partition is unavailable to a few milliseconds.
Syncing the logs will happen automatically happen whenever the server is stopped
other than by a hard kill, but the controlled leadership migration requires using
a special setting: controlled.shutdown.enable=true
Note that controlled shutdown will only succeed if all the partitions hosted on
the broker have replicas (i.e. the replication factor is greater than 1 and at
least one of these replicas is alive). This is generally what you want since
shutting down the last replica would make that topic partition unavailable.
Rolling restart
If you need to do software upgrades, broker configuration updates, or cluster
maintenance, then you will need to restart all the brokers in your Kafka cluster.
To do this, you can do a rolling restart by restarting one broker at a time.
Restarting the brokers one at a time provides high availability by avoiding
downtime for end users.
Some considerations to avoid downtime include:
- Use Confluent Control Center to monitor broker status during the rolling restart.
- Because one replica is unavailable while a broker is restarting, clients will not experience downtime if the number of remaining in sync replicas is greater than the configured
min.insync.replicas
.
- Run brokers with
controlled.shutdown.enable=true
to migrate topic partition leadership before the broker is stopped.
- The active controller should be the last broker you restart. This is to ensure that the active controller is not moved on each broker restart, which would slow down the restart.
Before starting a rolling restart:
- Verify your cluster is healthy and there are no under replicated
partitions. In Control Center, navigate to Overview of the
cluster, and observe the Under replicated partitions value. If
there are under replicated partitions, investigate why before doing
a rolling restart.
- Identify which Kafka broker in the cluster is the active controller.
The active controller will report
1
for the following
metric
kafka.controller:type=KafkaController,name=ActiveControllerCount
and the remaining brokers will report 0
.
Use the following workflow for rolling restart:
Connect to one broker, being sure to leave the active
controller for last, and stop the broker process gracefully.
Do not send a kill -9
command. Wait until the broker has
completely shutdown.
Tip
These instructions assume you are installing Confluent Platform by using ZIP or TAR archives. For more information, see On-Premises Deployments.
If you are performing a software upgrade
or making any system configuration changes, follow those
steps on this broker. (If you are just changing broker
properties, you could optionally do this before you stop the broker)
Start the broker back up, passing in the broker properties
file.
bin/kafka-server-start etc/kafka/server.properties
Wait until that broker completely restarts and is caught up before
proceeding to restart the next broker in your cluster. Waiting is
important to ensure that leader failover happens as cleanly as
possible. To know when the broker is caught up, in Control Center,
navigate to Overview of the cluster, and observe the
Under replicated partitions value. During broker restart, this
number increases because data will not be replicated to topic
partitions that reside on the restarting broker.
After a broker restarts and is caught up, this number goes back to its original
value before restart, which should be 0
in a healthy cluster.
Repeat the above steps on each broker until you have restarted all brokers
but the active controller. Now you can restart the active controller.
Scaling the Cluster
Adding servers to a Kafka cluster is easy, just assign them a unique broker ID and
start up Kafka on your new servers. However these new servers will not automatically
be assigned any data partitions, so unless partitions are moved to them they won’t
be doing any work until new topics are created. So usually when you add machines
to your cluster you will want to migrate some existing data to these machines.
Other common reasons for migrating data are decommissioning of brokers and
rebalancing data across the cluster (when it becomes unbalanced).
The process of migrating data is manually initiated but fully automated. Under the covers, when Kafka moves a partition, it will add a new replica on the destination machine
as a follower of the partition it is migrating. The new replica is allowed to replicate and when it is fully
caught up, it will be marked as in-sync. Then one of the existing replicas on the original server will be deleted, completing the move.
Confluent Platform includes the confluent-rebalancer tool and the open source Kafka kafka-reassign-partitions
tool. The Confluent
Rebalancer has the following advantages:
- Minimises data movement
- Balances data at both cluster and topic level (instead of just topic level)
- Balances disk usage across brokers (in addition to balancing the number of leaders and replicas across racks and brokers)
- Supports decommissioning of broker(s)
- Supports moving partitions away from dead brokers
The confluent-rebalancer is described in a separate page.
The open source partition reassignment tool can run in 3 mutually exclusive modes -
--generate
: In this mode, given a list of topics and a list of brokers, the tool generates a candidate reassignment to move all partitions of the specified topics to the new brokers. This option merely provides a convenient way to generate a partition reassignment plan given a list of topics and target brokers.
--execute
: In this mode, the tool kicks off the reassignment of partitions based on the user provided reassignment plan. (using the --reassignment-json-file
option). This can either be a custom reassignment plan hand crafted by the admin or provided by using the –generate option
--verify
: In this mode, the tool verifies the status of the reassignment for all partitions listed during the last --execute
. The status can be either of successfully completed, failed or in progress
The partition reassignment tool does not have the ability to automatically generate a reassignment plan for decommissioning brokers yet. As such,
the admin has to come up with a reassignment plan to move the replica for all partitions hosted on the broker to be decommissioned, to the rest of
the brokers. This can be relatively tedious as the reassignment needs to ensure that all the replicas are not moved from the decommissioned broker
to only one other broker. As stated previously, the confluent-rebalancer has built-in support for this.
Increasing replication factor
Increasing the replication factor can be done via the kafka-reassign-partitions
tool. Specify the extra replicas in the custom reassignment json file and use
it with the --execute
option to increase the replication factor of the specified partitions. For instance, the following example increases the replication
factor of partition 0 of topic foo from 1 to 3. Before increasing the replication factor, the partition’s only replica existed on broker 5. As part of increasing
the replication factor, we will add more replicas on brokers 6 and 7.
The first step is to hand craft the custom reassignment plan in a json file-
cat increase-replication-factor.json
{"version":1,
"partitions":[
{"topic":"foo",
"partition":0,
"replicas":[5,6,7]
}
]
}
Then, use the json file with the --execute
option to start the reassignment process-
bin/kafka-reassign-partitions --bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --execute
Current partition replica assignment
{"version":1,
"partitions":[
{"topic":"foo",
"partition":0,
"replicas":[5]
}
]
}
Save this to use as the ``--reassignment-json-file`` option during rollback
Successfully started reassignment of partitions
{"version":1,
"partitions":[
{"topic":"foo",
"partition":0,
"replicas":[5,6,7]
}
]
}
The --verify
option can be used with the tool to check the status of the partition reassignment. Note that the same increase-replication-factor.json
(used with the --execute
option) should be used with the --verify
option
bin/kafka-reassign-partitions --bootstrap-server localhost:9092 --reassignment-json-file increase-replication-factor.json --verify
Reassignment of partition [foo,0] completed successfully
You can also verify the increase in replication factor with the kafka-topics
tool:
bin/kafka-topics --bootstrap-server localhost:9092 --topic foo --describe
Topic:foo PartitionCount:1 ReplicationFactor:3 Configs:
Topic: foo Partition: 0 Leader: 5 Replicas: 5,6,7 Isr: 5,6,7
Limiting Bandwidth Usage during Data Migration
Kafka lets you apply a throttle to replication traffic, setting an upper bound on the bandwidth used to move replicas from machine to machine. This is useful when rebalancing a cluster, bootstrapping a new broker or adding or removing brokers, as it limits the impact these data-intensive operations will have on users.
There are three interfaces that can be used to engage a throttle. The simplest, and safest, is to apply a throttle when invoking confluent-rebalancer or kafka-reassign-partitions
, but kafka-configs
can also be used to view and alter the throttle values directly.
So for example, if you were to execute a rebalance, with the below command, it would move partitions at no more than 50 MBps.
bin/kafka-reassign-partitions --bootstrap-server myhost:9092 --execute
--reassignment-json-file bigger-cluster.json —throttle 50000000
When you execute this script you will see the throttle engage:
…
The throttle limit was set to 50000000 B/s
Successfully started reassignment of partitions.
Should you wish to alter the throttle, during a rebalance, say to increase the throughput so it completes quicker, you can do this by re-running the execute command passing the same reassignment-json-file
:
bin/kafka-reassign-partitions --bootstrap-server localhost:9092 --execute
--reassignment-json-file bigger-cluster.json --throttle 700000000
There is an existing assignment running.
The throttle limit was set to 700000000 B/s
Once the rebalance completes the administrator can check the status of the rebalance using the --verify
option. If the rebalance has completed, and --verify
is run, the throttle will be removed. It is important that administrators remove the throttle in a timely manner once rebalancing completes by running the command with the --verify
option. Failure to do so could cause regular replication traffic to be throttled.
When the --verify
option is executed, and the reassignment has completed, the script will confirm that the throttle was removed:
bin/kafka-reassign-partitions --bootstrap-server localhost:9092 --verify
--reassignment-json-file bigger-cluster.json
Status of partition reassignment:
Reassignment of partition [my-topic,1] completed successfully
Reassignment of partition [mytopic,0] completed successfully
Throttle was removed.
The administrator can also validate the assigned configs using the kafka-configs
. There are two pairs of throttle configuration used to manage the throttling process. The throttle value itself. This is configured, at a broker level, using the dynamic properties:
leader.replication.throttled.rate
follower.replication.throttled.rate
There is also an enumerated set of throttled replicas:
leader.replication.throttled.replicas
follower.replication.throttled.replicas
Which are configured per topic. All four config values are automatically assigned by kafka-reassign-partitions
(discussed below).
The throttle mechanism works by measuring the received and transmitted rates, for partitions in the replication.throttled.replicas
lists, on each broker. These rates are compared to the replication.throttled.rate
config to determine if a throttle should be applied. The rate of throttled replication (used by the throttle mechanism) is recorded in the below JMX metrics, so they can be externally monitored.
MBean:kafka.server:type=LeaderReplication,name=byte-rate
MBean:kafka.server:type=FollowerReplication,name=byte-rate
To view the throttle limit configuration:
bin/kafka-configs --describe --bootstrap-server localhost:9092 --entity-type brokers
Configs for brokers '2' are leader.replication.throttled.rate=1000000,follower.replication.throttled.rate=1000000
Configs for brokers '1' are leader.replication.throttled.rate=1000000,follower.replication.throttled.rate=1000000
This shows the throttle applied to both leader and follower side of the replication protocol. By default both sides are assigned the same throttled throughput value.
To view the list of throttled replicas:
bin/kafka-configs --describe --bootstrap-server localhost:9092 --entity-type topics
Configs for topic ‘my-topic' are leader.replication.throttled.replicas=1:102,0:101,follower.replication.throttled.replicas=1:101,0:102
Here we see the leader throttle is applied to partition 1 on broker 102 and partition 0 on broker 101. Likewise the follower throttle is applied to partition 1 on broker 101 and partition 0 on broker 102.
By default kafka-reassign-partitions
will apply the leader throttle to all replicas that exist before the rebalance, any one of which might be leader. It will apply the follower throttle to all move destinations. So if there is a partition with replicas on brokers 101,102
, being reassigned to 102,103
, a leader throttle, for that partition, would be applied to 101,102
(possible leaders during rebalance) and a follower throttle would be applied to 103
only (the move destination).
If required, you can also use the --alter
switch on kafka-configs
to alter the throttle configurations manually.
Some care should be taken when using throttled replication. In particular:
- Throttle Removal:
The throttle should be removed in a timely manner once reassignment completes (by running confluent-rebalancer --finish
or kafka-reassign-partitions -—verify
).
- Ensuring Progress:
If the throttle is set too low, in comparison to the incoming write rate, it is possible for replication to not make progress. This occurs when:
max(BytesInPerSec) > throttle
Where BytesInPerSec is the metric that monitors the write throughput of producers into each broker.
The administrator can monitor whether replication is making progress, during the rebalance, using the metric:
kafka.server:type=FetcherLagMetrics,name=ConsumerLag,clientId=([-.\w]+),topic=([-.\w]+),partition=([0-9]+)
The lag should constantly decrease during replication. If the metric does not decrease the administrator should increase the throttle throughput as described above.
- Avoiding long delays during replication:
The throttled throughput should be large enough that replicas cannot be starved for extended periods. A good, conservative rule of thumb is to keep throttle above #brokers MB/s
where #brokers
is the number of brokers in your cluster.
Administrators wishing to use lower throttle values can tune the response size used for replication based on the relation:
Worst-Case-Delay = replica.fetch.response.max.bytes x #brokers / throttle
Here, the admin should tune the throttle and/or replica.fetch.response.max.bytes
appropriately to ensure the delay is never larger than replica.lag.time.max.ms
(as it is possible for some partitions, particularly smaller ones, to enter the ISR before the rebalance completes) or the outer throttle window: (replication.quota.window.size.seconds x replication.quota.window.num)
or the connection timeout replica.socket.timeout.ms
.
As the default for replica.fetch.response.max.bytes
is 10MB and the delay should be less than 10s (replica.lag.time.max.ms
), this leads to the rule of thumb that throttles should never be less than #brokers MBps .
To better understand the relation let’s consider an example. Say we have a 5 node cluster, with default settings. We set a throttle of 10 MBps, cluster-wide, and add a new broker. The bootstrapping broker would replicate from the other 5 brokers with requests of size 10MB (default replica.fetch.response.max.bytes
). The worst case payload, arriving at the same time on the bootstrapping broker, is 50MB. In this case the follower throttle, on the bootstrapping broker, would delay subsequent replication requests for (50MB / 10 MBps) = 5s, which is acceptable. However if we set the throttle to 1 MBps the worst-case delay would be 50s which is not acceptable.
Balancing Replicas Across Racks
The rack awareness feature spreads replicas of the same partition across
different racks. This extends the guarantees Kafka provides for broker-failure to
cover rack-failure, limiting the risk of data loss should all the brokers on a
rack fail at once. The feature can also be applied to other broker groupings
such as availability zones in EC2.
You can specify that a broker belongs to a particular rack by adding a property
to the broker config:
When a topic is created or modified, or when replicas are redistributed, the
rack constraint will be honored, ensuring replicas span as many racks as they
can. A partition will span the number of different racks, which is a minimum of
#racks and replication-factor.
The algorithm used to assign replicas to brokers ensures that the number of
leaders per broker will be constant, regardless of how brokers are distributed
across racks. This ensures balanced throughput.
However if racks are assigned different numbers of brokers, the assignment of
replicas will not be even. Racks with fewer brokers will get more replicas,
meaning they will use more storage and put more resources into replication.
Hence it is sensible to configure an equal number of brokers per rack.
Caution
Currently, rack awareness cannot be enabled during upgrades. You need to
enable rack awareness before or after the Confluent Platform version upgrade is complete.
Enforcing Client Quotas
Starting in 0.9, the Kafka cluster has the ability to enforce quotas on produce and fetch requests. Quotas are basically byte-rate thresholds defined per client-id. A client-id logically identifies an application making a request. Hence a single client-id can span multiple producer and consumer instances and the quota will apply for all of them as a single entity i.e. if client-id=”test-client” has a produce quota of 10 MBps, this is shared across all instances with that same ID.
Quotas protect brokers from producers and consumers who produce/consume very high volumes of data and thus monopolize broker resources and cause network saturation. This is especially important in large multi-tenant clusters where a small set of badly behaved clients can degrade user experience for the well behaved ones. In fact, when running Kafka as a service quotas make it possible to enforce API limits according to an agreed upon contract.
By default, each unique client-id receives a fixed quota in bytes/sec as configured by the cluster (quota.producer.default
, quota.consumer.default
). This quota is defined on a per-broker basis. Each client can publish/fetch a maximum of X bytes/sec per broker before it gets throttled.
When a broker detects quota violation, it does not return an error. Rather it attempts to slow down a client exceeding its quota. The broker computes the amount of delay needed to bring the quota-violating client under it’s quota and delays the response for that time. This approach keeps the quota violation transparent to clients (outside of client side metrics). This also keeps them from having to implement any special backoff and retry behavior which ensures quotas are enforced regardless of the client implementation. JMX metrics on the client and brokers can reveal when clients are throttled.
Client byte rate is measured over multiple small windows (for e.g. 30 windows of 1 second each) in order to detect and correct quota violations quickly. Typically, having large measurement windows (for e.g. 10 windows of 30 seconds each) leads to large bursts of traffic followed by long delays which is not great in terms of user experience.
It is possible to override the default quota for client-ids that need a higher (or even lower) quota. The mechanism is similar to the per-topic log config overrides.
By default, each client-id receives an unlimited quota. The following sets the default quota per producer and consumer client-id to 10 MBps:
quota.producer.default=10485760
quota.consumer.default=10485760
It is also possible to set custom quotas for each client:
bin/kafka-configs --bootstrap-server localhost:9092 --alter --add-config 'producer_byte_rate=1024,consumer_byte_rate=2048' --entity-name clientA --entity-type clients
Updated config for clientId: "clientA".
Here’s how to describe the quota for a given client:
bin/kafka-configs --bootstrap-server localhost:9092 --describe --entity-name clientA --entity-type clients
Configs for clients:clientA are producer_byte_rate=1024,consumer_byte_rate=2048