A customer asked a great question about YugabyteDB Anywhere (YBA).
- Is it possible to specify a log path for the YBA platform?
My first answer focused on the installer’s default layout. YBA puts application.log under <installRoot>/data/logs, and the documented separate-disk setup applies to the entire data directory. That’s a bigger change when all you want is a new home for one log file.
I went back to see how YBA Installer builds the platform configuration. I found a setting worth trying and tested it on a fresh install of YBA 2026.1.2.0-b137 to see where the running process would write.
Demo: Move the active application log
This demo uses the default yugabyte service account and runs the commands as root. A fresh YBA installation is enough to reproduce it. The platform generates its own log activity without a YugabyteDB universe.
1. Find the default application log
yba-ctl status
The platform row before the change, with unrelated columns omitted:
Systemd service | Version | Log Files | Running Status
yb-platform | 2026.1.2.0-b137 | /opt/yugabyte/data/logs/application.log | Running
To see the default file’s current contents:
tail -n 10 /opt/yugabyte/data/logs/application.log
2. Create a directory the platform can write to
install -d -m 0750 -o yugabyte -g "$(id -gn yugabyte)" \
/var/log/yugabyte-platform
runuser -u yugabyte -- test -w /var/log/yugabyte-platform &&
echo "Log directory is writable"
Use the account set by service_username if you changed it at install time. If you’re using a separate filesystem, mount it first and make sure it’s available when YBA starts. On a host with SELinux enforcement, the service also needs permission under the host’s policy.
3. Edit the existing platform.additional setting
The setting I found was log.override.path. It tells the YBA platform which directory to use for application.log. To apply it through YBA Installer, add it under platform.additional in yba-ctl.yml.
cp -p /opt/yba-ctl/yba-ctl.yml /opt/yba-ctl/yba-ctl.yml.before-log-path
vi /opt/yba-ctl/yba-ctl.yml
In the demo config, additional: "" appeared near the end of the platform: section, just above the PostgreSQL section. Replace that line with the following block, matching the indentation of the other platform settings.
additional: |
log.override.path="/var/log/yugabyte-platform"
additional: |, the YAML pipe treats the indented lines as a block of text. The log.override.path line uses HOCON (Human-Optimized Config Object Notation), the format YBA uses for its platform configuration. YBA Installer appends that text to the generated yb-platform.conf.If additional already contains settings, add the HOCON line to the existing block. YBA Installer uses this YAML setting when it regenerates the platform configuration.
4. Apply the change
yba-ctl reconfigure
On this build, reconfiguration restarted the installer-managed services and waited for the YBA API to become ready. Schedule the change for a maintenance window on a shared instance. YBA Installer reconfiguration docs
I checked the generated config to see what the installer passed to the platform:
grep -nF 'log.override.path' \
/opt/yugabyte/software/2026.1.2.0-b137/yb-platform/conf/yb-platform.conf
Outout:
3:log.override.path="/opt/yugabyte/data/logs"
182:log.override.path="/var/log/yugabyte-platform"
The installer writes its default first and appends platform.additional later in the file. For these two string values, HOCON uses the later assignment.
5. Verify where the running platform writes
pid=$(systemctl show -p MainPID --value yb-platform.service)
ls -l "/proc/$pid/fd" | grep -F 'application.log'
head -n 10 /var/log/yugabyte-platform/application.log
tail -n 10 /var/log/yugabyte-platform/application.log
Selected lines from the live output:
l-wx------. 1 yugabyte yugabyte 64 Nov 9 04:40 579 -> /var/log/yugabyte-platform/application.log
YW 2026-11-09T04:37:34.620Z [INFO] from DefaultDBApi in main - Database [default] initialized
YW 2026-11-09T04:37:34.624Z [INFO] from HikariCPConnectionPool in main - Creating Pool for datasource 'default'
YW 2026-11-09T04:45:43.038Z [INFO] f50d7e6e-86fe-4fff-b8de-7a3fe68e90ab from Scheduler in platform-scheduler-2 - Running scheduler
The process held the custom file open for writing. The first lines show database initialization during startup, and the tail shows scheduler activity eight minutes later.
yba-ctl status? On YBA 2026.1.2.0-b137, the status row derives its log path from installRoot, so it continues to display /opt/yugabyte/data/logs/application.log after a restart. In this demo, yba-ctl reconfigure restarted yb-platform, and the new process wrote startup and scheduler records to /var/log/yugabyte-platform/application.log. Check the running process’s open file and look for fresh records to verify the active path.Revert the change
Remove the log.override.path line from platform.additional. If it was the only entry, you can restore additional: "". Run yba-ctl reconfigure again and use the same file-descriptor check to verify that the platform has reopened the default path. Existing logs stay in the directories where they were written.
This demo verified the active log relocation on one YBA build. Test archive rollover and the rollback procedure separately on your build before a production rollout. PostgreSQL, Prometheus, and installer logs have their own paths and settings.
Moving the full data directory or shipping logs
- ● Put all YBA data on a separate disk. Mount a dedicated filesystem at
<installRoot>/data. This puts the entire data subtree on that filesystem, including PostgreSQL data, Prometheus data, and the logs stored there. The installer docs cover both fresh installations and reuse of an existing YBA data disk. Stand-alone data disk - ● Send platform logs to a central system. Point a file-log collector at the active
application.logpath to ship copies off the host. YBA’s Export logs feature covers universe YSQL query and audit logs. Universe log export
Final thoughts
So, can you give the YBA platform’s application.log its own directory? Yes, on YBA 2026.1.2.0-b137. Set log.override.path in platform.additional and apply it with yba-ctl reconfigure.
Before calling the change done, check which file the running platform has open and look for fresh entries there. On the build I tested, yba-ctl status still showed the default path after the restart.
Have Fun!
Heading to the Distributed SQL Summit in Salt Lake City? Hope to see you there!