Data Cleaning: Difference between revisions

From VoIPmonitor.org
(Simplify cleanspool docs: Remove legacy mode references (cleanspool_use_files). Cleanspool keeps index in memory, .cleanspool_cache in hourly dirs is for fast restart only.)
(Complete rewrite: Logical structure (fundamentals first, then config, then advanced, then troubleshooting). Remove legacy mode references. Fix formatting. Reduce from 1106 to 386 lines.)
Line 1: Line 1:
This guide explains how VoIPmonitor manages data retention for both captured packets (PCAP files) and Call Detail Records (CDRs) in the database. Proper configuration is essential for managing disk space and maintaining long-term database performance.
This guide explains how VoIPmonitor manages data retention for PCAP files and database records.


== Overview ==
== Overview ==


VoIPmonitor generates two primary types of data that require periodic cleaning:
VoIPmonitor generates two types of data requiring periodic cleanup:
* '''PCAP Files:''' Raw packet captures of SIP/RTP/GRAPH data stored on the filesystem in the spool directory. These can consume significant disk space.
* '''CDR Data:''' Call metadata stored in the MySQL database. Large tables can slow down GUI performance if not managed properly.


The system uses two separate, independent mechanisms to manage the retention of this data:
{| class="wikitable"
|-
! Data Type !! Storage !! Cleanup Mechanism !! Key Parameters
|-
| '''PCAP Files''' || Filesystem (spool directory) || Cleanspool process || <code>maxpoolsize</code>, <code>maxpooldays</code>
|-
| '''CDR Records''' || MySQL database || Partition dropping || <code>cleandatabase</code>
|}


<kroki lang="plantuml">
These are '''independent systems''' - filesystem cleanup does not affect database records and vice versa.
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}
 
rectangle "VoIPmonitor Sensor" as sensor
 
package "Filesystem Storage" {
  folder "/var/spool/voipmonitor" as spool {
    file "SIP PCAPs" as sip
    file "RTP PCAPs" as rtp
    file "GRAPH files" as graph
    file "AUDIO files" as audio
  }
}
 
database "MySQL Database" {
  collections "cdr" as cdr
  collections "cdr_next" as cdrnext
  collections "register_state" as reg
  collections "sip_msg" as sipmsg
  collections "files" as filesdb
}


sensor --> spool : writes
== Filesystem Cleaning (PCAP Files) ==
sensor --> cdr : writes
sensor --> filesdb : indexes files
 
rectangle "Filesystem Cleaner\n(maxpoolsize/maxpooldays)" as fscleaner #E8F5E9
rectangle "Database Cleaner\n(cleandatabase)" as dbcleaner #E3F2FD
 
fscleaner --> spool : deletes old files
fscleaner --> filesdb : reads file index
dbcleaner --> cdr : drops partitions
 
note bottom of fscleaner : Runs every 5 minutes\nDeletes oldest data first
note bottom of dbcleaner : Daily partition drop\nInstant operation
@enduml
</kroki>
 
== Filesystem Cleaning (PCAP Spool Directory) ==
 
The sensor stores captured call data in a structured directory tree on the local filesystem.


=== How Cleanspool Works ===
=== How Cleanspool Works ===


The sniffer keeps the complete file index '''in memory''' during operation. This allows very fast cleaning operations without database queries.
The sniffer maintains a complete file index '''in memory''' during operation. Every 5 minutes, the cleanspool thread checks retention limits and deletes the oldest files when limits are exceeded.
 
The <code>.cleanspool_cache</code> files stored in '''hourly''' directories serve as a persistent cache for '''faster startup after restart''' - they allow the sniffer to quickly reload the file index without scanning the entire directory structure.
 
Example cache location: <code>/var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache</code>


'''Key characteristics:'''
The <code>.cleanspool_cache</code> files in hourly directories (e.g., <code>/var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache</code>) serve as '''persistent storage for fast restart''' - they allow quick index reload without scanning the entire directory structure.
* File index kept entirely in memory - very fast operations
* No MySQL queries needed for file listing
* Cache files enable quick restart without full directory scan
* For recent hours, prefers direct directory reading over cache for accuracy
 
The cleaning process flow:


<kroki lang="plantuml">
<kroki lang="plantuml">
Line 81: Line 32:
collections "Filesystem" as FS
collections "Filesystem" as FS


S -> FS: Write PCAP file\n(into TAR archive)
S -> FS: Write PCAP file
S -> MEM: Update file index
S -> MEM: Update index


... Every 5 minutes ...
... Every 5 minutes ...


C -> MEM: Query oldest files\nwhere age > maxpooldays\nOR total size > maxpoolsize
C -> MEM: Find oldest files exceeding limits
loop For each file to delete
loop For each file to delete
     C -> FS: DELETE file
     C -> FS: DELETE file
Line 92: Line 43:
end
end


note over MEM : Index persisted to\n.cleanspool_cache files\nfor fast restart
note over MEM : Index persisted to\n.cleanspool_cache\nfor fast restart
@enduml
@enduml
</kroki>
</kroki>


'''Verifying cache files exist:'''
=== Retention Configuration ===
<syntaxhighlight lang="bash">
# Find .cleanspool_cache files in hourly directories
find /var/spool/voipmonitor -name ".cleanspool_cache" -type f | head -5
</syntaxhighlight>


==== The maxpool_clean_obsolete Parameter ====
Retention limits can be set by '''size''' (MB) or '''age''' (days). When both are configured, the first limit reached triggers cleanup.


This parameter controls how cleanspool handles files that exist on the filesystem but are NOT in its in-memory index.
==== Global Limits ====


{| class="wikitable"
{| class="wikitable"
|-
|-
! Setting !! Behavior !! Use Case
! Parameter !! Default !! Description
|-
|-
| <code>maxpool_clean_obsolete = no</code> (default) || Only delete files that are indexed. Unknown files are ignored. || Safe default - protects manually added files
| <code>maxpoolsize</code> || 102400 (100 GB) || Maximum total size for all PCAP data
|-
|-
| <code>maxpool_clean_obsolete = yes</code> || Delete ALL files in spool directory, including those not in index || Clean up orphaned files, recover from index corruption
| <code>maxpooldays</code> || (unset) || Maximum age in days for all PCAP data
|}
|}


{| class="wikitable" style="background-color: #FFF3CD;"
==== Per-Type Limits ====
|-
! colspan="2" style="background: #856404; color: white;" | Warning: maxpool_clean_obsolete
|-
| style="vertical-align: top;" | '''Caution:'''
|
When <code>maxpool_clean_obsolete = yes</code> is enabled, cleanspool will scan the entire filesystem and delete any files not found in its index. This includes:
* Files manually copied into the spool directory
* Files from backup restores
* Files from other sensors (in shared storage scenarios)
 
Only enable this if you understand the implications and want aggressive cleanup of unindexed files.
|}
 
=== Reducing Data Collection at Source ===
 
Before configuring cleanup policies, consider reducing the amount of data captured. This is often the most effective long-term solution for storage management.
 
==== Save Only RTP Headers (Major Space Saver) ====
 
RTP packets typically contain the full audio payload, which consumes the majority of disk space. If you only need call quality statistics (MOS, jitter, packet loss) and not actual audio playback, switch to saving RTP headers only.
 
Edit <code>/etc/voipmonitor.conf</code>:


<syntaxhighlight lang="ini">
You can set different retention for each data type:
# Change from full RTP to headers only
savertp = header
</syntaxhighlight>


