Goal

Allowing system collections (or any collection) to grow indefinitely is a sure fire way to run out of disk space or cause slow startup/recovery due to large indices.  In the below example, the system_logs collection has grown very large.

So it's a best practice to think about how to keep these collection sizes in check.

Out of the box, Fusion includes some jobs specifically for this purpose, but their initial settings may not be the best for your current solution and environment.

Also, other collections that you create, like the Signals collections, will need jobs added to keep them from growing indefinitely.

Note: It's not covered here, but be sure to check the "Run" schedules of these jobs so that they run at regular intervals.

Environment

All Fusion versions.  Examples here are from Fusion 4.2.6.  The specific UI's and default values may be different in later versions, but the general concept is the same.

Guide

delete-old-job-history (REST CALL)

The setting of most interest is the REQUEST ENTITY (AS STRING) setting.  Out of the box, it's set to delete job history more than 30 days old.  To change it to something like 14 days, just change the setting to:

<root><delete><query>timestamp_dt:[* TO NOW-14DAYS] AND type_s:history</query></delete><commit /></root>

Also, this is the likely the best deletion job template to keep signals collections from growing too large.  To keep only 3 months of data, you'd create a new "REST Call" job, then name and configure it similar to:

delete-old-system-logs (Log Cleanup)

By default, this is set to keep the system_logs collection entries for 30 days.  That's probably longer than needed for most environments.  Just adjust the DELETE LOGS OLDER THAN N DAYS to whatever you feel is appropriate.

It's also important to realize that this just affects the "system_logs" collection -- not the logs that are written directly to the file system.

delete-old-system-metrics (REST Call)

Uses the same type of job as the "delete-old-job-history" job.  By default it also keeps 30DAYS of system-metrics.  These are low level metrics like service stops and JVM garbage collection.