How to Tame Nacos Access Logs: Reduce Disk Usage and Control Log Levels

Preface

Our company uses a Spring Cloud architecture with Nacos as the service registry. Operations complained about rapid disk consumption caused by exploding log files, which turned out to be Nacos itself.

Event Background

The most voluminous logs are {nacos.home}/logs/access_log.yyyy-mm-dd.log, recording every microservice request to Nacos and inter‑node communication (heartbeat, service list, status checks, etc.). Since Nacos is built on Spring Boot, these are Tomcat access logs without any retention or size limits, so they grow quickly as the number of services increases.

Solution

The access log can be turned off via application.properties in Nacos's conf directory. The default relevant settings are:

#*************** Access Log Related Configurations ***************
### If turn on the access log:
server.tomcat.accesslog.enabled=true

### The access log pattern:
server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D %{User-Agent}i %{Request-Source}i

### The directory of access log:
server.tomcat.basedir=

In a test environment you can simply set server.tomcat.accesslog.enabled=false to stop the logs. In production this is risky because logs are needed for troubleshooting.

As an alternative, a Linux cron job can delete old logs. Example script:

#!/bin/bash

logFile="/data/nacos/bin/logs/nacos_del_access.log"
# Keep logs for 14 days
date=`date -d "$date -14 day" +"%Y-%m-%d"`
# Path to the log file to delete
delFilePath="/data/nacos/bin/logs/access_log.${date}.log"

if [ ! -f "${logFile}" ];then
    echo 'access log file is frequently printed. /etc/cron.daily/nacosDelAccessLogs.sh will delete access logs' >>${logFile}
fi
# Delete if exists
if [ -f "${delFilePath}" ];then
    rm -rf ${delFilePath}
    curDate=`date --date='0 days ago' "+%Y-%m-%d %H:%M:%S"`
    echo "[${curDate}] Deleted file ${delFilePath}" >>${logFile}
fi

While this solves the disk‑space issue, it is not an elegant solution.

Dynamic Log‑Level Adjustment

Before Nacos 1.1.3 the server logged excessively with no way to change levels at runtime. From 1.1.3 onward, log levels can be adjusted via API:

# Set naming‑raft.log to error level
curl -X PUT '$nacos_server:8848/nacos/v1/ns/operator/log?logName=naming-raft&logLevel=error'
# Set config‑dump.log to warn level
curl -X PUT '$nacos_server:8848/nacos/v1/cs/ops/log?logName=config-dump&logLevel=warn'

Client‑Side Logging

Since 1.1.3 the Nacos client also reduces noisy logs (heartbeats, polling, etc.). You can control the client log level in application.yml:

logging:
  level:
    com.alibaba.nacos: warn

Or via JVM arguments (default is info):

-Dcom.alibaba.nacos.naming.log.level=warn -Dcom.alibaba.nacos.config.log.level=warn

These settings apply to Naming and Config clients for versions 1.0.0 and above.

Fine‑Grained Log Configuration

Inspect conf/nacos-logback.xml for detailed logback settings. For example, the default naming-server appender is:

<appender name="naming-server" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_HOME}/naming-server.log</file>
    <append>true</append>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${LOG_HOME}/naming-server.log.%d{yyyy-MM-dd}.%i</fileNamePattern>
        <maxFileSize>1GB</maxFileSize>
        <maxHistory>7</maxHistory>
        <totalSizeCap>7GB</totalSizeCap>
        <cleanHistoryOnStart>true</cleanHistoryOnStart>
    </rollingPolicy>
    <encoder>
        <Pattern>%date %level %msg%n%n</Pattern>
        <charset>UTF-8</charset>
    </encoder>
</appender>

You can adjust the log format, file rotation size, retention days, and compression according to your needs.

Conclusion

Nacos’s default logging can quickly consume disk space, and its configurability is limited. By disabling the Tomcat access log in non‑production, using cron‑based cleanup, leveraging the new API for dynamic log‑level changes, and fine‑tuning logback, you can achieve more efficient log management.