This post was originally written in September 2018 and was updated in March 2025.

MongoDB logs are essential for tracking operations and troubleshooting, but left unmanaged, they can quickly consume valuable disk space and even impact database performance. Proactively managing log file size through automated rotation is crucial for maintaining a healthy system. This blog post will guide you through the best—and simplest—methods for automating MongoDB log rotation, ensuring your logs remain useful and manageable without constant manual intervention.

Understanding MongoDB log files and rotation needs

In MongoDB, the log is not rotated automatically, so we need to rotate it manually. Usually, the log size of the MongoDB server depends on the level of information configured and the slow log configured. By default, commands taking more than 100ms, or whatever the value set for the slowOpThresholdMs parameter, are written into the MongoDB log file. Let’s see how to automate log rotation on Linux-based servers.

Methods for MongoDB log rotation: logRotate command vs. system utility

Using the MongoDB logRotate Command

The following two methods could be used to rotate the log in MongoDB. The first uses the command shown below from within mongo shell:

Using the SIGUSR1 Signal for Log Rotation

The alternative is to use SIGUSR1 signal to rotate the logs for a single process in Linux/Unix-based systems:

The systemLog.logRotate Parameter (Rename vs. Reopen)

The behavior of log rotation in MongoDB differs according to the value of the parameter logRotate which was introduced in version 3.0 (note that this should not be confused with the logRotate command that we’ve seen above). The two values are:

  • rename – renames the log file and creates a new file specified by the logpath parameter to write further logs
  • reopen – closes and reopens the log file following the typical Linux/Unix log rotation behavior. You also need to enable logAppend if you choose reopen. You should use reopen when using the Linux/Unix log rotate utility to avoid log loss.

In versions 2.6 and earlier, the default behavior when issuing the logRotate command is the same as when using rename, i.e. it renames the original log file from mongod.log to mongod.log.xxxx-xx-xxTxx-xx-xx format where x is filled with the rotation date time, and creates a new log file mongod.log to continue to write logs. You can see an example of this below:

Using the above method, we need to compress and move the rotated log file manually. You can of course write a script to automate this. But when using the logrotate=reopen option, the mongod.log is just closed and opened again. In this case, you need to use the command alongside with Linux’s logrotate utility to avoid the loss of log writing in the course of the log rotation operation. We will see more about this in the next section.

Automating MongoDB log rotation with the Linux logrotate utility

I wasn’t a fan of this second method for long time! But MongoDB log rotation seems to work well when using Linux/Unix’s logrotate tool. Now I prefer this approach, since it doesn’t need the complex script writing that’s needed for the first log rotation method described above. Let’s see in detail how to configure log rotation with Linux/Unix’s logrotate utility.

MongoDB 3.x versions

Start MongoDB with the following options:

As mentioned in the section about Linux’s logrotation utility, you need to create a separate config file /etc/logrotate.d/mongod for MongoDB’s log file rotation. Add the content shown below into that config file:

In this config file, we assume that log path is set as /var/log/mongodb/mongod.log in /etc/mongod.conf file, and instruct Linux’s logrotation  utility to do the following:

  • Check the size, and start rotation if the log file is greater than 100M
  • Move the mongod.log file to mongod.log.1
  • Create a new mongod.log file with mongod permissions
  • Compress the files from mongod.log.2 but retain up to mongod.log.10 as per delaycompress and rotate 10
  • MongoDB continues to write to the old file mongod.log.1 (based on Linux’s inode) – remember that now there is no mongod.log file
  • In postrotate, it sends the kill -SIGUSR1 signal to mongod mentioned with the pid file, and thus mongod creates the mongod.log and starts writing to it. So make sure you have the pid file path set to the same as pidFilepath from the /etc/mongod.conf file. If you have multiple mongod instances running in the same server, passing with pid file is recommended. Else you can also use $(pidof mongod) command to fetch the pid of mongod instance. i.e “/bin/kill -SIGUSR1 $(pidof mongod)”

Please test the logrotate manually using the created /etc/logrotate.d/mongod file to make sure it is working as expected. Here’s how:

 

Adaptations for MongoDB 2.x and earlier, or when using logRotate=rename

Since the introduction of logRotate parameter in MongoDB 3.0, the log rotate script needs an extra step when you are using logRotate=rename or when using <=2.x versions.

Start the MongoDB with the following options (for 2.4 and earlier, ) :

Start MongoDB with the following options YAML format (YAML config introduced from version 2.6) :

The config file /etc/logrotate.d/mongod for MongoDB’s log file rotation should be set up like this:

In this case, the logrotate utility behaves as follows:

  • Check for the size, and start rotation if the log file size exceeds 100M
  • Move mongod.log file to mongod.log.1
  • Create a new mongod.log file with mongod permissions
  • MongoDB continues to write to the old file, mongod.log.1
  • In postrotate, when the SIGUSR1 signal is sent, mongod rotates the log file. This includes renaming the new mongod.log file (0 bytes) created by logrotate to mongod.log.xxxx-xx-xxTxx-xx-xx format and creating a new mongod.log file to which, now, mongod starts writing the logs.
  • the Linux command find  identifies mongod.log.xxxx-xx-xxTxx-xx-xx file formats that are sized at 0 bytes, and these are removed

MongoDB Alternative

FAQs: Automating MongoDB log rotation

Q1: Why is MongoDB log rotation necessary?
A: MongoDB log rotation is necessary to prevent log files from growing indefinitely, which can consume excessive disk space, make log analysis difficult, and potentially impact database performance as it writes to very large files. Regularly rotating logs keeps file sizes manageable.

Q2: What are the main ways to rotate MongoDB logs?
A: There are two primary methods: 1) Using MongoDB’s internal logRotate administrative command (triggered via mongo shell or SIGUSR1 signal), whose behavior depends on the systemLog.logRotate parameter (rename or reopen). 2) Using an external system utility like the Linux logrotate tool, which typically works best with MongoDB’s systemLog.logRotate set to reopen.

Q3: What does the systemLog.logRotate: reopen option do and why use it with the logrotate utility?
A: When systemLog.logRotate is set to reopen (and logAppend is true), signaling mongod (usually with kill -SIGUSR1) causes it to close and reopen its log file handle. This is designed to work seamlessly with the Linux logrotate utility, which renames the current log file (mongod.log becomes mongod.log.1) and creates a new empty mongod.log. The SIGUSR1 signal in the postrotate script tells mongod to start writing to this newly created empty file.

Subscribe
Notify of
guest

3 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Darshan Jrshan

nicely documented, well explained with commands,Thanks Vinod,

0
Reply
bhargav

Two things i observed

1) Manually working by logrotate -f /etc/logrotate.d/mongod command but when actual log getting full its not create *log.1 or gz.
2) File naming which have shown in tutorial quite confusing
a) you said “/etc/logrotate.d/mongod.conf” but when you have given content for editing file it has logrotate-mongod.conf name but when you test actually it has logrotate -f /etc/logrotate.d/mongod

1
Reply
Wernfried Domscheit

Instead of
kill -SIGUSR1 cat /var/run/mongodb/mongod.pid 2>/dev/null
better use
kill -SIGUSR1 pidof mongod
then the pid-file is not relevant.

2
Reply