Live data storage retention in SEM

10/17/2018 10:28 PM

4/2/2025 10:24 PM

The number of days' worth of live data that the Security Event Manager (formerly Log & Event Manager) database will store varies for every implementation. The information below should help you determine this number for your environment, while also promoting a more detailed understanding of how the database works in general.

Security Event Manager

What the SEM database stores

By default, the SEM appliance allocates up to 230 GB of the 250 GB configured for the SEM virtual appliance. This partition consists of three data stores:

• Alert database (Alert store) - Normalized data storage.
  The Alert store consists of all of the normalized Events/Alerts collected by the SEM manager and SEM agents. Data in this store is compressed at a ratio of 40:1 to 60:1, which equates to an average compression rate of about 95-98%. SEM reports and nDepth queries this store for alert data whenever they are run.
   
• RAW database (Original log store) - Original data storage. Applies only if the original log storage option is enabled for auditing requirements. The original log store is an optional store for original, or RAW, log messages, which is searchable using Log Message queries in nDepth. The data in this store can come from SEM agents or other devices that are logging to the SEM appliance. You can define whether data is sent to this store at the connector level, so connector configurations define devices/logs that are sent to the RAW database. 
   
• Temporary syslog data (Sylog store) or SNMP data log storage – Consists of log data from network devices logging directly to SEM. The syslog store consists of all syslog/SNMP log data that is sent to the SEM appliance. SEM reads and processes the data in real time, and then sends it to the Alert database for long-term storage. SEM stores the original data into files for 50 days in its original format, just in case you need to review it. SEM rotates and compresses the data in the syslog store daily, but can be changed to accommodate high volume devices that may exceed size limits for zipping files. You can configure syslog to rotate the syslog store hourly, and keep 1 to 100 of these log files.

 

Where to Find the Numbers

The primary sources for retention statistics related to how your SEM database is being used:

• Using the SEM Log Storage Widget on the Dashboard
• The Disk Usage Summary

If you do not have a widget you can find the instructions to build one here:  SEM - Create a Widget for Monitoring Log Retention

Disk Usage Summary

When you initially log into your SEM virtual appliance using the vSphere "console" view or an SSH client such as PuTTY, SEM automatically generates a Disk Usage summary. You can also generate an ad hoc Disk Usage summary by running the diskusage command from the cmc::acm# (cmc > appliance) prompt. The two lines to note here are:

• Logs/Data: This figure (read as Logs & Data) represents the total space being utilized by your SEM databases and syslog storage. This value is presented in the percent% (usedG/allocatedG) format, where the percent and amount of disk space used should be 90% (+/- 2%) of the allocated disk space. When the percent reaches 90%, run the Database Maintenance Report to discover the retention period (Database Time Span) for the data in the Alert database.
  
  Note: SEM is designed to maintain the Logs/Data partition at a threshold of 90% full. As new data is inserted into the database beyond 90%, the oldest events are dropped off at regular intervals so that Logs/Data perpetually remains around 90% full. Because of this automated function, manually removing old data to avoid completely filling the partition is unnecessary.

 

• Logs: This figure represents the amount of space being utilized by the syslog store. This figure is included in the used figure noted above.
  
  To figure out how much space is currently being utilized by your Alert store, subtract the logs value from the used value.
  
  Note: If you are storing original log messages in your SEM database, the calculation above will show you the combined space being utilized by both your Alert and original log stores.

 

Alternate Storage Methods

Depending on the needs of your environment, you might want to utilize one or more of the alternate storage methods listed below. For more details or assistance with any of these methods, please open a ticket with Support.

• Backup your SEM virtual appliance Alert database on a regular basis. This will give you offline storage for all of your SEM normalized data stores. Use the ArchiveConfig command to configure the Alert database backups. The first time the database is backed up, the entire Alert database is placed onto a network share. Subsequent backups are incremental/differential backups.
• Backup your SEM virtual appliance RAW database on a regular basis. This will give you offline storage for all of your SEM original data stores. Use the LogMArchiveConfig command to configure the RAW database backups. The first time the database is backed up, the entire RAW database is placed onto a network share. Subsequent backups are incremental/differential backups.
• Typically not configured, you can also backup the Syslog store. Use the LogBackupConfig command to configure the syslog backups. 
• Decrease the number of days for which Syslog/SNMP data is stored on your SEM virtual appliance. Use the SSH/PuTTY commands (setlogrotate and limitsyslog) to adjust the storage space used.
• Increase the space allocated to your SEM virtual appliance - see Resize a SEM Virtual Appliance.
• Typically not needed, but you can deploy another SEM virtual appliance to be used as a syslog server. Contact SolarWinds support to configure this appliance for the Syslog role.
• Typically not needed, but you can deploy another SEM virtual appliance to be used as a database server. Contact SolarWinds support to configure this appliance for the database role.