{| class="wikitable"
{| class="wikitable"
|-
|-
! Setting !! Storage Impact !! Use Case
! Data Type !! Size Parameter !! Days Parameter
|-
| <code>savertp = yes</code> || High (~10x more) || Requires ability to play back audio from PCAPs
|-
| <code>savertp = header</code> || Low || Only CDR statistics needed, no audio playback required
|}
 
With <code>savertp = header</code>, VoIPmonitor still captures all necessary metadata for MOS scoring, jitter analysis, packet loss statistics, and quality graphs, but does not store the actual audio payload. This can reduce storage consumption by up to 90%.
 
'''Important:''' After changing from <code>savertp = yes</code> to <code>savertp = header</code>, existing PCAP files will remain playable. New calls will only contain RTP headers.
 
{| class="wikitable" style="background-color: #FFF3CD;"
|-
! colspan="2" style="background: #856404; color: white;" | Critical: Distributed Architecture Consideration
|-
|-
| style="vertical-align: top;" | '''<code>packetbuffer_sender</code> Architecture:'''
| SIP signaling || <code>maxpoolsipsize</code> || <code>maxpoolsipdays</code>
|
If you are using the Packet Mirroring/Client-Server mode (<code>packetbuffer_sender=yes</code> on remote sensors), the <code>savertp</code> setting must be applied on the '''central server''' where packet analysis is performed, not on the individual sensors.
 
{|
|-
|-
! Architecture !! Where to Apply <code>savertp = header</code>
| RTP audio || <code>maxpoolrtpsize</code> || <code>maxpoolrtpdays</code>
|-
|-
| <code>packetbuffer_sender = no</code> (Local Processing) || On each sensor/probe's configuration file
| Quality graphs || <code>maxpoolgraphsize</code> || <code>maxpoolgraphdays</code>
|-
|-
| <code>packetbuffer_sender = yes</code> (Packet Mirroring) || On the central server's configuration file (not on sensors)
| Converted audio || <code>maxpoolaudiosize</code> || <code>maxpoolaudiodays</code>
|}
 
For distributed deployment details, see [[Sniffer_distributed_architecture#Controlling_Packet_Storage_in_Packet_Mirroring_Mode|Client-Server Architecture]].
|}
|}


==== Enabling Selective Audio Recording with Capture Rules ====
==== Recommended Configuration ====
 
For compliance scenarios where you need to record full audio for specific calls while keeping most calls with headers only (or disabled), use GUI capture rules to create exceptions:


'''Workflow:'''
For most deployments, limit RTP (which consumes most space) while keeping SIP longer:


1. **Set global default to headers only:**
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
savertp = header
# Limit RTP to 100 GB (deleted when exceeded)
</syntaxhighlight>
maxpoolrtpsize = 102400


2. **Create capture rules in the GUI for exceptions:**
# Overall limit for all data
  * Navigate to '''Control Panel''' > '''Capture Rules'''
maxpoolsize = 512000
  * For selective audio recording, set the '''recordRTP''' option to '''ON'''
  * Rules with <code>recordRTP=ON</code> will capture full RTP audio, overriding the global <code>savertp=header</code> setting for matched calls
 
'''Use Cases:'''
 
{| class="wikitable"
|-
! Scenario !! Configuration !! File Storage
|-
| Legal Holds
| Create IP rule for subject party with <code>recordRTP=ON</code>
| Full audio recorded
|-
| VIP Customers
| Create phone number prefix rules for specific ranges with <code>recordRTP=ON</code>
| Full audio recorded
|-
| All Other Calls
| Global <code>savertp = header</code>
| Headers only (no audio)
|}
 
This approach allows you to comply with data retention laws (e.g., GDPR) by minimizing audio recording while still meeting specific legal or business requirements for certain call categories.
 
For detailed capture rule configuration options, see [[Capture_rules]].
For more configuration options, see [[Sniffer_configuration#Saving_Options|Sniffer Configuration - Saving Options]].
 
=== Spool Directory Structure ===
 
The spool directory uses a hierarchical structure organized by time and data type.
 
{| class="wikitable"
|-
! Structure !! Description
|-
| <code>YY-mm-dd/HH/MM/{TYPE}/files...</code> || Date → Hour → Minute → Data Type
|}
 
The <code>{TYPE}</code> subdirectory can be:
* <code>SIP</code> - SIP signaling PCAP files
* <code>RTP</code> - RTP audio PCAP files
* <code>AUDIO</code> - Converted audio files (WAV/OGG)
* <code>GRAPH</code> - Quality graph image files
 
Example path:
<syntaxhighlight lang="text">
/var/spool/voipmonitor/25-01-06/10/45/RTP/rtp_2025-01-06-10-45.tar
</syntaxhighlight>
</syntaxhighlight>


The timestamps are based on UTC or the timezone configured in <code>voipmonitor.conf</code>.
This keeps SIP signaling (small files, useful for troubleshooting) as long as overall space allows, while limiting large RTP files.


'''Important:''' The cleanup process operates at the '''minute level''', not hour level. When cleaning is triggered, it removes the oldest minute's worth of data (e.g., <code>25-01-06/08/57/</code>) rather than deleting an entire hour's worth of data at once.
==== Verifying Active Cleanup Rules ====


=== Spool Directory Location ===
Check which rule triggered cleanup:


By default, all data is stored in <code>/var/spool/voipmonitor</code>. This location can be changed by setting the <code>spooldir</code> option in <code>voipmonitor.conf</code>.
==== Relocating the Spool Directory to a Different Partition ====
If your default partition is running out of space, you can move the spool directory to a larger partition or dedicated disk. This is particularly useful when MySQL Error 28 ("No space left on device") occurs despite retention settings being in place.
{| class="wikitable"
|-
! Situation !! Recommended Action
|-
| <code>/var/lib/mysql</code> full but other partitions available || Move spool to larger partition and update <code>spooldir</code> in <code>voipmonitor.conf</code>
|-
| Multiple disks available || Use dedicated partition for PCAP storage
|-
| GUI on same server || Sync GUI <code>SNIFFER_DATA_PATH</code> to match new <code>spooldir</code>
|}
===== Procedure to Relocate Spooldir =====
;Step 1: Identify Available Space
Check all partitions to find a suitable location:
<syntaxhighlight lang="bash">
df -h
</syntaxhighlight>
;Step 2: Create New Spool Directory
Create the directory on the destination partition:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Example: Use /mnt/pcaps partition
journalctl -u voipmonitor | grep -i clean
mkdir -p /mnt/pcaps/voipmonitor
 
# Set correct ownership for both sniffer and GUI access
chown voipmonitor:voipmonitor /mnt/pcaps/voipmonitor
chmod 755 /mnt/pcaps/voipmonitor
</syntaxhighlight>
 
;Step 3: Update VoIPmonitor Configuration
Edit <code>/etc/voipmonitor.conf</code> to point to the new location:
<syntaxhighlight lang="ini">
spooldir = /mnt/pcaps/voipmonitor
</syntaxhighlight>
</syntaxhighlight>


;Step 4: Update GUI Configuration (Critical)
Log messages indicate: <code>clean_maxpoolsize</code>, <code>clean_maxpooldays</code>, <code>clean_maxpoolrtpdays</code>, etc.
 
If the GUI runs on the same server, you MUST update the path the GUI uses to access the spool. This is defined in the GUI configuration file:
 
* Debian/Ubuntu: <code>/var/www/html/voipmonitor/config/configuration.php</code>
* RHEL/CentOS: <code>/var/www/voipmonitor/config/configuration.php</code>
 
Edit the GUI configuration file:
<syntaxhighlight lang="php">
// Find and update this line to match your new spooldir
define('SNIFFER_DATA_PATH', '/mnt/pcaps/voipmonitor');
</syntaxhighlight>


'''Important:''' The <code>SNIFFER_DATA_PATH</code> in the GUI config MUST match the <code>spooldir</code> setting in <code>voipmonitor.conf</code>. If these are mismatched, the GUI will be unable to locate and display call recordings.
=== Emergency Cleanup ===


;Step 5: Restart Services
Emergency cleanup acts as a safety mechanism when disk is nearly full:
Apply all changes by restarting the services:
<syntaxhighlight lang="bash">
# Restart the VoIPmonitor sensor
systemctl restart voipmonitor
 
# If using Apache/Nginx, reload web server
systemctl reload apache2    # Debian/Ubuntu
# or
systemctl reload nginx      # RHEL/CentOS
</syntaxhighlight>
 
;Step 6: Verify Configuration
<syntaxhighlight lang="bash">
# Check if new spool directory is being used
ls -ld /mnt/pcaps/voipmonitor
 
# Verify GUI can access the path
grep SNIFFER_DATA_PATH /path/to/gui/config/configuration.php
 
# Check sensor logs for any spool-related errors
tail -f /var/log/voipmonitor.log
</syntaxhighlight>
 
===== Optional: Move Existing Data =====
 
If you want to migrate existing PCAP files to the new location:
<syntaxhighlight lang="bash">
# Stop the sensor to prevent writes during migration
systemctl stop voipmonitor
 
# Move existing data (this may take a long time)
mv /var/spool/voipmonitor/* /mnt/pcaps/voipmonitor/
 
# Restart the sensor
systemctl start voipmonitor
</syntaxhighlight>
 
=== Retention Mechanism ===
 
The cleaning process runs automatically every 5 minutes and removes data based on the configuration in <code>voipmonitor.conf</code>.


{| class="wikitable"
{| class="wikitable"
|-
|-
! Mechanism !! Check Interval !! Purpose
! Parameter !! Default !! Triggers When
|-
|-
| '''Retention Policy (<code>maxpool*</code>)''' || Every 5 minutes || Capacity control - maintains storage below configured limits
| <code>autocleanspoolminpercent</code> || 1 || Disk usage reaches 99%
|-
|-
| '''Emergency Cleanup (<code>autoclean*</code>)''' || Every 5 minutes || Disk space "fuse" - prevents disk exhaustion when free space falls below threshold
| <code>autocleanmingb</code> || 5 || Free space below 5 GB
|}
|}


==== Retention Policy: maxpool* Parameters ====
When triggered, oldest data is deleted aggressively '''regardless of <code>maxpool*</code> settings''' until thresholds are cleared.


When triggered by a <code>maxpool*</code> setting (e.g., <code>maxpoolsize</code>, <code>maxpoolrtpsize</code>):
=== Reducing Data at Source ===


1. The cleanup identifies the oldest minute of data
Before tuning retention, consider reducing data volume:
2. It removes the entire <code>YY-mm-dd/HH/MM/</code> directory tree (e.g., <code>25-01-06/08/57/</code>)
3. If <code>maxpoolsize</code> is used (overall limit), it removes all data types from that minute
4. If type-specific limits are used (e.g., <code>maxpoolaudiosize</code>), it removes only that data type


'''Important: The cleanup removes ONE minute of data at a time, not an entire hour's worth. This ensures gradual, controlled cleanup instead of sudden large deletions.'''
==== Save RTP Headers Only ====


==== Emergency Cleanup: autoclean* Parameters ====
If you only need call quality statistics (MOS, jitter, packet loss) without audio playback:


The <code>autoclean*</code> parameters act as a safety "fuse" to prevent the disk from filling up:
<syntaxhighlight lang="ini">
savertp = header
</syntaxhighlight>


{| class="wikitable"
This reduces storage by up to 90% while preserving all quality metrics.
|-
! Parameter !! Default !! Behavior
|-
| <code>autocleanspoolminpercent</code> || 1 || When disk usage reaches 99%, trigger emergency cleanup regardless of <code>maxpool*</code> settings
|-
| <code>autocleanmingb</code> || 5 || When free space falls below 5 GB, trigger emergency cleanup
|}


When either threshold is breached:
==== Selective Audio Recording ====
* Oldest data is deleted AGGRESSIVELY until free space is restored
* This happens regardless of your <code>maxpool*</code> or <code>maxpooldays</code> settings
* Normal retention behavior resumes once thresholds are cleared


==== Performance Warning: maxpoolaudiosize ====
To record full audio only for specific calls (legal holds, VIP customers):


The <code>maxpoolaudiosize</code> parameter controls the size of converted audio files (WAV/OGG) when <code>saveaudio</code> is enabled.
# Set global default to headers only: <code>savertp = header</code>
# Create capture rules in GUI (Control Panel > Capture Rules) with <code>recordRTP=ON</code> for exceptions


{| class="wikitable" style="background-color: #FFF3CD;"
See [[Capture_rules]] for details.
|-
! colspan="2" style="background: #856404; color: white;" | Performance Consideration
|-
! Warning
| Audio conversion (PCAP → WAV/OGG) is CPU-intensive. For deployments with high call volumes (>200 concurrent calls or high CPS), using <code>saveaudio</code> can overload the system and cause packet loss or performance degradation.
|}
 
* '''Recommended:''' For high-volume deployments, use <code>savertp = yes</code> and convert on-demand via the GUI instead
* '''Alternative:''' Consider <code>savertp = header</code> if you only need statistics, not audio playback
 
=== Retention Configuration ===
 
The cleaning configuration allows you to set limits based on total size (in Megabytes) or age (in days).
 
{| class="wikitable" style="background-color: #E8F5E9;"
|-
! colspan="2" style="background: #4CAF50; color: white;" | Important: Default Retention Behavior
|-
| style="vertical-align: top;" | '''Default Behavior:'''
|
By default, PCAP files are deleted based on '''size only''' (using <code>maxpoolsize</code>), not based on time. The default <code>maxpoolsize</code> is 100 GB (102400 MB). When the spool directory reaches 100 GB, the oldest PCAP files are automatically deleted to free up space.


Time-based retention (<code>maxpooldays</code>) is '''disabled by default''' and must be explicitly configured if you want to limit retention by days instead of size.
=== The maxpool_clean_obsolete Parameter ===
|}


You can set limits based on total size (in Megabytes) or age (in days). If both a size and day limit are set for the same data type, the first limit that is reached will trigger the cleaning.
Controls handling of files not in the index:


{| class="wikitable"
{| class="wikitable"
|-
|-
! Parameter !! Default Value !! Description
! Setting !! Behavior
|-
| <code>maxpoolsize</code> || 102400 (100 GB) || The total maximum disk space for '''all''' captured data (SIP, RTP, GRAPH, AUDIO).
|-
| <code>maxpooldays</code> || (unset) || The maximum number of days to keep '''all''' captured data.
|-
| <code>maxpoolsipsize</code> || (unset) || A specific size limit for SIP PCAP files only.
|-
| <code>maxpoolsipdays</code> || (unset) || A specific age limit for SIP PCAP files only.
|-
| <code>maxpoolrtpsize</code> || (unset) || A specific size limit for RTP PCAP files only.
|-
| <code>maxpoolrtpdays</code> || (unset) || A specific age limit for RTP PCAP files only.
|-
| <code>maxpoolgraphsize</code> || (unset) || A specific size limit for GRAPH files only.
|-
|-
| <code>maxpoolgraphdays</code> || (unset) || A specific age limit for GRAPH files only.
| <code>maxpool_clean_obsolete = no</code> (default) || Only delete indexed files. Unknown files are preserved.
|-
|-
| <code>maxpoolaudiosize</code> || (unset) || A specific size limit for converted audio files (WAV/OGG) only.
| <code>maxpool_clean_obsolete = yes</code> || Delete ALL files in spool, including unindexed ones.
|-
| <code>maxpoolaudiodays</code> || (unset) || An age limit for converted audio files (WAV/OGG) only.
|}
|}


=== Recommended Configuration Strategy: Mixed Size-Based Retention ===
== Database Cleaning (CDR Records) ==


For optimal disk space management while preserving SIP signaling for long-term analysis, use a **mixed retention strategy**:
=== Partitioning Method ===


{| class="wikitable"
VoIPmonitor uses daily partitioning for database tables. Dropping old partitions is instant (milliseconds) regardless of row count.
|-
! Data Type !! Recommended Setting !! Rationale
|-
| RTP (audio payload) || Size-based (<code>maxpoolrtpsize</code>) || RTP consumes most disk space (5-10x more than SIP)
|-
| SIP (signaling) || Overall only (<code>maxpoolsize</code>, no <code>maxpoolsipdays</code>) || SIP files are small; keep as long as total space allows
|-
| Charts/Audio || Overall only (<code>maxpoolsize</code>) || Supplementary data, keep as space permits
|}


{| class="wikitable" style="background-color: #E3F2FD;"
|-
! colspan="2" style="background: #1976D2; color: white;" | Configuration Example: Long-Term SIP with Limited RTP
|-
| style="vertical-align: top;" | Scenario:
| You want to keep SIP signaling and charts for as long as possible, but limit RTP (audio) to a reasonable size to prevent disk exhaustion.
|-
| style="vertical-align: top;" | Configuration:
| Edit <code>/etc/voipmonitor.conf</code>:
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Set size limit for RTP only (keeps audio limited)
# Keep CDR records for 30 days
maxpoolrtpsize = 102400    # 100 GB for RTP
cleandatabase = 30
 
# DO NOT set maxpoolsipdays - let SIP be controlled by maxpoolsize only
 
# Set overall limit for all data together
maxpoolsize = 512000      # 500 GB total limit (includes SIP + RTP + GRAPH + AUDIO)
</syntaxhighlight>
</syntaxhighlight>
|-
| style="vertical-align: top;" | Behavior:
| RTP is deleted when it exceeds <code>maxpoolrtpsize</code> (100 GB). SIP, chart, and audio files are kept as long as the total <code>maxpoolsize</code> (500 GB) allows. If the disk fills up (total exceeds 500 GB), oldest data is deleted regardless of type.
|-
| style="vertical-align: top;" | Why this works:
| RTP files are huge (GBs per day) but rarely needed for troubleshooting. SIP files are small (MBs per day) and essential for analyzing call setup/teardown, call flows, and configuration issues. By limiting RTP size but not SIP size, you maximize useful long-term data retention.
|}
=== Alternative Configuration: Time-Based Retention ===
If you need to keep data for a specific number of days (such as compliance requirements), you can use time-based retention parameters.
{| class="wikitable" style="background-color: #FFF3CD;"
|-
! colspan="2" style="background: #856404; color: white;" | Important: Time-Based Retention Basics
|-
| style="vertical-align: top;" | '''Understanding Maximum vs Minimum''':
| <code>maxpoolsipdays</code> sets a '''maximum''' retention period for SIP files, not a guaranteed minimum. To ensure files are kept for at least the specified period, you must allocate sufficient disk space using <code>maxpoolsize</code> to accommodate the expected volume of data for that period.
|}
==== Configuration Example: 14-Day SIP Retention ====


{| class="wikitable"
{| class="wikitable"
|-
|-
! Scenario !! Configuration !! Behavior
! Parameter !! Default !! Description
|-
|-
! Keep SIP for 14 days, limit RTP
| <code>cleandatabase</code> || 0 (disabled) || Global retention in days
| Edit <code>/etc/voipmonitor.conf</code>:
<syntaxhighlight lang="ini">
# Set maximum age for SIP files
maxpoolsipdays = 14
maxpoolgraphdays = 14
 
# Set maximum age for RTP files (can be different)
maxpoolrtpdays = 7
 
# OR set maximum size for RTP files
maxpoolrtpsize = 102400
 
# Allocate sufficient disk space to accommodate 14 days of data
maxpoolsize = 300000    # Ensure this is large enough for 14 days of SIP + graph data
</syntaxhighlight>
| SIP files are deleted after 14 days (maximum). RTP files are deleted after 7 days (if using <code>maxpoolrtpdays</code>) or when <code>maxpoolrtpsize</code> limit is reached. If <code>maxpoolsize</code> is reached before the 14-day period, data may be deleted regardless of age. Monitor disk usage to ensure <code>maxpoolsize</code> is sufficient.
|}
 
==== Verifying Which Cleaning Rule is Active ====
 
To debug which cleaning rule is currently applied and confirm your configuration is working:
 
<syntaxhighlight lang="bash">
# Check systemd journal for clean triggers
journalctl -u voipmonitor --since='YYYY-MM-DD' | grep clean -i
</syntaxhighlight>
 
The log messages indicate which rule triggered cleanup:
* <code>clean_maxpoolsize</code> - Cleaning triggered by total size limit
* <code>clean_maxpooldays</code> - Cleaning triggered by overall age limit
* <code>clean_maxpoolsipdays</code> - Cleaning triggered by SIP age limit
* <code>clean_maxpoolrtpdays</code> - Cleaning triggered by RTP age limit
 
If you see multiple triggers, VoIPmonitor applies the first limit that is reached, deleting data until all limits are satisfied.
 
==== Best Practice: Configure maxpoolsize with Disk Capacity Buffer ====
 
When setting <code>maxpoolsize</code>, configure a buffer below the total disk capacity. This ensures there is sufficient space during periods when the cleaning process is not active (such as when <code>cleanspool_enable_fromto</code> restricts cleaning to specific hours).
 
{| class="wikitable" style="background-color: #FFF3CD;"
|-
|-
! colspan="2" style="background: #856404; color: white;" | Important: Disk Capacity Buffer
| <code>cleandatabase_cdr</code> || 0 || CDR table retention
|-
|-
| style="vertical-align: top;" | '''Why a Buffer is Needed:'''
| <code>cleandatabase_register_state</code> || 0 || Registration state retention
|
The cleaning process runs every 5 minutes, but <code>cleanspool_enable_fromto</code> may restrict cleaning to specific hours (e.g., 1-5 AM). During non-cleaning hours, data will continue to accumulate. Setting <code>maxpoolsize</code> close to total disk capacity risks filling the disk outside the active cleaning window.
|-
|-
| style="vertical-align: top;" | '''Recommended Configuration:'''
| <code>cleandatabase_register_time_info</code> || 0 || Registration timing (must be set explicitly)
|
Set <code>maxpoolsize</code> to approximately 90-95% of total disk capacity to create a buffer.
|-
|-
| style="vertical-align: top;" | '''Example:'''
| <code>partition_operations_enable_fromto</code> || 1-5 || Time window for partition operations
|
For a 7 TB disk:
<syntaxhighlight lang="ini">
# 6.5 TB = 6656000 MB (approximately 93% of 7 TB)
maxpoolsize = 6656000
 
# Restrict cleaning to 1-5 AM to avoid I/O impact during peak traffic
cleanspool_enable_fromto = 1-5
</syntaxhighlight>
This configuration provides a 0.5 TB buffer for data accumulation during the 19-hour cleaning-off window.
|}
 
=== Manual File Deletion ===
 
Manual deletion of files from the spool directory is generally safe, but there are important considerations.
 
==== Is It Safe? ====
 
{| class="wikitable"
|-
! Scenario !! Safe? !! Notes
|-
| Deleting old directories (prior days/hours) || Yes || The index is recomputed automatically
|-
| Deleting current hour while service running || No risk to service, but may cause errors for active captures if file handles are still open
|-
| Deleting current MINUTE while recording in progress || Not recommended || May cause file descriptor errors temporarily
|}
|}
When you manually delete files:
* In '''modern mode''' (<code>cleanspool_use_files = yes</code>): The <code>files</code> database table still contains records for deleted files. These orphaned records are cleaned up during the next cleanup cycle.
* In '''legacy mode''': The <code>.cleanspool_cache</code> is recomputed automatically during the next cleanup cycle.
==== Orphaned Database Records ====
When you manually delete PCAP files, the corresponding records in the MySQL database (CDR tables) remain. This means:
* You will see calls in the GUI
* Clicking "Play" or "Download" will show "File not found" errors
{| class="wikitable" style="background-color: #E3F2FD;"
|-
! colspan="2" style="background: #1976D2; color: white;" | Manual Deletion: Database Records Remain
|-
! After deleting PCAP files
| Database CDR records are NOT automatically deleted. Calls will appear in the GUI but show "File not found" for missing files.
|-
! Solution
| To clean orphaned records, run the database cleaner: <code>voipmonitor --clean-db</code> or use the GUI "Maintenance" tab.
|}
==== When Is Manual Deletion Recommended? ====
* **Emergency Space Recovery:** If disk is 99% full and autoclean is not processing fast enough, manually deleting old directories (e.g., yesterday's folders) provides immediate space relief
* **Compliance Requests:** Legal requests requiring immediate data removal without waiting for automated cleanup
* **Targeted Cleanup:** Removing data for specific dates/time periods
==== Recovering from Index Issues ====
If the cleanspool index becomes corrupted or out of sync:
'''For Modern Mode (cleanspool_use_files = yes):'''
The <code>files</code> table can be rebuilt by rescanning the spool directory:
<syntaxhighlight lang="bash">
# Trigger a reindex via manager API
echo 'manager_file start /tmp/vmsck' | nc 127.0.0.1 5029
echo reindexfiles | nc -U /tmp/vmsck
rm /tmp/vmsck
</syntaxhighlight>
'''For Legacy Mode (.cleanspool_cache):'''
If the <code>.cleanspool_cache</code> file is deleted or corrupted:
<syntaxhighlight lang="bash">
# Same reindex command works for legacy mode
echo 'manager_file start /tmp/vmsck' | nc 127.0.0.1 5029
echo reindexfiles | nc -U /tmp/vmsck
rm /tmp/vmsck
</syntaxhighlight>
The <code>reindexfiles</code> command rescans the spool directory structure and rebuilds the index.


{| class="wikitable" style="background-color: #FFF3CD;"
{| class="wikitable" style="background-color: #FFF3CD;"
|-
|-
! colspan="2" style="background: #856404; color: white;" | Alternative: Secured Manager API
! colspan="2" style="background: #856404; color: white;" | Important: register_time_info
|-
|-
If your deployment uses the secured manager API with SSL/TLS, use the secured endpoint instead of the Unix socket method. See [[Encryption_in_manager_api_customer|Manager API documentation]] for the secured API usage.
| The <code>register_time_info</code> table is NOT covered by global <code>cleandatabase</code>. Set <code>cleandatabase_register_time_info</code> explicitly to enable cleanup.
|}
|}


=== Custom Autocleaning: One-Time Cleanup with Filters ===
=== Size-Based Database Cleaning ===


The GUI provides a '''custom autocleaning''' feature that allows you to perform one-time cleanup of existing recordings based on specific criteria, such as IP address or telephone number. This is useful when you need to clean up data for a specific subset of calls without affecting global retention settings.
To limit database by size instead of time:


==== Use Case: Cleaning Old Recordings for a Specific IP ====
<syntaxhighlight lang="ini">
 
cleandatabase_size = 512000        # 500 GB limit in MB
After configuring [[Capture_rules|capture rules]] to stop recording future calls from a specific IP address, you may still have existing RTP recordings from that IP. Custom autocleaning allows you to remove these old recordings.
cleandatabase_size_force = true    # Required to enable
 
Example scenario:
* You configured a capture rule to discard RTP for IP <code>192.168.1.50</code>
* Only new calls will be affected by this rule
* Existing recordings for this IP must be cleaned up manually
 
GUI cleanup steps:
# Navigate to '''Settings > Custom Autocleaning'''
# Create a new autocleaning rule
# Set the criteria (e.g., "Delete RTP older than 1 day")
# In the '''Common Filter''' section, specify the target IP address (<code>192.168.1.50</code>)
# Save and apply the rule
# Once the cleanup is complete, remove the autocleaning rule
 
This rule will run once and clean up all matching old recordings, then the capture rule will prevent future recordings.
 
==== Comparison with Global Retention ====
 
{| class="wikitable"
|-
! Feature !! Custom Autocleaning !! Global Retention
|-
| '''Scope''' || Targeted (specific IP, number, filter) || All calls
|-
| '''Purpose''' || One-time cleanup of existing data || Ongoing automated cleanup
|-
| '''Configuration''' || GUI with CDR filters || <code>maxpoolsize</code>, <code>maxpooldays</code>
|-
| '''Flexibility''' || High - can use any CDR filter criteria || Low - time/size only
|}
 
=== Diagnosing Disk Space Usage ===
 
To properly configure retention limits, first analyze your actual disk usage:
 
;Check total disk space
<syntaxhighlight lang="bash">
df -h
</syntaxhighlight>
 
;Check total spool directory size
<syntaxhighlight lang="bash">
du -hs /var/spool/voipmonitor
</syntaxhighlight>
 
;Analyze per-day utilization (helps identify growth patterns)
<syntaxhighlight lang="bash">
du -h --max-depth=1 /var/spool/voipmonitor | sort -k2,2
</syntaxhighlight>
</syntaxhighlight>


Example output interpretation:
=== Limits ===
<syntaxhighlight lang="text">
# 80G    ./2024-12
# 120G  ./2024-11
# 150G  ./2024-10
</syntaxhighlight>
This shows recent months consume 80-150 GB of data. Use this data to estimate appropriate size limits.


=== Understanding Directory Size Differences (SIP vs RTP Retention) ===
* '''Partition limit:''' ~8000 partitions per table (~22 years with daily partitioning)
* '''CDR record limit:''' No practical limit - uses BIGINT (18 quintillion records). See [[Upgrade_to_bigint]].


If you notice significant size differences between directories in your spool, this is usually expected behavior when you have different retention periods for SIP and RTP data.
=== Multi-Sensor Environments ===


{| class="wikitable"
When multiple sensors share a database, only ONE sensor should manage partitions:
|-
! Age of Directory !! Contents !! Size
|-
| 0-30 days || Both SIP and RTP PCAP files || Large
|-
| 30-90 days || SIP PCAP files only (RTP deleted) || Smaller
|-
| 90+ days || None (both SIP and RTP deleted) || Empty or absent
|}


This behavior is '''expected and by design''' when using different retention periods (e.g., <code>maxpoolsipdays = 90</code> and <code>maxpoolrtpdays = 30</code>).
==== Why RTP Directories Exist After Disabling RTP Saving ====
If you have configured <code>savertp = no</code> or <code>savertp = header</code> but still see <code>RTP</code> subdirectories, this occurs because:
* When <code>savertcp = yes</code>, RTCP (RTP Control Protocol) packets are saved in the <code>rtp_YYYY-MM-DD-HH-MM.tar</code> files
* The <code>RTP</code> directory name refers to the broad UDP port range used for RTP/RTCP traffic
* These files contain RTCP control traffic (receiver reports, sender reports) but not the full RTP audio payload
{| class="wikitable"
|-
! Configuration !! Result !! Expected Directory Size
|-
| <code>savertp = yes</code> + <code>savertcp = yes</code> || Full RTP audio + RTCP controls saved || Very large (GBs)
|-
| <code>savertp = no</code> + <code>savertcp = yes</code> || Only RTCP controls saved || Small (MBs)
|-
| <code>savertp = header</code> + <code>savertcp = yes</code> || RTP headers + RTCP controls saved || Small (MBs)
|}
== Filesystem Troubleshooting ==
=== Files Disappearing Faster Than Expected ===
If PCAP files are being deleted sooner than your <code>maxpooldays</code> setting suggests, check for these common causes:
==== Emergency Cleanup Triggers ====
Emergency cleanup can override your retention settings:
{| class="wikitable"
|-
! Parameter !! Default !! Triggers When
|-
| <code>autocleanspoolminpercent</code> || 1 || Disk usage reaches 99%
|-
| <code>autocleanmingb</code> || 5 || Free space falls below 5 GB
|}
'''Diagnosis:'''
<syntaxhighlight lang="bash">
# Check disk usage
df -h /var/spool/voipmonitor
# Check emergency trigger settings
grep -E "autocleanspoolminpercent|autocleanmingb" /etc/voipmonitor.conf
</syntaxhighlight>
'''Resolution:'''
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Increase emergency thresholds (allow more data before emergency cleanup)
# On all sensors EXCEPT one:
autocleanspoolminpercent = 5  # Allow 95% usage before emergency
disable_partition_operations = yes
autocleanmingb = 20            # Trigger at 20 GB free instead of 5 GB
</syntaxhighlight>


==== GUI Configuration Override ====
# On the designated sensor:
 
partition_operations_enable_fromto = 4-6
If <code>mysqlloadconfig = yes</code> (default), GUI sensor settings override <code>voipmonitor.conf</code>:
 
'''Diagnosis:'''
<syntaxhighlight lang="bash">
# Check if database config is enabled
grep mysqlloadconfig /etc/voipmonitor.conf
 
# Check GUI: Settings > Sensors > wrench icon > search "maxpool"
</syntaxhighlight>
</syntaxhighlight>


'''Resolution:''' Update settings via GUI, or set <code>mysqlloadconfig = no</code> to use file-based config only.
== Advanced Topics ==


==== Diagnostic Checklist ====
=== Spool Directory Location ===
 
Before applying fixes, run through this diagnostic checklist:


<syntaxhighlight lang="bash">
Default location: <code>/var/spool/voipmonitor</code>
# 1. Check all retention-related settings
cat /etc/voipmonitor.conf | grep -E '^spooldir|^maxpool|^cleandatabase|^autoclean'


# 2. Measure total spool usage
Directory structure: <code>YYYY-MM-DD/HH/MM/{SIP|RTP|GRAPH|AUDIO}/files...</code>
du -hs /var/spool/voipmonitor


# 3. Analyze per-day usage patterns
==== Relocating the Spool Directory ====
du -h --max-depth=1 /var/spool/voipmonitor | sort -k2,2


# 4. Check disk capacity
To move spool to a larger partition:
df -h


# 5. Check for emergency cleanup in logs
;Step 1: Create new directory
journalctl -u voipmonitor | grep -i "clean\|autoclean"
</syntaxhighlight>
 
=== Spool Directory Filling Due to Database Performance ===
 
If <code>/var/spool/voipmonitor/</code> is filling up rapidly after a disk swap, MySQL upgrade, or configuration change, the issue may be caused by database performance problems.
 
{| class="wikitable" style="background:#fff3cd; border:1px solid #ffc107;"
|-
! colspan="2" style="background:#ffc107;" | Root Cause: Slow Database Causing Query File Queuing
|-
! Symptoms
| Spool directory fills exponentially, sometimes within hours, even with correct <code>maxpoolsize</code> settings.
|-
! Root Cause
| MySQL cannot process database writes quickly enough, causing query files to queue.
|}
 
'''Diagnosis:'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Watch for SQLq (SQL queue) metrics in real-time
mkdir -p /mnt/storage/voipmonitor
tail -f /var/log/syslog | grep voipmonitor | grep SQLq
chown voipmonitor:voipmonitor /mnt/storage/voipmonitor
 
# Check MySQL InnoDB settings
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
</syntaxhighlight>
</syntaxhighlight>


'''Solution - Tune MySQL:'''
;Step 2: Update sniffer configuration
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
[mysqld]
# /etc/voipmonitor.conf
# 50-70% of server RAM
spooldir = /mnt/storage/voipmonitor
innodb_buffer_pool_size = 8G
 
# Fast writes (acceptable data loss risk on crash)
innodb_flush_log_at_trx_commit = 2
</syntaxhighlight>
</syntaxhighlight>


=== "low spool disk space" Message ===
;Step 3: Update GUI configuration
 
Edit GUI config file and set <code>SNIFFER_DATA_PATH</code> to match:
This message indicates that your configured <code>maxpoolsize</code> exceeds the physical disk capacity. VoIPmonitor may automatically adjust <code>maxpoolsize</code> to a lower value.
<syntaxhighlight lang="php">
 
define('SNIFFER_DATA_PATH', '/mnt/storage/voipmonitor');
'''Resolution:'''
<syntaxhighlight lang="bash">
# Check actual disk capacity
df -h /var/spool/voipmonitor
 
# Set realistic maxpoolsize (leave 5-10% buffer)
# For a 500 GB partition, use ~450 GB:
maxpoolsize = 460800
</syntaxhighlight>
</syntaxhighlight>


=== Missing Data Due to NFS/Storage Server Issues ===
;Step 4: Restart services
 
If using remote storage (NFS, SSHFS), missing data may be caused by network connectivity issues rather than retention policies.
 
'''Diagnosis:'''
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Check system logs for NFS errors
systemctl restart voipmonitor
grep -i "nfs" /var/log/syslog | grep "not responding\|timed out"
 
# Test connectivity
ping nfs-server.example.com
nc -zv nfs-server.example.com 2049
</syntaxhighlight>
</syntaxhighlight>


== Tiered Storage and Archival Options ==
=== Tiered Storage (tar_move) ===
 
If you need to extend PCAP retention beyond your fast local disk capacity, there are three recommended approaches.
 
=== Option 1: Use tar_move Feature (Recommended) ===


The <code>tar_move</code> feature automatically archives PCAP files to secondary storage after they are closed.
To extend retention using secondary storage:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# Use local fast storage for live capture
# Local fast storage for live capture
spooldir = /var/spool/voipmonitor
spooldir = /var/spool/voipmonitor


# Enable automatic archival
# Archive to secondary storage
tar_move = yes
tar_move = yes
tar_move_destination_path = /mnt/archive/voipmonitor
tar_move_destination_path = /mnt/archive/voipmonitor
tar_move_max_threads = 2
</syntaxhighlight>
</syntaxhighlight>


{| class="wikitable"
Files in <code>tar_move_destination_path</code> remain accessible via GUI.
|-
! Parameter !! Description
|-
| <code>tar_move = yes</code> || Move files to archive after capture completes
|-
| <code>tar_move = copy</code> || Copy files (keep original)
|-
| <code>tar_move_destination_path</code> || Target directory for archived files
|}


'''Important:''' Files in <code>tar_move_destination_path</code> remain accessible via GUI. VoIPmonitor searches both local spooldir and tar_move_destination_path.
==== S3 Cloud Storage ====


==== S3 Cloud Storage Considerations ====
Use <code>rclone</code> instead of <code>s3fs</code> to avoid GUI unresponsiveness:
 
When using S3 storage, use <code>rclone</code> instead of <code>s3fs</code> to avoid GUI unresponsiveness:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Recommended: rclone mount
rclone mount bucket-name /mnt/s3-archive \
/usr/bin/rclone mount bucket-name /mnt/s3-archive \
   --allow-other --dir-cache-time 30s --vfs-cache-mode off
   --allow-other --dir-cache-time 30s --poll-interval 0 \
  --vfs-cache-mode off --buffer-size 0 --use-server-modtime \
  --no-modtime --s3-no-head --log-level INFO
</syntaxhighlight>
</syntaxhighlight>


=== Option 2: Manual Archival with Additional Spool Directories ===
=== Custom Autocleaning (GUI) ===


Move old files manually and configure GUI to access multiple directories:
For one-time cleanup of specific recordings (e.g., by IP address):


# Create archive script to move files older than X days
# Navigate to Settings > Custom Autocleaning
# Add archive path to GUI: '''Settings > System configuration > Basic > Additional spool directories'''
# Create rule with filters (IP, phone number, etc.)
# Apply and remove rule after completion


=== Option 3: LVM Single Logical Volume ===
Useful for cleaning old data after configuring capture rules to stop future recording.


Combine fast SSD + large HDD into a single logical volume using LVM. VoIPmonitor sees only one spool directory.
== Troubleshooting ==


== Database Cleaning (CDR Retention) ==
=== Files Disappearing Faster Than Expected ===


Managing the size of the <code>cdr</code> table and other large tables is critical for GUI performance.
Check these causes in order:


=== Partitioning Method (Recommended) ===
;1. Emergency cleanup triggered
 
<syntaxhighlight lang="bash">
Since version 7, VoIPmonitor uses '''database partitioning''', which splits large tables into smaller, daily segments.
df -h /var/spool/voipmonitor
 
# If >95% full, emergency cleanup is active
{| class="wikitable"
|-
! Aspect !! Description
|-
| '''How it works''' || Set <code>cleandatabase = 30</code> to keep the last 30 days of data
|-
| '''Why it's better''' || Dropping old partitions is instantaneous (milliseconds), regardless of row count
|-
| '''Partition limit''' || ~8000 partitions per table (~22 years with daily partitioning)
|-
| '''CDR record limit''' || No practical limit - modern installations use <code>BIGINT</code> for <code>cdr.ID</code> (up to 18 quintillion records). See [[Upgrade_to_bigint|Migrating to BIGINT]].
|}
 
==== Quick Start: Global Retention ====
 
<syntaxhighlight lang="ini">
# Keep all records for 30 days
cleandatabase = 30
</syntaxhighlight>
</syntaxhighlight>


==== Retention Parameters ====
;2. GUI configuration override
When <code>mysqlloadconfig = yes</code> (default), GUI settings override config file. Check: Settings > Sensors > wrench icon.


{| class="wikitable"
;3. Insufficient maxpoolsize
|-
Set <code>maxpoolsize</code> to 90-95% of disk capacity to leave buffer for growth between cleanup cycles.
! Parameter !! Default !! Description
|-
| <code>cleandatabase</code> || 0 (disabled) || Master retention setting in days
|-
| <code>cleandatabase_cdr</code> || 0 || Specific retention for CDR tables
|-
| <code>cleandatabase_rtp_stat</code> || 2 || Retention for RTP statistics
|-
| <code>cleandatabase_sip_msg</code> || 0 || Retention for SIP messages
|-
| <code>cleandatabase_register_state</code> || 0 || Retention for registration states
|-
| <code>cleandatabase_register_time_info</code> || 0 || '''Must be set explicitly''' (not covered by global setting)
|-
| <code>cleandatabase_size</code> || (unset) || Size-based limit in MB
|-
| <code>cleandatabase_size_force</code> || false || Required for size-based cleanup
|-
| <code>partition_operations_enable_fromto</code> || 1-5 || Time window for partition operations
|}
 
{| class="wikitable" style="background-color: #FFF3CD;"
|-
! colspan="2" style="background: #856404; color: white;" | Important: register_time_info Table
|-
| style="vertical-align: top;" | '''Critical:'''
| The <code>register_time_info</code> table is NOT covered by the global <code>cleandatabase</code> setting. You MUST configure <code>cleandatabase_register_time_info</code> explicitly.
|}


==== Size-Based Database Cleaning ====
=== Disk Space Not Reclaimed After Database Cleanup ===


Use <code>cleandatabase_size</code> to limit database by size rather than time:
Check <code>innodb_file_per_table</code>:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="sql">
# Limit database to 50 GB
SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table';
cleandatabase_size = 51200
cleandatabase_size_force = true
 
# Optional: Start cleaning when disk free space drops below threshold
cleandatabase_min_free_size = 30720
</syntaxhighlight>
</syntaxhighlight>


==== Multi-Sniffer Environments ====
If OFF, space is not reclaimed when partitions drop. Enable for future tables:
 
When multiple sensors share the same database, partition operations should be managed by only ONE sensor:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# On all sniffers EXCEPT one:
[mysqld]
disable_partition_operations = yes
innodb_file_per_table = 1
 
# On the ONE designated sniffer:
partition_operations_enable_fromto = 4-6
</syntaxhighlight>
</syntaxhighlight>


== Database Troubleshooting ==
=== MySQL Error 28: No Space Left ===
 
=== MySQL Error 28: No Space Left on Device ===


If MySQL crashes with Error 28 even when <code>cleandatabase</code> is configured:
Primary solution - enable size-based cleaning:


'''Primary Solution - Enable Size-Based Cleaning:'''
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
cleandatabase_size = 512000       # 500 GB limit
cleandatabase_size = 512000
cleandatabase_size_force = true   # Required
cleandatabase_size_force = true
</syntaxhighlight>
</syntaxhighlight>


'''Alternative Causes:'''
Other causes:
* '''Inode exhaustion:''' Check with <code>df -i</code>
* '''Inode exhaustion:''' Check with <code>df -i</code>
* '''MySQL tmpdir full:''' Check with <code>mysql -e "SHOW VARIABLES LIKE 'tmpdir';"</code>
* '''MySQL tmpdir full:''' Check with <code>SHOW VARIABLES LIKE 'tmpdir'</code>
 
=== Disk Space Not Reclaimed After Cleanup ===
 
Check <code>innodb_file_per_table</code> setting:
 
<syntaxhighlight lang="sql">
SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table';
</syntaxhighlight>
 
If OFF, space is not reclaimed when partitions are dropped. Enable for future tables:
<syntaxhighlight lang="ini">
[mysqld]
innodb_file_per_table = 1
</syntaxhighlight>


=== Database Not Cleaning (Verify Partitioning) ===
=== Database Not Cleaning ===


Before assuming cleaning is broken, verify tables are partitioned:
Verify tables are partitioned:


<syntaxhighlight lang="sql">
<syntaxhighlight lang="sql">
-- Check if CDR table is partitioned
SHOW CREATE TABLE cdr\G
SHOW CREATE TABLE cdr\G


-- Check partition list and row counts
SELECT PARTITION_NAME, TABLE_ROWS
SELECT PARTITION_NAME, TABLE_ROWS
FROM information_schema.PARTITIONS
FROM information_schema.PARTITIONS
Line 1,062: Line 344:
If only expected partitions exist (matching your <code>cleandatabase</code> setting), cleaning IS working - you may simply have high data volume.
If only expected partitions exist (matching your <code>cleandatabase</code> setting), cleaning IS working - you may simply have high data volume.


== MySQL Performance Settings ==
=== Spool Filling Due to Database Bottleneck ===
 
If spool fills rapidly after disk swap or MySQL upgrade:
 
<syntaxhighlight lang="bash">
# Check SQL queue
tail -f /var/log/syslog | grep voipmonitor | grep SQLq
</syntaxhighlight>


For high-performance operation:
Growing SQLq indicates database cannot keep up. Solution:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
[mysqld]
[mysqld]
# Use 50-70% of available RAM for caching
innodb_buffer_pool_size = 4G          # 50-70% of RAM
innodb_buffer_pool_size = 4G
innodb_flush_log_at_trx_commit = 2   # Faster writes
 
# Flush logs to OS every second (faster, safe for VoIPmonitor)
innodb_flush_log_at_trx_commit = 2
 
# Enable per-table filespace for easy space reclamation
innodb_file_per_table = 1
</syntaxhighlight>
</syntaxhighlight>


Line 1,083: Line 366:
* [[Scaling|Scaling and Performance Guide]]
* [[Scaling|Scaling and Performance Guide]]
* [[SQL_queue_is_growing_in_a_peaktime|SQL Queue Troubleshooting]]
* [[SQL_queue_is_growing_in_a_peaktime|SQL Queue Troubleshooting]]
* [[Sniffer_troubleshooting|Sniffer Troubleshooting]]


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' VoIPmonitor has two independent data retention systems: (1) Filesystem cleaning for PCAP files using <code>maxpoolsize</code>/<code>maxpooldays</code> parameters, running every 5 minutes; (2) Database cleaning using <code>cleandatabase</code> with daily partitioning for instant partition drops.
'''Summary:''' VoIPmonitor has two independent data retention systems: (1) Filesystem cleaning for PCAP files using <code>maxpoolsize</code>/<code>maxpooldays</code>, running every 5 minutes; (2) Database cleaning using <code>cleandatabase</code> with daily partitioning.


'''How cleanspool works:''' The sniffer keeps the complete file index '''in memory''' for fast operations. The <code>.cleanspool_cache</code> files in '''hourly''' directories (e.g., <code>/var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache</code>) serve only as persistent storage for '''fast restart''' - they allow quick index reload without scanning directories.
'''Cleanspool:''' File index kept in memory for fast operations. <code>.cleanspool_cache</code> files in hourly directories (e.g., <code>/var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache</code>) are for fast restart only.


The <code>maxpool_clean_obsolete</code> parameter (default: no) controls whether files not in the index are deleted. Emergency cleanup (<code>autocleanspoolminpercent=1</code>, <code>autocleanmingb=5</code>) can override retention settings when disk is nearly full. GUI settings via <code>mysqlloadconfig=yes</code> override <code>voipmonitor.conf</code>. For tiered storage, use <code>tar_move</code> to archive to secondary storage. Database partition limit is ~8000 per table (~22 years); CDR record count uses BIGINT (18 quintillion limit). Size-based database cleaning requires <code>cleandatabase_size</code> AND <code>cleandatabase_size_force=true</code>.
'''Key parameters:''' <code>maxpoolsize</code> (default 100GB), <code>maxpoolrtpsize</code>/<code>maxpoolrtpdays</code> for RTP-specific limits, <code>cleandatabase</code> for CDR retention. Emergency cleanup via <code>autocleanspoolminpercent</code> (default 1%) and <code>autocleanmingb</code> (default 5GB) overrides settings when disk nearly full. GUI settings override config file when <code>mysqlloadconfig=yes</code>. Size-based database cleaning requires <code>cleandatabase_size</code> AND <code>cleandatabase_size_force=true</code>. Database partition limit ~8000 (~22 years); CDR uses BIGINT.


'''Keywords:''' data retention, cleaning, maxpoolsize, maxpooldays, cleandatabase, maxpool_clean_obsolete, .cleanspool_cache, autocleanspoolminpercent, autocleanmingb, emergency cleanup, tar_move, tiered storage, partitioning, cleandatabase_size, innodb_file_per_table, savertp header, packetbuffer_sender, BIGINT cdr.ID, hourly cache, in-memory index
'''Keywords:''' data retention, maxpoolsize, maxpooldays, maxpoolrtpsize, cleandatabase, cleandatabase_size, .cleanspool_cache, autocleanspoolminpercent, autocleanmingb, tar_move, innodb_file_per_table, savertp header, BIGINT


'''Key Questions:'''
'''Key Questions:'''
* How does cleanspool work?
* How does cleanspool work?
* Where are the .cleanspool_cache files located?
* Where are .cleanspool_cache files?
* Will cleanspool delete files not in the cache?
* Why are files deleted faster than expected?
* What is maxpool_clean_obsolete?
* How to fix MySQL Error 28?
* Why are PCAP files being deleted faster than expected?
* How to configure size-based database cleaning?
* How do I fix MySQL Error 28?
* How to extend retention with tiered storage?
* How do I configure size-based database cleaning?
* How do I extend retention with tiered storage?
* Why is disk space not reclaimed after cleanup?
* Why is disk space not reclaimed after cleanup?
* How do I check if database partitioning is working?

Revision as of 14:38, 8 January 2026

This guide explains how VoIPmonitor manages data retention for PCAP files and database records.

Overview

VoIPmonitor generates two types of data requiring periodic cleanup:

Data Type Storage Cleanup Mechanism Key Parameters
PCAP Files Filesystem (spool directory) Cleanspool process maxpoolsize, maxpooldays
CDR Records MySQL database Partition dropping cleandatabase

These are independent systems - filesystem cleanup does not affect database records and vice versa.

Filesystem Cleaning (PCAP Files)

How Cleanspool Works

The sniffer maintains a complete file index in memory during operation. Every 5 minutes, the cleanspool thread checks retention limits and deletes the oldest files when limits are exceeded.

The .cleanspool_cache files in hourly directories (e.g., /var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache) serve as persistent storage for fast restart - they allow quick index reload without scanning the entire directory structure.

Retention Configuration

Retention limits can be set by size (MB) or age (days). When both are configured, the first limit reached triggers cleanup.

Global Limits

Parameter Default Description
maxpoolsize 102400 (100 GB) Maximum total size for all PCAP data
maxpooldays (unset) Maximum age in days for all PCAP data

Per-Type Limits

You can set different retention for each data type:

Data Type Size Parameter Days Parameter
SIP signaling maxpoolsipsize maxpoolsipdays
RTP audio maxpoolrtpsize maxpoolrtpdays
Quality graphs maxpoolgraphsize maxpoolgraphdays
Converted audio maxpoolaudiosize maxpoolaudiodays

Recommended Configuration

For most deployments, limit RTP (which consumes most space) while keeping SIP longer:

# Limit RTP to 100 GB (deleted when exceeded)
maxpoolrtpsize = 102400

# Overall limit for all data
maxpoolsize = 512000

This keeps SIP signaling (small files, useful for troubleshooting) as long as overall space allows, while limiting large RTP files.

Verifying Active Cleanup Rules

Check which rule triggered cleanup:

journalctl -u voipmonitor | grep -i clean

Log messages indicate: clean_maxpoolsize, clean_maxpooldays, clean_maxpoolrtpdays, etc.

Emergency Cleanup

Emergency cleanup acts as a safety mechanism when disk is nearly full:

Parameter Default Triggers When
autocleanspoolminpercent 1 Disk usage reaches 99%
autocleanmingb 5 Free space below 5 GB

When triggered, oldest data is deleted aggressively regardless of maxpool* settings until thresholds are cleared.

Reducing Data at Source

Before tuning retention, consider reducing data volume:

Save RTP Headers Only

If you only need call quality statistics (MOS, jitter, packet loss) without audio playback:

savertp = header

This reduces storage by up to 90% while preserving all quality metrics.

Selective Audio Recording

To record full audio only for specific calls (legal holds, VIP customers):

  1. Set global default to headers only: savertp = header
  2. Create capture rules in GUI (Control Panel > Capture Rules) with recordRTP=ON for exceptions

See Capture_rules for details.

The maxpool_clean_obsolete Parameter

Controls handling of files not in the index:

Setting Behavior
maxpool_clean_obsolete = no (default) Only delete indexed files. Unknown files are preserved.
maxpool_clean_obsolete = yes Delete ALL files in spool, including unindexed ones.

Database Cleaning (CDR Records)

Partitioning Method

VoIPmonitor uses daily partitioning for database tables. Dropping old partitions is instant (milliseconds) regardless of row count.

# Keep CDR records for 30 days
cleandatabase = 30
Parameter Default Description
cleandatabase 0 (disabled) Global retention in days
cleandatabase_cdr 0 CDR table retention
cleandatabase_register_state 0 Registration state retention
cleandatabase_register_time_info 0 Registration timing (must be set explicitly)
partition_operations_enable_fromto 1-5 Time window for partition operations
Important: register_time_info
The register_time_info table is NOT covered by global cleandatabase. Set cleandatabase_register_time_info explicitly to enable cleanup.

Size-Based Database Cleaning

To limit database by size instead of time:

cleandatabase_size = 512000        # 500 GB limit in MB
cleandatabase_size_force = true    # Required to enable

Limits

  • Partition limit: ~8000 partitions per table (~22 years with daily partitioning)
  • CDR record limit: No practical limit - uses BIGINT (18 quintillion records). See Upgrade_to_bigint.

Multi-Sensor Environments

When multiple sensors share a database, only ONE sensor should manage partitions:

# On all sensors EXCEPT one:
disable_partition_operations = yes

# On the designated sensor:
partition_operations_enable_fromto = 4-6

Advanced Topics

Spool Directory Location

Default location: /var/spool/voipmonitor

Directory structure: YYYY-MM-DD/HH/MM/{SIP|RTP|GRAPH|AUDIO}/files...

Relocating the Spool Directory

To move spool to a larger partition:

Step 1
Create new directory
mkdir -p /mnt/storage/voipmonitor
chown voipmonitor:voipmonitor /mnt/storage/voipmonitor
Step 2
Update sniffer configuration
# /etc/voipmonitor.conf
spooldir = /mnt/storage/voipmonitor
Step 3
Update GUI configuration

Edit GUI config file and set SNIFFER_DATA_PATH to match:

define('SNIFFER_DATA_PATH', '/mnt/storage/voipmonitor');
Step 4
Restart services
systemctl restart voipmonitor

Tiered Storage (tar_move)

To extend retention using secondary storage:

# Local fast storage for live capture
spooldir = /var/spool/voipmonitor

# Archive to secondary storage
tar_move = yes
tar_move_destination_path = /mnt/archive/voipmonitor

Files in tar_move_destination_path remain accessible via GUI.

S3 Cloud Storage

Use rclone instead of s3fs to avoid GUI unresponsiveness:

rclone mount bucket-name /mnt/s3-archive \
  --allow-other --dir-cache-time 30s --vfs-cache-mode off

Custom Autocleaning (GUI)

For one-time cleanup of specific recordings (e.g., by IP address):

  1. Navigate to Settings > Custom Autocleaning
  2. Create rule with filters (IP, phone number, etc.)
  3. Apply and remove rule after completion

Useful for cleaning old data after configuring capture rules to stop future recording.

Troubleshooting

Files Disappearing Faster Than Expected

Check these causes in order:

1. Emergency cleanup triggered
df -h /var/spool/voipmonitor
# If >95% full, emergency cleanup is active
2. GUI configuration override

When mysqlloadconfig = yes (default), GUI settings override config file. Check: Settings > Sensors > wrench icon.

3. Insufficient maxpoolsize

Set maxpoolsize to 90-95% of disk capacity to leave buffer for growth between cleanup cycles.

Disk Space Not Reclaimed After Database Cleanup

Check innodb_file_per_table:

SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table';

If OFF, space is not reclaimed when partitions drop. Enable for future tables:

[mysqld]
innodb_file_per_table = 1

MySQL Error 28: No Space Left

Primary solution - enable size-based cleaning:

cleandatabase_size = 512000
cleandatabase_size_force = true

Other causes:

  • Inode exhaustion: Check with df -i
  • MySQL tmpdir full: Check with SHOW VARIABLES LIKE 'tmpdir'

Database Not Cleaning

Verify tables are partitioned:

SHOW CREATE TABLE cdr\G

SELECT PARTITION_NAME, TABLE_ROWS
FROM information_schema.PARTITIONS
WHERE TABLE_NAME = 'cdr'
ORDER BY PARTITION_ORDINAL_POSITION DESC
LIMIT 10;

If only expected partitions exist (matching your cleandatabase setting), cleaning IS working - you may simply have high data volume.

Spool Filling Due to Database Bottleneck

If spool fills rapidly after disk swap or MySQL upgrade:

# Check SQL queue
tail -f /var/log/syslog | grep voipmonitor | grep SQLq

Growing SQLq indicates database cannot keep up. Solution:

[mysqld]
innodb_buffer_pool_size = 4G          # 50-70% of RAM
innodb_flush_log_at_trx_commit = 2    # Faster writes

See Also

AI Summary for RAG

Summary: VoIPmonitor has two independent data retention systems: (1) Filesystem cleaning for PCAP files using maxpoolsize/maxpooldays, running every 5 minutes; (2) Database cleaning using cleandatabase with daily partitioning.

Cleanspool: File index kept in memory for fast operations. .cleanspool_cache files in hourly directories (e.g., /var/spool/voipmonitor/2026-01-01/15/.cleanspool_cache) are for fast restart only.

Key parameters: maxpoolsize (default 100GB), maxpoolrtpsize/maxpoolrtpdays for RTP-specific limits, cleandatabase for CDR retention. Emergency cleanup via autocleanspoolminpercent (default 1%) and autocleanmingb (default 5GB) overrides settings when disk nearly full. GUI settings override config file when mysqlloadconfig=yes. Size-based database cleaning requires cleandatabase_size AND cleandatabase_size_force=true. Database partition limit ~8000 (~22 years); CDR uses BIGINT.

Keywords: data retention, maxpoolsize, maxpooldays, maxpoolrtpsize, cleandatabase, cleandatabase_size, .cleanspool_cache, autocleanspoolminpercent, autocleanmingb, tar_move, innodb_file_per_table, savertp header, BIGINT

Key Questions:

  • How does cleanspool work?
  • Where are .cleanspool_cache files?
  • Why are files deleted faster than expected?
  • How to fix MySQL Error 28?
  • How to configure size-based database cleaning?
  • How to extend retention with tiered storage?
  • Why is disk space not reclaimed after cleanup?