Billing: Difference between revisions

From VoIPmonitor.org
(Review: oprava struktury nadpisů, přidání kategorie, oprava překlepu)
Tag: Reverted
(Review: přidán hlavní nadpis, kategorie, opraveno formátování seznamů (bold), opravena hierarchie nadpisů, opraveny odkazy, opravena syntaktická chyba (.Settings), vylepšen AI Summary)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Scaling and Performance Tuning}}
= Billing =
[[Category:Administration]]
[[Category:GUI manual]]


This guide provides a comprehensive overview of performance tuning and scaling for VoIPmonitor. It covers the three primary system bottlenecks and offers practical, expert-level advice for optimizing your deployment for high traffic loads.
== Overview ==


== Understanding Performance Bottlenecks ==
* Two price types in CDR: Customer and operator (for comparing operators).
A VoIPmonitor deployment's maximum capacity is determined by three potential bottlenecks. Identifying and addressing the correct one is key to achieving high performance.
* Multiple billing tables: For each operator and customer.
* Billing watchdog rules: Quotas per hour/day/week/month aggregated by src IP or tel. number.
* Billing watchdog rules: For expensive destinations.


<kroki lang="plantuml">
== Settings > Billing Configuration ==
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}


title VoIPmonitor Performance Bottlenecks
Sections: Billing type/rules, state holidays, operator assignment, customer assignment, exclude, aggregation, currency, settings.


rectangle "Network\nInterface" as NIC #E8F4FD
=== Billing Type / Rules ===
rectangle "Packet Capture\n(t0 thread)" as T0 #FFE6E6
rectangle "RTP/SIP\nProcessing" as PROC #E6FFE6
rectangle "PCAP Files\nStorage" as DISK #FFF3E6
database "MySQL/MariaDB\nDatabase" as DB #E6E6FF


NIC -right-> T0 : "1. CPU\nBottleneck"
Create at least one billing table for customer/operator prices. For operator-only, create per operator and assign in "operator assignment" without "Default customer billing".
T0 -right-> PROC
PROC -down-> DISK : "2. I/O\nBottleneck"
PROC -right-> DB : "3. Database\nBottleneck"


note bottom of T0
* '''Name:''' Billing table name.
  Monitor: t0CPU in syslog
* '''State holidays:''' Assign holidays table for peak/offpeak.
  Limit: Single CPU core
* '''Default price:''' Per-minute (offpeak if peak/offpeak enabled).
end note
* '''Enable peak/offpeak:''' For time-based billing.
* '''Default price peak:''' Peak per-minute.
* '''Default T1:''' First impulse seconds.
* '''Default T2:''' Period length (e.g., 30s call, T1=10, T2=6: Bill 10 + 4*6 = 34s).
* '''Default customer billing:''' When enabled, applies the customer price (C:) from this table to all source IPs, even if not assigned to a specific customer. This is useful for reporting purposes when you want to ensure all calls show customer pricing, while operator prices (O:) are still determined by operator assignment rules based on destination IP.


note bottom of DISK
Add billing rules (CSV export/import):
  Monitor: iostat, ioping
  Solution: SSD, TAR archives
end note


note bottom of DB
* '''Name:''' Rule name.
  Monitor: SQLq in syslog
* '''Prefix number:''' Match prefix.
  Solution: Partitioning, tuning
* '''Fixed number:''' Match exact.
end note
* '''Price:''' Destination (offpeak if enabled).
@enduml
* '''Price peak:''' Peak destination.
</kroki>
* '''Override default peak/offpeak:''' Custom times.
* '''T1:''' Custom first impulse.
* '''T2:''' Custom period.


The three bottlenecks are:
==== Number Matching Type ====
# '''Packet Capturing (CPU & Network Stack):''' The ability of a single CPU core to read packets from the network interface. This is often the first limit encountered.
# '''Disk I/O (Storage):''' The speed at which the sensor can write PCAP files to disk. Critical when call recording is enabled.
# '''Database Performance (MySQL/MariaDB):''' The rate at which the database can ingest CDRs and serve data to the GUI.


On a modern, well-tuned server (e.g., 24-core Xeon, 10Gbit NIC), a single VoIPmonitor instance can handle up to '''10,000 concurrent calls''' with full RTP analysis and recording, or over '''60,000 concurrent calls''' with SIP-only analysis.
When creating prefix rules, choose how VoIPmonitor matches international prefixes:


== Optimizing Packet Capturing (CPU & Network) ==
* '''Original:''' Requires separate rules for each prefix format. For example, if users dial both <code>00420</code> and <code>+420</code>, you need two rules: one for <code>00420</code> and another for <code>+420</code>.
The most performance-critical task is the initial packet capture, handled by a single, highly optimized thread (t0). If this thread's CPU usage (<code>t0CPU</code> in logs) approaches 100%, you are hitting the capture limit.


=== Use a Modern Linux Kernel & VoIPmonitor Build ===
* '''Normalized:''' International prefixes are stripped before matching. A single rule for <code>420</code> will match calls to <code>00420</code>, <code>+420</code>, and just <code>420</code>. This is recommended for simpler configuration when international prefixes vary.
Modern Linux kernels (3.2+) and VoIPmonitor builds include '''TPACKET_V3''' support, a high-speed packet capture mechanism. This is the single most important factor for high performance.


'''Recommendation:''' Always use a recent Linux distribution (AlmaLinux, Rocky Linux, or Debian) and the latest VoIPmonitor static binary. With this combination, a standard Intel 10Gbit NIC can often handle up to 2 Gbit/s of VoIP traffic without special drivers.
The matching behavior is controlled by the "International prefixes" setting in the global Settings section (default: <code>00</code> and <code>+</code>).


=== Network Stack & Driver Tuning ===
=== State Holidays ===
For high-traffic environments (>500 Mbit/s), fine-tuning the network driver and kernel parameters is essential.


==== NIC Ring Buffer ====
Holidays table for offpeak treatment. Define only for peak/offpeak billing.
The ring buffer is a queue between the network card driver and VoIPmonitor. A larger buffer prevents packet loss during short CPU usage spikes.


<syntaxhighlight lang="bash">
=== Operator Assignment ===
# Check maximum size
ethtool -g eth0


# Set to maximum (e.g., 16384)
Rules per operator with billing table. Excludes customer price for operator calls (bills outgoing only). For both prices: One default customer table, assign operator tables here.
ethtool -G eth0 rx 16384
</syntaxhighlight>


==== Interrupt Coalescing ====
Override international prefixes per operator (see [[#Settings|Settings]]).
This setting batches multiple hardware interrupts into one, reducing CPU overhead.


<syntaxhighlight lang="bash">
=== Customer Assignment ===
ethtool -C eth0 rx-usecs 1022
</syntaxhighlight>


==== Applying Settings Persistently ====
Apply different tables to customers by src IP or tel. numbers/prefixes if default insufficient.
To make these settings permanent, add them to your network configuration. For Debian/Ubuntu using <code>/etc/network/interfaces</code>:


<syntaxhighlight lang="ini">
Override international prefixes per customer (see [[#Settings|Settings]]).
auto eth0
iface eth0 inet manual
    up ip link set $IFACE up
    up ip link set $IFACE promisc on
    up ethtool -G $IFACE rx 16384
    up ethtool -C $IFACE rx-usecs 1022
</syntaxhighlight>


Note: Modern systems using NetworkManager or systemd-networkd require different configuration methods.
=== Exclude ===


==== Configuration-Level Optimizations ====
Rules to exclude billing by src/dst IP or tel. prefixes/numbers.
Before investing in kernel-bypass solutions, ensure your <code>voipmonitor.conf</code> is optimized for performance. Several configuration parameters can significantly reduce CPU load and improve packet capture efficiency.


;Use interface_ip_filter Instead of filter
=== Aggregation ===
:If you need to filter by IP address or subnet, use <code>interface_ip_filter</code> instead of the general BPF <code>filter</code> option. The <code>interface_ip_filter</code> directive is more efficient and reduces CPU overhead compared to complex BPF filters.


<syntaxhighlight lang="ini">
Summarizes costs by src IP/tel. number for hour/day/week/month/year. Used in fraud/alerts for quota rules.
# More efficient IP-based filtering
interface_ip_filter = 192.168.0.0/24
interface_ip_filter = 10.0.0.0/8


# Less efficient BPF filtering (avoid if possible)
==== Settings ====
# filter = udp and (host 192.168.0.0/24 or host 10.0.0.0/8)
</syntaxhighlight>


{{Note|See [[Sniffer_configuration]] for the complete reference and description of <code>interface_ip_filter</code> (Interface Selection section).}}
* '''Enable by addresses:''' Per src IP.
* '''Enable by numbers:''' Per tel. number.
* '''Week start.'''
* '''Hours/days/weeks/months/years:''' Retention periods.


;Optimize PCAP Compression Threads
==== Exclude Addresses ====
:For systems with high call recording rates, PCAP compression can become CPU-intensive. VoIPmonitor can automatically scale compression threads.


<syntaxhighlight lang="ini">
Exclude src/dst IPs (e.g., operators/SIP proxies) for customer-only data.
# /etc/voipmonitor.conf
# Initial compression threads (auto-scales based on load)
pcap_dump_writethreads = 1


# Maximum compression threads (adjust based on CPU cores)
==== Exclude Numbers ====
pcap_dump_writethreads_max = 32


# Asynchronous PCAP writing (enabled by default)
Exclude src/dst numbers. Prioritize addresses to avoid unnecessary data.
pcap_dump_asyncwrite = yes
</syntaxhighlight>


{{Tip|Set <code>pcap_dump_writethreads_max</code> to the number of CPU cores available for best performance on multi-core systems. Monitor <code>t0CPU</code> to ensure compression threads are not competing with the capture thread.}}
=== Currency ===


;Adjust Jitterbuffer Settings Based on Traffic Patterns
Optional for single currency. Multiple: Recalculates to main via Google rates (view-only, not stored).
:Jitterbuffer simulation adds CPU overhead. For production environments with stable networks, consider adjusting jitterbuffer settings to balance accuracy with performance.


<syntaxhighlight lang="ini">
* '''Code:''' e.g., USD.
# /etc/voipmonitor.conf
* '''Custom code:''' Symbol, e.g., "$".
# Fixed 50ms jitterbuffer (default: yes)
* '''Name:''' Currency name.
jitterbuffer_f1 = yes
* '''Country:''' Select.
* '''Main currency:''' Recalculate all to this.
* '''Description.'''


# Fixed 200ms jitterbuffer (default: yes)
=== Settings ===
jitterbuffer_f2 = yes


# Adaptive jitterbuffer up to 500ms (default: yes)
* '''International prefixes:''' Distinguish local/international (default: 00, +).
jitterbuffer_adapt = yes
* '''Min. international length:''' Treat longer numbers as international if no prefix.
</syntaxhighlight>
* '''Local numbers are in:''' Prefix local numbers with international code for selected country.


{{Warning|Disabling jitterbuffer analysis reduces CPU load but removes MOS and jitter quality metrics from CDRs. Only disable if you do not require voice quality monitoring.}}
== Watchdog ==


=== Advanced Kernel-Bypass Solutions ===
In Alerts/Anti Fraud: Two rules requiring aggregation enabled.
If kernel and driver tuning are insufficient, you can offload the capture process entirely by bypassing the kernel's network stack.


{| class="wikitable"
=== Billing Over Quota ===
|-
! Solution !! Type !! CPU Reduction !! Use Case
|-
| '''[[DPDK]]''' || Open-source || ~70% || Multi-gigabit on commodity hardware
|-
| '''PF_RING ZC/DNA''' || Commercial || 90% → 20% || High-volume enterprise
|-
| '''Napatech SmartNICs''' || Hardware || <3% at 10 Gbit/s || Extreme performance requirements
|}


;DPDK (Data Plane Development Kit)
Checks billed sums per src IP/tel. number or groups for periods. Alerts on thresholds.
:A set of libraries and drivers for fast packet processing. VoIPmonitor can leverage DPDK to read packets directly from the network card, completely bypassing the kernel. See [[DPDK|DPDK guide]] for details.


;PF_RING ZC/DNA
* '''Enabled:''' On/off.
:A commercial software driver from ntop.org that dramatically reduces CPU load by bypassing the kernel.
* '''Every N minutes:''' Check frequency.
* '''Enable hyperlinks:''' Links in emails.
* '''Hour/day/week/month:''' Max costs.
* '''Summary:''' Aggregate included callers/IPs.
* '''Include/Exclude IP/numbers:''' Filter calls. None: Per individual IP/number.


;Napatech SmartNICs
=== Billing High Rate ===
:Specialized hardware acceleration cards that deliver packets with near-zero CPU overhead.


== Optimizing Disk I/O ==
Alerts on destinations > cost/minute threshold.
VoIPmonitor's modern storage engine is highly optimized to minimize random disk access, which is the primary cause of I/O bottlenecks.


=== VoIPmonitor Storage Strategy ===
* '''Enabled:''' On/off.
Instead of writing a separate PCAP file for each call (which causes massive I/O load), VoIPmonitor groups all calls starting within the same minute into a single compressed <code>.tar</code> archive. This changes the I/O pattern from thousands of small, random writes to a few large, sequential writes, reducing IOPS by a factor of 10 or more.
* '''Every N minutes:''' Check frequency.
* '''Enable hyperlinks:''' Links in emails.
* '''Limit:''' Cost/minute threshold.
* '''Include/Exclude IP/numbers:''' Filter calls. None: Per individual IP/number.


'''Typical capacity:''' A standard 7200 RPM SATA drive can handle up to 2,000 concurrent calls with full recording.
== Viewing Costs in Reports and CDR View ==


=== Filesystem Tuning (ext4) ===
After configuring billing, you may want to verify that costs are being calculated and then include them in reports.
For the spool directory (<code>/var/spool/voipmonitor</code>), using an optimized ext4 filesystem can improve performance.


<syntaxhighlight lang="bash">
=== Verifying Costs in CDR View ===
# Format partition without a journal (use with caution, requires battery-backed RAID controller)
mke2fs -t ext4 -O ^has_journal /dev/sda2


# Add to /etc/fstab for optimal performance
To verify that billing is working correctly, check if costs appear in your CDR records:
/dev/sda2  /var/spool/voipmonitor  ext4    errors=remount-ro,noatime,data=writeback,barrier=0 0 0
</syntaxhighlight>


{{Warning|Disabling the journal removes protection against filesystem corruption after crashes. Only use this with a battery-backed RAID controller.}}
# Navigate to the '''CDR''' view in the GUI
# Click the dropdown menu on the first column (column selection icon)
# Select '''PRICE''' from the list of available columns
# The PRICE column will now show Customer (C:) and Operator (O:) prices for each call


=== RAID Controller Cache Policy ===
If prices show as zero or empty, check:
A misconfigured RAID controller is a common bottleneck. For database and spool workloads, the cache policy should be set to '''WriteBack''', not WriteThrough. This applies for RPM disks, not fast SSDs.
* The billing system is enabled (Settings > Billing Configuration > Settings > "Enable by addresses" or "Enable by numbers")
* The source or destination IP is assigned to a billing table
* The called number matches a prefix or rule in the billing table
* The "Default customer billing" checkbox is enabled if you want customer prices applied to all calls


'''Requirements:'''
=== Including Costs in Daily Reports ===
* A healthy Battery Backup Unit (BBU) is required
* Specific commands vary by vendor (<code>megacli</code>, <code>ssacli</code>, <code>perccli</code>)
* Refer to vendor documentation for LSI, HP, and Dell controllers


== Optimizing Database Performance (MySQL/MariaDB) ==
To generate reports with call costs:
A well-tuned database is critical for both data ingestion from the sensor and GUI responsiveness.


{{Note|For extreme scenarios (4,000+ concurrent calls, UI lag, high SQL queue, or 1000+ CDRs/sec), see [[High-Performance_VoIPmonitor_and_MySQL_Setup_Manual]] for specialized configurations including innodb_flush_log_at_trx_commit=0, hourly partitioning, and centralized writer architecture.}}
# Navigate to '''GUI > Reports > Configure Daily Reports'''
# Select '''CDR summary''' as the report type
# Enable the '''Price columns''' option
# Configure the date range and any filters (e.g., specific trunks, IP addresses)
# Save the report configuration


=== Memory Configuration ===
The report will include cost information based on your billing configuration. See [[Reports|Reports]] for more details on report types.
The most critical database parameter is <code>innodb_buffer_pool_size</code>, which defines how much memory InnoDB uses to cache data and indexes.
 
{{Warning|On servers running both VoIPmonitor and MySQL, setting <code>innodb_buffer_pool_size</code> too high causes OOM (Out of Memory) killer events, resulting in CDR delays, crashes, and instability. See [[Sniffer_troubleshooting#Check_for_OOM_.28Out_of_Memory.29_Issues|OOM Troubleshooting]] for details.}}
 
==== Buffer Pool Sizing ====
 
{| class="wikitable"
|-
! Server Type !! Calculation !! Example (32GB RAM)
|-
| '''Shared''' (VoIPmonitor + MySQL) || (Total RAM - VoIPmonitor - OS overhead) / 2 || 14GB
|-
| '''Dedicated''' MySQL server || 50-70% of total RAM || 20-22GB
|}
 
For shared servers, use this formula:
<syntaxhighlight lang="text">
innodb_buffer_pool_size = (Total RAM - VoIPmonitor memory - OS overhead - safety margin) / 2
 
Example for a 32GB server:
- Total RAM: 32GB
- VoIPmonitor process memory: ~2GB (check with ps aux)
- OS + other services overhead: ~2GB
- Available for buffer pool: 28GB
- Recommended innodb_buffer_pool_size = 14G
</syntaxhighlight>
 
==== RAM Recommendations ====
{| class="wikitable"
|-
! Deployment Size !! Minimum RAM !! Recommended RAM
|-
| Small (<500 concurrent calls) || 8GB || 16GB
|-
| Medium (500-2000 calls) || 16GB || 32GB
|-
| Large (>2000 calls) || 32GB || 64GB+
|}
 
==== Disable Graphical Desktop ====
A graphical desktop environment consumes 1-2GB of RAM unnecessarily. VoIPmonitor is managed through a web interface and does not require a desktop.
 
<syntaxhighlight lang="bash">
# Disable display manager
systemctl stop gdm          # Ubuntu/Debian with GDM
systemctl disable gdm
 
# Set default to multi-user (no GUI)
systemctl set-default multi-user.target
 
# Verify memory freed
free -h
</syntaxhighlight>
 
=== Other Key Parameters ===
 
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf
 
[mysqld]
# Buffer pool size (calculate per above)
innodb_buffer_pool_size = 14G
 
# Flush logs to OS cache, write to disk once per second (faster, minimal data loss risk)
innodb_flush_log_at_trx_commit = 2
 
# Store each table in its own file (essential for partitioning)
innodb_file_per_table = 1
 
# LZ4 compression for modern MariaDB
innodb_compression_algorithm = lz4
</syntaxhighlight>
 
{{Warning|For deployments with 4,000+ concurrent calls experiencing UI unresponsiveness, database queue growth (SQLq), or extremely high CDR insertion rates (1000+ CDRs/sec), the intermediate settings above may not be sufficient. See [[High-Performance_VoIPmonitor_and_MySQL_Setup_Manual]] for extreme performance configurations optimized for 10,000+ concurrent calls, including innodb_flush_log_at_trx_commit=0, hourly partitioning, and centralized writer architecture.}}
 
=== Slow Query Log ===
 
The MySQL slow query log can consume significant memory and disk I/O on high-traffic systems. If you are experiencing high memory utilization alerts or performance issues with the database server, consider adjusting or disabling the slow query log.
 
{{Warning|Disabling the slow query log removes the ability to analyze slow queries for performance optimization. Only disable it temporarily or if you are certain you do not need it.}}
 
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf or /etc/my.cnf.d/mysql-server.cnf
 
[mysqld]
# Disable slow query log (set to 1 to enable)
slow_query_log = 0
 
# Alternative: Increase threshold to only log extremely slow queries (e.g., 600 seconds = 10 minutes)
long_query_time = 600
</syntaxhighlight>
 
After changing MySQL configuration, restart the database and dependent services:
 
<syntaxhighlight lang="bash">
# Restart MySQL/MariaDB
systemctl restart mariadb  # or mysql
 
# Restart VoIPmonitor sniffer (depends on database)
systemctl restart voipmonitor
</syntaxhighlight>
 
=== Troubleshooting: Connection Refused Errors ===
 
If the VoIPmonitor GUI or sniffer experiences crashes with "Can't connect to MySQL server" or "Connection refused" errors, verify that MariaDB is configured with adequate memory.
 
'''Symptoms:'''
* GUI server crashes repeatedly
* MariaDB connection refused errors in logs
* MariaDB service appears to be running (`systemctl status mariadb` shows active)
* Issues occur intermittently during peak call volumes
 
'''Cause:'''
When <code>innodb_buffer_pool_size</code> is set too low (e.g., default 128M or 256M), MariaDB may run out of memory for the InnoDB buffer pool during high call volumes or complex database queries. This can cause connection failures even while the database service remains technically running.
 
'''Solution:'''
Edit the MariaDB configuration file (path varies by distribution):
 
<syntaxhighlight lang="bash">
# Common configuration file locations:
# Debian/Ubuntu: /etc/mysql/mariadb.conf.d/50-server.cnf
# RHEL/CentOS: /etc/my.cnf.d/mariadb-server.cnf
# Generic: /etc/mysql/my.cnf
 
# Edit the file and increase innodb_buffer_pool_size
nano /etc/mysql/mariadb.conf.d/50-server.cnf
</syntaxhighlight>
 
Set a higher buffer pool size (example for a server with 8-16GB RAM):
 
<syntaxhighlight lang="ini">
[mysqld]
# Increase from default 128M to 6G or higher, depending on available RAM
innodb_buffer_pool_size = 6G
</syntaxhighlight>
 
Restart MariaDB to apply the change:
 
<syntaxhighlight lang="bash">
systemctl restart mariadb
</syntaxhighlight>
 
{{Tip|Use the [[#Buffer Pool Sizing|Buffer Pool Sizing formula]] above to calculate the optimal value for your server. For most production deployments with 500-2000 concurrent calls, values between 6G and 14G are typical.}}
 
=== Database Partitioning ===
VoIPmonitor automatically splits large tables (like <code>cdr</code>) into daily partitions. This is enabled by default and '''highly recommended'''.
 
'''Benefits:'''
* Massively improves GUI query performance (only relevant partitions are scanned)
* Allows instant deletion of old data by dropping partitions (thousands of times faster than DELETE)
 
See [[Data_Cleaning#The_Modern_Method:_Partitioning_.28Recommended.29|Database Partitioning]] for configuration details.
 
== Scaling Through Component Separation ==
 
For deployments requiring high availability and independent scaling of different workloads, VoIPmonitor's three core components (MySQL database, Sensor, and GUI) can be deployed on separate dedicated hosts. This architecture allows each component to be scaled based on its specific resource requirements.
 
=== When to Use Component Separation ===
 
Consider separating components when:
* You need to scale packet capture without affecting GUI responsiveness
* Database queries are becoming a bottleneck during peak hours
* You have multiple teams managing different aspects of the system (DBAs, network engineers, web administrators)
* You want to implement different high availability strategies for each component
* Your traffic volume exceeds 5,000-10,000 concurrent calls
 
=== Three-Host Architecture ===
 
In this model, each core VoIPmonitor component runs on a dedicated server:
 
{| class="wikitable"
|-
! Host !! Component !! Primary Resources !! Scaling Strategy
|-
| '''Host 1: MySQL Database''' || MariaDB/MySQL server || RAM (50-70% for buffer pool), fast I/O (SSD/NVMe) || Add RAM, upgrade storage, add read replicas for reporting
|-
| '''Host 2: Sensor(s)''' || Packet capture and analysis || Single CPU core (t0 thread), network I/O || Add more sensors for distributed capture, use DPDK/PF_RING
|-
| '''Host 3: GUI''' || Web interface (PHP + Apache/Nginx) || CPU for database queries, network bandwidth || Horizontal scaling with load balancer, caching
|}
 
=== Configuration Steps ===
 
==== Step 1: Deploy Dedicated MySQL Server ====
 
Configure the database server with proper MySQL/MariaDB tuning for VoIPmonitor. Use the dedicated server buffer pool sizing from [[#Memory_Configuration|Memory Configuration]].
 
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf on MySQL Host
[mysqld]
bind-address = 0.0.0.0  # Allow remote connections
innodb_buffer_pool_size = 50G  # 50-70% of total RAM for dedicated DB server
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1
innodb_compression_algorithm = lz4
</syntaxhighlight>
 
Grant access for remote connections:
 
<syntaxhighlight lang="sql">
CREATE USER 'voipmonitor'@'%' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'%';
FLUSH PRIVILEGES;
</syntaxhighlight>
 
==== Step 2: Deploy Sensor(s) ====
 
Install the VoIPmonitor sensor on one or more dedicated capture servers. Configure the sensor to connect to the remote MySQL database.
 
<syntaxhighlight lang="ini">
# /etc/voipmonitor.conf on Sensor Host
[general]
id_sensor = 1  # Unique per sensor
# Remote MySQL connection
mysqlhost = mysql.server.ip  # IP of dedicated MySQL server
mysqldb = voipmonitor
mysqluser = voipmonitor
mysqlpassword = strong_password
 
# Capture settings
interface = eth0
sipport = 5060,5061
 
# Performance tuning
pcap_dump_writethreads = 1
pcap_dump_writethreads_max = 32
</syntaxhighlight>
 
==== Step 3: Deploy Dedicated GUI ====
 
Install the VoIPmonitor GUI on a separate web server and configure it to connect to the remote MySQL database.
 
<syntaxhighlight lang="bash">
# Extract GUI package
tar -xzf voipmonitor-gui-latest.tar.gz -C /var/www/html/
 
# Edit GUI configuration
/var/www/html/voipmonitor/config/system_configuration.php
</syntaxhighlight>
 
Configure database connection through the GUI interface:
 
# Open <nowiki>http://gui.server.ip/voipmonitor</nowiki> in a browser
# Navigate to '''Settings > System Configuration > Database'''
# Configure:
# * Host: mysql.server.ip
# * User: voipmonitor
# * Password: strong_password
# * Database: voipmonitor
 
Alternatively, edit the configuration file directly:
 
<syntaxhighlight lang="php">
// /var/www/html/voipmonitor/config/system_configuration.php
define('DB_HOST', 'mysql.server.ip');
define('DB_USER', 'voipmonitor');
define('DB_PASS', 'strong_password');
define('DB_NAME', 'voipmonitor');
</syntaxhighlight>
 
==== Network Connectivity Requirements ====
 
Ensure firewall rules allow:
 
{| class="wikitable"
|-
! Source !! Destination !! Port !! Purpose
|-
| Sensor host || MySQL server || 3306 || Write CDRs to database
|-
| GUI host || MySQL server || 3306 || Read/Write for queries and configuration
|-
| User browsers || GUI host || 80, 443 || Access web interface
|-
| (Optional) GUI host || Sensor host(s) || 5029 || Retrieve PCAP files (if using local processing mode)
|}
 
=== Advantages of Component Separation ===
 
* '''Independent Scaling''' - Each component can be upgraded independently based on load
* '''Resource Optimization''' - Database servers need more RAM, sensors need fast CPUs, GUI needs network and query performance
* '''Isolation''' - Issues on one component do not affect others (e.g., GUI upgrade does not stop packet capture)
* '''Team Specialization''' - DBAs manage database, network engineers manage sensors, web team manages GUI
* '''High Availability Options''' - Different HA strategies for each component:
** MySQL: Galera cluster for multi-master replication
** Sensors: Client-server mode with failover
** GUI: Load balancer with multiple web servers
 
=== Comparison with Distributed Client-Server Mode ===
 
The three-host component separation architecture differs from [[Sniffer_distributed_architecture|Client-Server mode]]:
 
{| class="wikitable"
|-
! Architecture !! Scenario !! Best For
|-
| '''Component Separation (this section)''' || 3 dedicated hosts: MySQL + GUI + Sensor(s) || Single data center, independent scaling needs, centralized database
|-
| '''Client-Server Mode''' || Central server + remote sensors forwarding packets || Multi-site deployments, geographic distribution, low-resource remote sensors
|}
 
Both models can be combined: Use component separation at the central site, while remote sites use client-server mode to forward data.
 
=== Monitoring Component Health ===
 
Monitor each component separately:
 
* '''MySQL Server:''' Check <code>innodb_buffer_pool_size</code>, query throughput, slow queries
* '''Sensor(s):''' Monitor <code>t0CPU</code>, packet drops, SQL queue depth
* '''GUI Server:''' Monitor web server load, PHP-FPM statistics, page response times
 
Use the [[Sniffer_troubleshooting|Sniffer Troubleshooting]] guide for sensor issues and database performance tools for MySQL tuning.
 
== Monitoring Live Performance ==
VoIPmonitor logs detailed performance metrics every 10 seconds to syslog.
 
<syntaxhighlight lang="bash">
# Debian/Ubuntu
tail -f /var/log/syslog | grep voipmonitor
 
# CentOS/RHEL
tail -f /var/log/messages | grep voipmonitor
</syntaxhighlight>
 
=== Understanding the Log Output ===
Sample log line:
<syntaxhighlight lang="text">
voipmonitor[15567]: calls[315][355] PS[C:4 S:29/29 R:6354 A:6484] SQLq[0] heap[0|0|0] comp[54] [12.6Mb/s] t0CPU[5.2%] ... RSS/VSZ[323|752]MB
</syntaxhighlight>
 
{| class="wikitable"
|-
! Metric !! Description !! Warning Threshold
|-
| <code>calls[X][Y]</code> || X = active calls, Y = total calls in memory || -
|-
| <code>SQLq[C]</code> || SQL queries waiting to be sent to database || Growing consistently = DB bottleneck
|-
| <code>heap[A{{!}}B{{!}}C]</code> || Memory usage % for internal buffers || A = 100% → packet drops
|-
| <code>t0CPU[X%]</code> || '''Main packet capture thread CPU usage''' || >90-95% = capture limit reached
|-
| <code>RSS/VSZ[X{{!}}Y]MB</code> || Resident/Virtual memory usage || RSS growing = memory leak
|}
 
=== Performance Diagrams ===
 
The following diagrams illustrate the difference between standard kernel packet capture and optimized solutions:
 
[[File:kernelstandarddiagram.png|thumb|center|600px|Standard kernel packet capture path - packets traverse multiple kernel layers before reaching VoIPmonitor]]
 
[[File:ntop.png|thumb|center|600px|PF_RING/DPDK bypass mode - packets are delivered directly to VoIPmonitor, bypassing the kernel network stack]]
 
== See Also ==
* [[Sniffer_troubleshooting]] - Troubleshooting guide including OOM issues
* [[Data_Cleaning]] - Database and spool retention configuration
* [[Sniffer_configuration]] - Complete configuration reference
* [[DPDK]] - DPDK setup guide
* [[IO_Measurement]] - Disk I/O benchmarking tools


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' Expert guide to scaling VoIPmonitor for high-traffic environments. Covers three main bottlenecks: (1) Packet Capturing - optimized via TPACKET_V3, NIC tuning with ethtool (ring buffer, interrupt coalescing), configuration-level optimizations (interface_ip_filter more efficient than BPF filter, pcap_dump_writethreads for compression thread tuning, jitterbuffer settings for CPU/performance balance), and kernel-bypass solutions (DPDK, PF_RING, Napatech); (2) Disk I/O - VoIPmonitor uses TAR-based storage to reduce IOPS, with ext4 tuning and RAID WriteBack cache; (3) Database - critical innodb_buffer_pool_size tuning with formula for shared servers: (Total RAM - VoIPmonitor - OS overhead) / 2. For 32GB shared server, recommend 14GB buffer pool. Dedicated servers can use 50-70% of RAM. Covers slow query log as a memory/I/O consumer and disabling it for memory optimization. Covers partitioning benefits and syslog monitoring (t0CPU, SQLq, heap metrics). TROUBLESHOOTING: GUI or sniffer crashes with "MariaDB connection refused" errors indicate innodb_buffer_pool_size is set too low (e.g., default 128M or 256M). This causes MariaDB to run out of memory for the InnoDB buffer pool during high call volumes, resulting in connection failures even while the service remains active. Solution: Edit MariaDB config file (typically /etc/mysql/mariadb.conf.d/50-server.cnf or /etc/my.cnf.d/mariadb-server.cnf) and increase innodb_buffer_pool_size to 6G or higher based on available RAM. For most production deployments with 500-2000 concurrent calls, values between 6G and 14G are typical. Restart MariaDB with systemctl restart mariadb after changing the configuration. For extreme scenarios (4,000+ concurrent calls, UI lag, unresponsive GUI, high SQL queue), see High-Performance_VoIPmonitor_and_MySQL_Setup_Manual for specialized configurations including innodb_flush_log_at_trx_commit=0, hourly partitioning, centralized writer architecture, RTP thread tuning (rtpthreads, rtpthreads_start), and MySQL optimization settings (innodb_thread_concurrency, innodb_io_capacity, innodb_flush_method=O_DIRECT).


COMPONENT SEPARATION ARCHITECTURE: For deployments requiring independent scaling, VoIPmonitor's three core components (MySQL database, Sensor, and GUI) can be deployed on separate dedicated hosts. This architecture is recommended when needing to scale packet capture without affecting GUI responsiveness, database queries are becoming a bottleneck, multiple teams manage different aspects (DBAs, network engineers, web administrators), traffic volume exceeds 5,000-10,000 concurrent calls, or different HA strategies are needed. Three-Host Architecture: Host 1 is MySQL Database (needs 50-70% RAM for buffer pool, fast SSD/NVMe I/O, scale by adding RAM or read replicas, consider Galera cluster for HA); Host 2 is Sensor(s) (needs fast CPU single core for t0 thread and network I/O, scale by adding more sensors for distributed capture or use DPDK/PF_RING); Host 3 is GUI web interface (needs CPU for database queries and network bandwidth, can be horizontally scaled with load balancer and caching, use multiple web servers with load balancer for HA). Configuration: MySQL server with bind-address=0.0.0.0 and remote user access via CREATE USER 'voipmonitor'@'%' with GRANT ALL PRIVILEGES. Sensor configured with mysqlhost pointing to MySQL server IP. GUI configured via Settings > System Configuration > Database or by editing config/system_configuration.php to set DB_HOST, DB_USER, DB_PASS, DB_NAME. Network connectivity requires firewall rules: Sensor→MySQL (port 3306), GUI→MySQL (port 3306), Users→GUI (ports 80/443), GUI→Sensor(s) (port 5029 for PCAP retrieval if using local processing). Advantages: independent scaling, resource optimization (database needs RAM, sensors need CPU, GUI needs network), isolation (issues on one component don't affect others), team specialization, different HA strategies per component. Comparison with Client-Server Mode: Component Separation (3 dedicated hosts MySQL+GUI+Sensor) is best for single data center and independent scaling needs while Client-Server Mode (central server+remote sensors forwarding packets) is best for multi-site and geographic distribution with low-resource remote sensors. Both models can be combined. Monitor components separately: MySQL (innodb_buffer_pool_size, query throughput, slow queries), Sensors (t0CPU, packet drops, SQL queue), GUI (web server load, PHP-FPM, response times).
'''Summary:''' This article documents VoIPmonitor's billing features for tracking call costs. Features include: two price types (Customer and Operator), multiple billing tables per operator/customer, watchdog rules for quotas and expensive destinations. Configuration covers billing rules with peak/offpeak rates, state holidays, operator/customer assignment, exclusions, cost aggregation, and multi-currency support. Number matching can be "original" (exact prefix match) or "normalized" (strips international prefixes). Costs are viewable in CDR PRICE column and can be included in daily reports.


'''Keywords:''' scaling, performance tuning, bottleneck, t0CPU, TPACKET_V3, DPDK, PF_RING, ethtool, ring buffer, interface_ip_filter, BPF filter, pcap_dump_writethreads, jitterbuffer, jitterbuffer_f1, jitterbuffer_f2, jitterbuffer_adapt, compression threads, PCAP async write, innodb_buffer_pool_size, OOM killer, shared server memory, database partitioning, SQLq monitoring, slow query log, slow_query_log, long_query_time, UI lag, unresponsive GUI, high performance, 4000 concurrent calls, 5000 concurrent calls, innodb_flush_log_at_trx_commit=0, hourly partitioning, rtpthreads, rtpthreads_start, RTP threads, innodb_io_capacity, innodb_thread_concurrency, innodb_flush_method, extreme performance, High-Performance Manual, component separation, three host architecture, dedicated MySQL server, dedicated GUI server, remote database, mysqlhost configuration, GUI remote database, independent scaling, high availability, Galera cluster, load balancer, DB_HOST, DB_USER, DB_PASS, DB_NAME, bind-address, firewall ports, GUI settings database configuration, connection refused, MariaDB connection refused, GUI crashes, database connection errors, mariadb.conf.d/50-server.cnf, MySQL crash, MariaDB crash, can't connect to MySQL
'''Keywords:''' billing, customer price, operator price, billing tables, peak, offpeak, currency, watchdog, quota, high rate, PRICE column, daily reports, CDR summary, default customer billing, prefix number, normalized, original, international prefixes, number matching, T1, T2, impulse, aggregation


'''Key Questions:'''
'''Key Questions:'''
* How do I scale VoIPmonitor for thousands of concurrent calls?
* What are the key billing features in VoIPmonitor?
* What are the main performance bottlenecks in VoIPmonitor?
* How to create and configure billing tables and rules?
* How do I fix high t0CPU usage?
* What is the state holidays table used for in billing?
* What is DPDK and when should I use it?
* How to exclude calls from billing?
* How do I calculate innodb_buffer_pool_size for a shared server?
* How to handle multiple currencies in VoIPmonitor?
* What happens if innodb_buffer_pool_size is set too high?
* What are international prefix settings?
* What causes "MariaDB connection refused" errors in the GUI or sniffer?
* How do billing watchdog rules function?
* How do I fix GUI crashes due to MariaDB connection refused errors?
* How to view costs in the CDR view?
* How do I troubleshoot database connection issues with MariaDB?
* How to include costs in daily reports?
* How do I interpret the performance metrics in syslog?
* What does Default customer billing do?
* Should I use a dedicated database server for VoIPmonitor?
* What is the difference between normalized and original number matching for billing prefixes?
* How much RAM does a VoIPmonitor server need?
* How do I configure billing rates based on specific call number prefixes?
* How can the slow query log affect memory utilization?
* What are T1 and T2 billing parameters?
* How do I disable or adjust the MySQL slow query log?
* Is interface_ip_filter more efficient than the filter option?
* How do I optimize PCAP compression threads for high traffic?
* Which jitterbuffer settings affect CPU load the most?
* What configuration options reduce CPU overhead?
* How do I deploy VoIPmonitor with MySQL, GUI, and Sensor on separate servers?
* When should I use component separation architecture for VoIPmonitor?
* What is the three host architecture for VoIPmonitor scaling?
* How do I configure the GUI to connect to a remote MySQL database?
* How do I configure sensors to write to a remote MySQL server?
* What are the advantages of separating VoIPmonitor components onto different hosts?
* How do I scale the MySQL database independently from sensors and GUI?
* How do I scale the GUI independently from database and sensors?
* What is the difference between component separation and client-server mode?
* Can I combine component separation with client-server mode for VoIPmonitor?
* How do I configure firewall rules for component separation architecture?
* When should I use a dedicated GUI server for VoIPmonitor?

Latest revision as of 18:00, 6 January 2026

Billing

Overview

  • Two price types in CDR: Customer and operator (for comparing operators).
  • Multiple billing tables: For each operator and customer.
  • Billing watchdog rules: Quotas per hour/day/week/month aggregated by src IP or tel. number.
  • Billing watchdog rules: For expensive destinations.

Settings > Billing Configuration

Sections: Billing type/rules, state holidays, operator assignment, customer assignment, exclude, aggregation, currency, settings.

Billing Type / Rules

Create at least one billing table for customer/operator prices. For operator-only, create per operator and assign in "operator assignment" without "Default customer billing".

  • Name: Billing table name.
  • State holidays: Assign holidays table for peak/offpeak.
  • Default price: Per-minute (offpeak if peak/offpeak enabled).
  • Enable peak/offpeak: For time-based billing.
  • Default price peak: Peak per-minute.
  • Default T1: First impulse seconds.
  • Default T2: Period length (e.g., 30s call, T1=10, T2=6: Bill 10 + 4*6 = 34s).
  • Default customer billing: When enabled, applies the customer price (C:) from this table to all source IPs, even if not assigned to a specific customer. This is useful for reporting purposes when you want to ensure all calls show customer pricing, while operator prices (O:) are still determined by operator assignment rules based on destination IP.

Add billing rules (CSV export/import):

  • Name: Rule name.
  • Prefix number: Match prefix.
  • Fixed number: Match exact.
  • Price: Destination (offpeak if enabled).
  • Price peak: Peak destination.
  • Override default peak/offpeak: Custom times.
  • T1: Custom first impulse.
  • T2: Custom period.

Number Matching Type

When creating prefix rules, choose how VoIPmonitor matches international prefixes:

  • Original: Requires separate rules for each prefix format. For example, if users dial both 00420 and +420, you need two rules: one for 00420 and another for +420.
  • Normalized: International prefixes are stripped before matching. A single rule for 420 will match calls to 00420, +420, and just 420. This is recommended for simpler configuration when international prefixes vary.

The matching behavior is controlled by the "International prefixes" setting in the global Settings section (default: 00 and +).

State Holidays

Holidays table for offpeak treatment. Define only for peak/offpeak billing.

Operator Assignment

Rules per operator with billing table. Excludes customer price for operator calls (bills outgoing only). For both prices: One default customer table, assign operator tables here.

Override international prefixes per operator (see Settings).

Customer Assignment

Apply different tables to customers by src IP or tel. numbers/prefixes if default insufficient.

Override international prefixes per customer (see Settings).

Exclude

Rules to exclude billing by src/dst IP or tel. prefixes/numbers.

Aggregation

Summarizes costs by src IP/tel. number for hour/day/week/month/year. Used in fraud/alerts for quota rules.

Settings

  • Enable by addresses: Per src IP.
  • Enable by numbers: Per tel. number.
  • Week start.
  • Hours/days/weeks/months/years: Retention periods.

Exclude Addresses

Exclude src/dst IPs (e.g., operators/SIP proxies) for customer-only data.

Exclude Numbers

Exclude src/dst numbers. Prioritize addresses to avoid unnecessary data.

Currency

Optional for single currency. Multiple: Recalculates to main via Google rates (view-only, not stored).

  • Code: e.g., USD.
  • Custom code: Symbol, e.g., "$".
  • Name: Currency name.
  • Country: Select.
  • Main currency: Recalculate all to this.
  • Description.

Settings

  • International prefixes: Distinguish local/international (default: 00, +).
  • Min. international length: Treat longer numbers as international if no prefix.
  • Local numbers are in: Prefix local numbers with international code for selected country.

Watchdog

In Alerts/Anti Fraud: Two rules requiring aggregation enabled.

Billing Over Quota

Checks billed sums per src IP/tel. number or groups for periods. Alerts on thresholds.

  • Enabled: On/off.
  • Every N minutes: Check frequency.
  • Enable hyperlinks: Links in emails.
  • Hour/day/week/month: Max costs.
  • Summary: Aggregate included callers/IPs.
  • Include/Exclude IP/numbers: Filter calls. None: Per individual IP/number.

Billing High Rate

Alerts on destinations > cost/minute threshold.

  • Enabled: On/off.
  • Every N minutes: Check frequency.
  • Enable hyperlinks: Links in emails.
  • Limit: Cost/minute threshold.
  • Include/Exclude IP/numbers: Filter calls. None: Per individual IP/number.

Viewing Costs in Reports and CDR View

After configuring billing, you may want to verify that costs are being calculated and then include them in reports.

Verifying Costs in CDR View

To verify that billing is working correctly, check if costs appear in your CDR records:

  1. Navigate to the CDR view in the GUI
  2. Click the dropdown menu on the first column (column selection icon)
  3. Select PRICE from the list of available columns
  4. The PRICE column will now show Customer (C:) and Operator (O:) prices for each call

If prices show as zero or empty, check:

  • The billing system is enabled (Settings > Billing Configuration > Settings > "Enable by addresses" or "Enable by numbers")
  • The source or destination IP is assigned to a billing table
  • The called number matches a prefix or rule in the billing table
  • The "Default customer billing" checkbox is enabled if you want customer prices applied to all calls

Including Costs in Daily Reports

To generate reports with call costs:

  1. Navigate to GUI > Reports > Configure Daily Reports
  2. Select CDR summary as the report type
  3. Enable the Price columns option
  4. Configure the date range and any filters (e.g., specific trunks, IP addresses)
  5. Save the report configuration

The report will include cost information based on your billing configuration. See Reports for more details on report types.

AI Summary for RAG

Summary: This article documents VoIPmonitor's billing features for tracking call costs. Features include: two price types (Customer and Operator), multiple billing tables per operator/customer, watchdog rules for quotas and expensive destinations. Configuration covers billing rules with peak/offpeak rates, state holidays, operator/customer assignment, exclusions, cost aggregation, and multi-currency support. Number matching can be "original" (exact prefix match) or "normalized" (strips international prefixes). Costs are viewable in CDR PRICE column and can be included in daily reports.

Keywords: billing, customer price, operator price, billing tables, peak, offpeak, currency, watchdog, quota, high rate, PRICE column, daily reports, CDR summary, default customer billing, prefix number, normalized, original, international prefixes, number matching, T1, T2, impulse, aggregation

Key Questions:

  • What are the key billing features in VoIPmonitor?
  • How to create and configure billing tables and rules?
  • What is the state holidays table used for in billing?
  • How to exclude calls from billing?
  • How to handle multiple currencies in VoIPmonitor?
  • What are international prefix settings?
  • How do billing watchdog rules function?
  • How to view costs in the CDR view?
  • How to include costs in daily reports?
  • What does Default customer billing do?
  • What is the difference between normalized and original number matching for billing prefixes?
  • How do I configure billing rates based on specific call number prefixes?
  • What are T1 and T2 billing parameters?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Billing&oldid=9118"