Introduction

When ZooKeeper is bundled with a Kafka distribution, its error logs are not determined by zoo.cfg alone. The real destination comes from the logging configuration used at startup, which is usually a Log4j properties file referenced by the Kafka or ZooKeeper launch script.

Separate Data Directories from Log Output

A common source of confusion is mixing ZooKeeper data directories with application log files. In zoo.cfg, dataDir and dataLogDir control snapshots and transaction logs, not necessarily human-readable error logs.

1# zoo.cfg
2clientPort=2181
3dataDir=/var/lib/zookeeper/data
4dataLogDir=/var/lib/zookeeper/txnlog

Those paths matter for ZooKeeper state, but stack traces and runtime error messages normally go wherever the logging framework sends them.

Check the Log4j Configuration Used at Startup

Kafka distributions that include ZooKeeper typically ship a logging configuration file such as config/log4j.properties or a ZooKeeper-specific variant. That file defines whether logs go to the console, to a rolling file, or both.

1zookeeper.root.logger=INFO, ROLLINGFILE
2
3log4j.appender.ROLLINGFILE=org.apache.log4j.RollingFileAppender
4log4j.appender.ROLLINGFILE.File=/var/log/zookeeper/zookeeper.log
5log4j.appender.ROLLINGFILE.MaxFileSize=100MB
6log4j.appender.ROLLINGFILE.MaxBackupIndex=10
7log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
8log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d %-5p [%t] %c: %m%n

In that example, ZooKeeper error messages end up in /var/log/zookeeper/zookeeper.log.

Look at the Startup Script and Runtime Environment

The effective log destination may also be controlled by the script that launches ZooKeeper. Kafka startup scripts often export JVM options or point to a specific logging file.

bin/zookeeper-server-start.sh config/zookeeper.properties

Inspect the script or wrapper service definition for values such as KAFKA_LOG4J_OPTS, LOG_DIR, or a system property pointing to a custom Log4j config. On systems using systemd, logs may also be redirected to journald instead of to a file.

grep -R "KAFKA_LOG4J_OPTS\|LOG_DIR" bin config
systemctl cat zookeeper
journalctl -u zookeeper

That is often the fastest way to discover the real runtime destination.

Console Logging Is Still Logging

Some packaged setups write ZooKeeper logs only to standard output or standard error. In that case, the destination depends on how the process is launched. If started in a terminal, the logs go to that terminal. If started by a service manager, they may be captured by the service manager.

This is why there is no one universal path such as /tmp/zookeeper.log. The answer is deployment-specific.

Verify the Destination from the Running Process

If you have shell access, trigger a known log event or inspect open files for the ZooKeeper JVM.

ps -ef | grep zookeeper
lsof -p <pid> | grep log

That helps when the configuration files suggest one destination but the running process has been overridden by environment variables or service wrappers.

In Newer Kafka Deployments, ZooKeeper May Not Even Be Present

Modern Kafka clusters can run in KRaft mode without ZooKeeper. If you are troubleshooting a current environment, first confirm that ZooKeeper is part of the deployment before looking for its logs.

That does not change the answer for ZooKeeper-based setups, but it does prevent time being wasted on a component that no longer exists in the architecture.

Common Pitfalls

• Looking in dataDir for error logs even though it stores snapshots and transaction data instead.
• Assuming Kafka distributions always log ZooKeeper to the same file path across all environments.
• Forgetting that startup scripts or service managers can override the shipped Log4j settings.
• Ignoring standard output and journald when no rolling file appender is configured.
• Troubleshooting ZooKeeper logs in a Kafka deployment that actually runs in KRaft mode without ZooKeeper.

Summary

• ZooKeeper error log destination is usually defined by the logging configuration, not by zoo.cfg.
• Check the Log4j properties file and the startup script together.
• Distinguish state directories such as dataDir from human-readable runtime logs.
• Verify whether logs are going to a file, the console, or a service manager.
• Confirm the deployment actually uses ZooKeeper before searching for its logs.