Search the VMware Knowledge Base (KB)
View by Article ID

Safely cleaning up log files in vRealize Operations 6.x (2145578)

  • 1 Ratings

Purpose

This purpose this article is to provide safe procedure to reclaim disk space consumed by logs in vRealize Operations 6.x.

Note: Increase in the disk space might cause upgrade to fail or stop the cluster services.

Resolution

Note: Please take a snapshot or backup before attempting any of the steps provided here.

It is generally inadvisable to delete log files from a running system, as it can cause issues with file permissions, missing directories, and other unfulfilled expectations of the services writing them. However, space can be reclaimed by marking the files as 0 bytes via the truncate command.

By combining truncate with the find command, you can ensure that only older log files are reduced in size to have their space reclaimed.

For example:

find /storage/log/ -mount -type f -mtime +1 -exec echo {} \; -exec truncate -cs 0 {} \; 2>&1 | tee /tmp/files_truncated.txt

Here is a breakdown of the find options:
  • /storage/log/
    • This is the data volume where all logs are kept.
  • -mount
    • This prevents find from looking outside the log volume.
  • -type f
    • This prevents find from looking at directories, links, or other special files.
  • -mtime +1
    • This causes find to only look at files that have not been modified in the last 1 day. You can increase or remove this value as desired.
  • -exec echo {} \;
    • This prints file paths that are discovered so that you can see affected files.
  • -exec truncate -cs 0 {} \;
    • This truncates the file that is discovered to be 0 bytes.
  • 2>&1 | tee /tmp/files_truncated.txt
    • This records all output of this command to a file at /tmp/files_truncated.txt
You can also add something like -iname *log* to the find command between -mtime and -exec to limit the search to only log files. However, this omits other files from being truncated such as heap dumps and gemfire replay data that generally take up more space than the log files do, if they exist.

After running the truncation, you should bring the cluster services down and back up through the Admin UI to ensure that everything is working properly.

Impact/Risks

  • Running the truncation command removes all history of your logs, which may contain useful information about other issues that may be present, and present a challenge to VMware support if you open a request with them. 
  • Logs only take up space on one of three data volumes. If you are having free space issues relating to one of the other volumes getting full, truncating log data does not help you. 
  • Do not run a truncation of files on any of the other data volumes, as it may cause irrecoverable damage to your system and loss of historical data.
  • Because truncation leaves empty files behind, inodes in the filesystem remains consumed. This is not typically an issue, as most files are named in a manner that is subject to rolling out (and thus are finite in number), and because vRealize Operations is tuned to allow significantly more inodes than most common Linux systems. If you find that after truncation and a full restart of the cluster services you have a stable system, you can use find to locate all 0-byte files and remove them. While relatively safe, this is not recommended unless you are actually running out of inodes. You can check this by running the command df -i.

See Also

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 1 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)




Please enter the Captcha code before clicking Submit.
  • 1 Ratings
Actions
KB: