Cloud: Difference between revisions

From VoIPmonitor.org
(Add Quick Start section with automated installation script method for connecting to cloud)
(Fix cloud configuration: replace incorrect server_destination/packetbuffer_sender with correct cloud_token parameter)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
= VoIPmonitor Cloud Service Architecture =
= VoIPmonitor Cloud Service =


This document details the architecture of the '''VoIPmonitor Cloud Service'''. In this service model, the customer is responsible only for running the on-premise sniffer, while the database and web GUI are hosted and managed by VoIPmonitor.
The '''VoIPmonitor Cloud Service''' is a managed hosting model where you run only the on-premise sniffer, while VoIPmonitor hosts and manages the database and web GUI.


== Service Specifications ==
== Service Specifications ==


The VoIPmonitor Cloud Service has the following service limits and specifications:
{| class="wikitable"
! Specification !! Value
|-
| Max Concurrent Channels || 2000
|-
| CDR Retention || 25 days
|-
| PCAP Storage || Local only (on sniffer, not in cloud)
|}


* '''Concurrent Channels Maximum:''' The service supports up to '''2000 concurrent channels'''.
{{Note|If your requirements exceed these limits, consider an on-premise deployment.}}
* '''CDR Retention Period:''' Call Detail Records (CDRs) are retained for '''25 days''' in the cloud database.
* '''PCAP Storage Location:''' SIP+RTP packet storage (PCAP files) is NOT stored in the cloud. If packet capture storage is enabled, all PCAP files are stored on the '''local sniffer's storage''' only.


These limits are fixed and apply to all Cloud Service customers. If your requirements exceed these specifications, consider an on-premise VoIPmonitor deployment.
== Architecture ==


== Quick Start: Connecting Your Server to the Cloud ==
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart LR
    subgraph Customer["Customer Network"]
        S1[Sniffer 1]
        S2[Sniffer 2]
        PBX[PBX/SIP Server]
    end


The fastest way to connect your on-premise VoIP server to the VoIPmonitor Cloud service is to use the automated installation script.
    subgraph Cloud["VoIPmonitor Cloud"]
        DB[(Database)]
        GUI[Web GUI]
    end


=== Method: Automated Installation Script (Recommended) ===
    PBX -->|Traffic| S1
    PBX -->|Traffic| S2
    S1 -->|CDR Metadata| DB
    S2 -->|CDR Metadata| DB
    DB --> GUI
    GUI -->|On-demand PCAP| S1
    GUI -->|On-demand PCAP| S2
</kroki>


This method automatically configures your sniffer to send data to the cloud GUI.
=== Data Flow ===


;Step 1: Download the Installation Script
* '''Sniffer (Client):''' Captures and processes VoIP traffic locally. Multiple sniffers can connect from different locations.
* Log in to the '''VoIPmonitor Portal''' at https://www.voipmonitor.org/portal/
* '''Cloud (Server):''' Hosts the database (CDR metadata) and web GUI for analysis and reporting.
* Navigate to your '''Licenses''' section
* In the list of your licensed products, locate the '''Cloud Service installation script'''
* Download the script (it will be a small shell script with a .sh extension)


;Step 2: Run the Script on Your Sniffer Server
=== How Data is Transferred ===
* Upload or copy the script to your sniffer server (the machine that will capture VoIP traffic)
 
* Make the script executable and run it with root or sudo privileges:
;Standard Mode (Default)
<pre>
The sniffer analyzes traffic locally and sends '''only CDR metadata''' to the cloud. Voice packets (PCAP) are discarded after analysis. This minimizes bandwidth usage.
 
;On-Demand PCAP Retrieval
If packet capture is enabled via [[Capture_rules|Capture Rules]], PCAPs are stored '''locally on the sniffer'''. When a user requests a PCAP through the cloud GUI, the file streams directly from the sniffer to the user's browser - it is never uploaded to the cloud.
 
== Quick Start ==
 
=== Free Trial ===
 
# Log in to [https://www.voipmonitor.org/portal/ VoIPmonitor Portal]
# Navigate to '''my services'''
# Order the free 30-day Cloud GUI trial
 
=== Method 1: Installation Script (Recommended) ===
 
# Download the installation script from VoIPmonitor Portal ('''my services''' > your Cloud service)
# Run on your sniffer server:
<syntaxhighlight lang="bash">
chmod +x voipmonitor-cloud-install.sh
chmod +x voipmonitor-cloud-install.sh
sudo ./voipmonitor-cloud-install.sh
sudo ./voipmonitor-cloud-install.sh
</pre>
</syntaxhighlight>
 
The script automatically installs and configures everything.


The script will automatically:
=== Method 2: Manual Configuration ===
* Download and install the latest voipmonitor sniffer binary
* Configure <code>voipmonitor.conf</code> with the correct cloud server settings
* Set up the service to start automatically
* Connect to your cloud account using your license key


;Step 3: Verify Connection
Edit <code>/etc/voipmonitor.conf</code>:
* After the script completes, wait a few seconds for the sensor to register
* Log in to your VoIPmonitor Cloud GUI
* Your sensor should automatically appear in the dashboard


This is the recommended method as it eliminates manual configuration errors and ensures all settings are correct.
<syntaxhighlight lang="ini">
# Cloud authentication token (obtain from VoIPmonitor Portal)
cloud_token = your_cloud_token_here


=== Method: Manual Configuration ===
# Ensure all MySQL parameters are commented out or removed:
#mysqlhost = ...
#mysqldb = ...
#mysqlusername = ...
#mysqlpassword = ...
</syntaxhighlight>


If you prefer to configure your sniffer manually (for example, if you already have voipmonitor installed), follow the steps in the [[#Core Architecture:_Client-Server_Model|Core Architecture]] and [[#General_Configuration_Verification|Configuration Verification]] sections below. You will need to set:
<syntaxhighlight lang="bash">
systemctl restart voipmonitor
</syntaxhighlight>


* <code>server_destination = cloud.voipmonitor.org</code>
{{Note|1=The <code>cloud_token</code> is unique to your account and can be found in [https://www.voipmonitor.org/portal/ VoIPmonitor Portal] under '''my services''' > your Cloud service.}}
* <code>server_destination_port = 60023</code>
* <code>packetbuffer_sender = yes</code>


== Core Architecture: Client-Server Model ==
== AWS EC2 Configuration ==


The architecture separates the data capture process (on-premise) from the data storage and analysis interface (in the cloud).
When deploying on AWS, configure resource limits to prevent memory exhaustion and disk full conditions.


*  '''Sniffer (Client):''' A VoIPmonitor sniffer runs on the customer's network (either on a dedicated machine or the PBX itself). Its only job is to capture and process VoIP traffic locally. Multiple sniffers can be deployed across various locations.
=== Required Parameters ===
*  '''Cloud Platform (Server):''' The central database (storing call metadata) and the web GUI are hosted and managed by VoIPmonitor. All user interaction, analysis, and reporting is done through this central cloud interface.


=== Data Flow from Sniffer to Cloud ===
{| class="wikitable"
! Parameter !! Purpose !! Recommended Value
|-
| <code>ringbuffer</code> || Packet capture buffer size (MB) || 50-100 (low traffic), 500-1000 (medium), 1000-2000 (high)
|-
| <code>max_buffer_mem</code> || Max memory for buffers (MB) || 500 for t3.small, 2000 for m5.large+
|-
| <code>maxpoolsize</code> || Max PCAP storage (MB) || Set to ~80% of available disk
|-
| <code>spooldir</code> || PCAP storage path || Use EBS volume (gp3/io2), not instance store
|}


The key aspect of the cloud architecture is how data is transmitted from the customer's sniffer to the hosted server. The system primarily operates in one of two modes.
{{Warning|1=Always set <code>maxpoolsize</code> - without it, VoIPmonitor will fill the disk until the system crashes.}}


==== 1. Standard Mode: Local Processing & CDR Upload ====
=== Example AWS Configuration ===


This is the default and most efficient mode. The on-premise sniffer captures all VoIP traffic, analyzes it locally, and generates a '''Call Detail Record (CDR)''' for each call.
For m5.large (8GB RAM, 100GB EBS gp3):


*  The sniffer sends '''only the CDR metadata''' to the cloud database.
<syntaxhighlight lang="ini">
*  The actual voice packets (PCAP) are '''not''' sent to the cloud; they are discarded after local analysis.
# Cloud authentication
cloud_token = your_cloud_token_here


This model ensures minimal bandwidth usage, as only small metadata files are transferred over the internet.
# Sensor ID
id_sensor = 1


==== 2. Optional Mode: On-Demand Packet Capture Retrieval ====
# Capture interface (typically eth0 or ens5 on AWS)
interface = eth0


For deep diagnostics, users can enable packet capture storage. The process is designed to keep sensitive data on-premise unless explicitly needed.
# AWS resource limits
ringbuffer = 500
max_buffer_mem = 2000
spooldir = /var/spool/voipmonitor
maxpoolsize = 102400
 
# MySQL parameters must NOT be configured for cloud mode
</syntaxhighlight>


# '''Selective Local Storage:''' Storing packet captures is not an all-or-nothing feature. The user defines granular '''Capture Rules''' to control exactly which calls are saved. These rules can be based on criteria like IP addresses, telephone numbers, or even specific SIP packet headers. Only calls that match a rule will have their PCAP file saved to the sniffer's '''local disk'''.
=== AWS License Fix ===
# '''On-Demand Request:''' A user can request to download a PCAP file or listen to a call through the cloud web GUI.
# '''Direct Download:''' The cloud platform instructs the sniffer to serve the requested file. The download then occurs directly from the customer's sniffer to the user's browser, bypassing a permanent upload to the cloud.


This on-demand mechanism ensures that large and sensitive packet capture files remain within the customer's network perimeter, only traversing the internet when requested by an authorized user.
AWS EC2 instances require this permission for license checks:


== Troubleshooting: Sensor Not Appearing in Cloud ==
<syntaxhighlight lang="bash">
chmod 644 /dev/root
</syntaxhighlight>


If your on-premise sniffer is running but does not appear in the VoIPmonitor Cloud interface, follow these troubleshooting steps.


=== Common Issue: ARM64 Cloud Connectivity Bug ===


On ARM64 architecture systems (aarch64), certain voipmonitor binary builds have a known cloud connectivity issue where the sensor runs locally but fails to properly handshake with the cloud server.
=== Resizing EC2 Instances ===


;Symptoms:
When resizing an EC2 instance to a different size, you '''must''' adjust <code>max_buffer_mem</code> and <code>ringbuffer</code> to fit the new instance's RAM limits. If you keep old settings from a larger instance, VoIPmonitor may crash or fail to start due to insufficient memory.
:* The <code>voipmonitor</code> process is running and appears active with <code>systemctl status voipmonitor</code>
:* The sensor is capturing traffic locally (check via <code>journalctl -u voipmonitor -f</code>)
:* No sensor appears in your VoIPmonitor Cloud interface
:* Configuration is correct (<code>server_destination</code>, <code>server_destination_port</code>, <code>packetbuffer_sender</code>)
:* Firewall rules allow outbound TCP to port 60023


;Solution: Update to the Corrected ARM64 Binary
==== Buffer Memory Formula ====


This issue is resolved by downloading and installing a special static binary build that includes the ARM64 cloud connectivity fix.
The total memory allocated for buffers is calculated as:


<syntaxhighlight lang="bash">
''Allocated RAM for Buffers = max_buffer_mem + count(interface) x ringbuffer''
# 1. Stop the voipmonitor service
systemctl stop voipmonitor


# 2. Request the corrected ARM64 static binary from VoIPmonitor support
Ensure this total fits within your instance's available RAM, leaving room for other processes (GUI, database, operating system).
# The support team will provide a specific download link for the corrected build
# Example URL format:
# wget https://download.voipmonitor.org/path/to/voipmonitor-arm64-fixed.tar.gz


# 3. Extract the archive
==== Reducing Instance Size Example ====
tar xzf voipmonitor-arm64-fixed.tar.gz
cd voipmonitor-*-static


# 4. Backup the existing binary and replace it
Resizing from '''c7i.4xlarge''' (32GB RAM) to '''c7i.xlarge''' (8GB RAM):
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor /usr/local/sbin/voipmonitor


# 5. Restart the service
Before resize (32GB instance):
systemctl start voipmonitor
<syntaxhighlight lang="ini">
ringbuffer = 500
max_buffer_mem = 6000  # Total: 6000 + 1 x 500 = 6500 MB = 6.35 GB
</syntaxhighlight>


# 6. Verify the sensor appears in Cloud interface
After resize (8GB instance):
journalctl -u voipmonitor -f
<syntaxhighlight lang="ini">
ringbuffer = 200
max_buffer_mem = 1000  # Total: 1000 + 1 x 200 = 1200 MB = 1.17 GB
</syntaxhighlight>
</syntaxhighlight>


;Important Notes:
==== Increasing Instance Size ====
:* Do NOT compile from source to fix this issue - use the corrected static binary provided by support
 
:* The fix is specific to ARM64 architecture; x86_64 and 32-bit systems are not affected
When moving to a larger instance, you can increase buffer limits to handle higher traffic volumes. See [[Scaling|Scaling Guide]] for tuning guidance.
:* After installing the corrected binary, the sensor should appear in Cloud within a few seconds
 
{{Warning|1=Always restart the VoIPmonitor service after changing buffer settings: <code>systemctl restart voipmonitor</code>}}
 
== Troubleshooting ==
 
=== Sensor Not Appearing in Cloud ===


=== General Configuration Verification ===
;First-Time Setup: Initialize Database
If you see '''failed read rsa key''' or '''loss connection''' errors, you must first log in to the Cloud GUI to initialize your database:


If the ARM64 issue is not applicable, verify your cloud connectivity configuration:
# Log in to [https://cloud.voipmonitor.org Cloud GUI] with your portal credentials
# This creates the necessary database tables
# Restart the sniffer: <code>systemctl restart voipmonitor</code>
# Verify sensor appears green in '''Settings -> Sensors'''


;1. Check voipmonitor.conf cloud settings:
;Verify Configuration
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
grep -E "server_destination|packetbuffer_sender" /etc/voipmonitor.conf
grep -E "cloud_token" /etc/voipmonitor.conf
</syntaxhighlight>
</syntaxhighlight>


Required for VoIPmonitor Cloud:
Required setting:
<pre>
<syntaxhighlight lang="ini">
server_destination = cloud.voipmonitor.org
cloud_token = your_cloud_token_here
server_destination_port = 60023
</syntaxhighlight>
packetbuffer_sender = yes
</pre>


;2. Verify network connectivity to cloud:
Also verify that MySQL parameters are commented out or removed.
 
;Check Network Connectivity
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Test outbound connection to VoIPmonitor Cloud
nc -zv cloud.voipmonitor.org 443
nc -zv cloud.voipmonitor.org 60023
</syntaxhighlight>
</syntaxhighlight>


;3. Check for firewall issues:
Ensure outbound HTTPS (TCP 443) is allowed through all firewalls (local, corporate, cloud provider).
* Ensure outbound TCP traffic to <code>cloud.voipmonitor.org:60023</code> is allowed
* Check local firewall (ufw, firewalld, iptables)
* Check corporate or cloud provider firewalls


;4. Verify sensor IDs match:
;ARM64 Architecture Issue
* If <code>id_sensor</code> is set in <code>voipmonitor.conf</code>, ensure it is unique (no collision with other sensors)
On ARM64 (aarch64) systems, a known bug prevents cloud connectivity. Contact VoIPmonitor support for a corrected ARM64 static binary.
* The sensor ID should match what you expect to see in the Cloud interface


;5. Review logs for errors:
Symptoms:
* Sensor runs locally (visible in logs)
* Configuration is correct
* Firewall allows traffic
* Sensor does not appear in Cloud GUI
 
Solution:
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Check cloud-specific connection errors
systemctl stop voipmonitor
journalctl -u voipmonitor -f | grep -i "cloud\|server\|connection"
# Download corrected binary from support
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor-arm64-fixed /usr/local/sbin/voipmonitor
systemctl start voipmonitor
</syntaxhighlight>
</syntaxhighlight>
== See Also ==
* [[Sniffer_distributed_architecture]] - Client-server architecture details
* [[Capture_rules]] - Configuring selective PCAP storage
* [[Sniffer_configuration]] - All sniffer configuration parameters


== AI Summary for RAG ==
== AI Summary for RAG ==
Summary: This document explains the VoIPmonitor Cloud Service, a client-server architecture where the customer runs one or more sniffer clients on-premise, while VoIPmonitor hosts the database and web GUI. Quick Start section covers the automated installation script method: log in to VoIPmonitor Portal, navigate to Licenses section, download the Cloud Service installation script, run it on the sniffer server with sudo. The script automatically downloads/install sniffer binary, configures voipmonitor.conf with cloud settings, sets up the service, and connects to cloud account using license key. Alternative manual configuration method requires setting server_destination=cloud.voipmonitor.org, server_destination_port=60023, packetbuffer_sender=yes. The sniffer's primary mode involves local processing of VoIP traffic, sending only lightweight Call Detail Records (CDRs) to the cloud. Full packet captures (PCAPs) are not automatically uploaded; instead, they are selectively stored on the local sniffer based on user-defined 'capture rules' (e.g., by IP address, phone number, or SIP headers). These stored PCAPs can be downloaded on-demand directly from the sniffer when requested by a user through the cloud GUI. This model is for users who want to avoid managing server infrastructure. Service limits: 2000 concurrent channels maximum, 25 days CDR retention, PCAPs stored locally only. Troubleshooting section covers ARM64 cloud connectivity issue where sensor runs locally but does not appear in cloud - requires corrected static binary from support, not configuration changes. Also includes general troubleshooting steps: verify server_destination=cloud.voipmonitor.org, server_destination_port=60023, packetbuffer_sender=yes, test nc -zv cloud.voipmonitor.org 60023, check firewall rules, verify unique id_sensor, review logs with journalctl -u voipmonitor -f | grep -i "cloud|server|connection".
 
Keywords: cloud service, cloud architecture, client-server, on-premise sniffer, hosted database, hosted GUI, installation script, automated setup, manual configuration, local processing, CDR, Call Detail Record, local storage, packet capture, PCAP, on-demand download, capture rules, SIP headers, managed service, troubleshooting, ARM64, cloud connectivity bug, sensor not appearing, server_destination, server_destination_port, packetbuffer_sender, firewall
'''Summary:''' VoIPmonitor Cloud Service is a managed hosting model where customer runs on-premise sniffer while VoIPmonitor hosts database and web GUI. Service limits: 2000 concurrent channels, 25 days CDR retention, PCAP stored locally only. Free 30-day trial via portal. Setup: use installation script from portal or manually configure <code>server_destination=cloud.voipmonitor.org</code>, <code>server_destination_port=60023</code>, <code>packetbuffer_sender=yes</code>. Sniffer sends only CDR metadata to cloud; PCAPs stay local and stream on-demand. AWS deployment requires resource limits: <code>ringbuffer</code>, <code>max_buffer_mem</code>, <code>maxpoolsize</code> (critical to prevent disk full), and <code>chmod 644 /dev/root</code> for license. Troubleshooting: first-time users must log into Cloud GUI to initialize database (fixes "failed read rsa key"); ARM64 requires special binary from support.
Key Questions:
 
* How do I connect my on-premise server to VoIPmonitor Cloud?
'''Keywords:''' cloud service, hosted GUI, on-premise sniffer, server_destination, packetbuffer_sender, port 60023, CDR metadata, PCAP local storage, on-demand download, AWS, EC2, ringbuffer, max_buffer_mem, maxpoolsize, EBS volume, ARM64, cloud database initialization, failed read rsa key, loss connection, free trial, 2000 channels, 25 days retention
* What is the fastest way to set up cloud connectivity?
 
* How do I use the automated installation script?
'''Key Questions:'''
* Where do I download the cloud installation script?
* How do I connect my sniffer to VoIPmonitor Cloud?
* Can I configure the sniffer manually instead of using the script?
* What are the required voipmonitor.conf settings for cloud connectivity?
* How does the VoIPmonitor Cloud Service architecture work?
* Who is the cloud service intended for?
* Is my call data (PCAP) stored in the cloud?
* Is my call data (PCAP) stored in the cloud?
* How can I control which calls have their packet captures saved?
* How do I configure VoIPmonitor on AWS EC2?
* How are Call Detail Records (CDRs) and packet captures (PCAPs) handled differently?
* What is the recommended maxpoolsize for AWS instances?
* What data does the on-premise sniffer send to the cloud?
* Why is my sensor not appearing in Cloud interface?
* How can I access a full packet capture for a specific call?
* How do I fix "failed read rsa key" error?
* What are the main benefits of this cloud model?
* Does VoIPmonitor Cloud offer a free trial?
* Why does my ARM64 sensor not appear in the VoIPmonitor Cloud interface?
* What are the cloud service limits (channels, retention)?
* How do I fix the ARM64 cloud connectivity issue?
* How do I fix ARM64 cloud connectivity issues?
* What are the required voipmonitor.conf settings for VoIPmonitor Cloud?
* How do I test if my firewall is blocking cloud connectivity?

Latest revision as of 14:13, 23 January 2026

VoIPmonitor Cloud Service

The VoIPmonitor Cloud Service is a managed hosting model where you run only the on-premise sniffer, while VoIPmonitor hosts and manages the database and web GUI.

Service Specifications

Specification Value
Max Concurrent Channels 2000
CDR Retention 25 days
PCAP Storage Local only (on sniffer, not in cloud)

ℹ️ Note: If your requirements exceed these limits, consider an on-premise deployment.

Architecture

Data Flow

  • Sniffer (Client): Captures and processes VoIP traffic locally. Multiple sniffers can connect from different locations.
  • Cloud (Server): Hosts the database (CDR metadata) and web GUI for analysis and reporting.

How Data is Transferred

Standard Mode (Default)

The sniffer analyzes traffic locally and sends only CDR metadata to the cloud. Voice packets (PCAP) are discarded after analysis. This minimizes bandwidth usage.

On-Demand PCAP Retrieval

If packet capture is enabled via Capture Rules, PCAPs are stored locally on the sniffer. When a user requests a PCAP through the cloud GUI, the file streams directly from the sniffer to the user's browser - it is never uploaded to the cloud.

Quick Start

Free Trial

  1. Log in to VoIPmonitor Portal
  2. Navigate to my services
  3. Order the free 30-day Cloud GUI trial

Method 1: Installation Script (Recommended)

  1. Download the installation script from VoIPmonitor Portal (my services > your Cloud service)
  2. Run on your sniffer server:
chmod +x voipmonitor-cloud-install.sh
sudo ./voipmonitor-cloud-install.sh

The script automatically installs and configures everything.

Method 2: Manual Configuration

Edit /etc/voipmonitor.conf: 

# Cloud authentication token (obtain from VoIPmonitor Portal)
cloud_token = your_cloud_token_here

# Ensure all MySQL parameters are commented out or removed:
#mysqlhost = ...
#mysqldb = ...
#mysqlusername = ...
#mysqlpassword = ...

systemctl restart voipmonitor

ℹ️ Note: The cloud_token is unique to your account and can be found in VoIPmonitor Portal under my services > your Cloud service.

AWS EC2 Configuration

When deploying on AWS, configure resource limits to prevent memory exhaustion and disk full conditions.

Required Parameters

Parameter Purpose Recommended Value
ringbuffer Packet capture buffer size (MB) 50-100 (low traffic), 500-1000 (medium), 1000-2000 (high)
max_buffer_mem Max memory for buffers (MB) 500 for t3.small, 2000 for m5.large+
maxpoolsize Max PCAP storage (MB) Set to ~80% of available disk
spooldir PCAP storage path Use EBS volume (gp3/io2), not instance store

⚠️ Warning: Always set maxpoolsize - without it, VoIPmonitor will fill the disk until the system crashes.

Example AWS Configuration

For m5.large (8GB RAM, 100GB EBS gp3): 

# Cloud authentication
cloud_token = your_cloud_token_here

# Sensor ID
id_sensor = 1

# Capture interface (typically eth0 or ens5 on AWS)
interface = eth0

# AWS resource limits
ringbuffer = 500
max_buffer_mem = 2000
spooldir = /var/spool/voipmonitor
maxpoolsize = 102400

# MySQL parameters must NOT be configured for cloud mode

AWS License Fix

AWS EC2 instances require this permission for license checks: 

chmod 644 /dev/root


Resizing EC2 Instances

When resizing an EC2 instance to a different size, you must adjust max_buffer_mem and ringbuffer to fit the new instance's RAM limits. If you keep old settings from a larger instance, VoIPmonitor may crash or fail to start due to insufficient memory.

Buffer Memory Formula

The total memory allocated for buffers is calculated as:

Allocated RAM for Buffers = max_buffer_mem + count(interface) x ringbuffer

Ensure this total fits within your instance's available RAM, leaving room for other processes (GUI, database, operating system).

Reducing Instance Size Example

Resizing from c7i.4xlarge (32GB RAM) to c7i.xlarge (8GB RAM):

Before resize (32GB instance): 

ringbuffer = 500
max_buffer_mem = 6000  # Total: 6000 + 1 x 500 = 6500 MB = 6.35 GB

After resize (8GB instance): 

ringbuffer = 200
max_buffer_mem = 1000  # Total: 1000 + 1 x 200 = 1200 MB = 1.17 GB

Increasing Instance Size

When moving to a larger instance, you can increase buffer limits to handle higher traffic volumes. See Scaling Guide for tuning guidance.

⚠️ Warning: Always restart the VoIPmonitor service after changing buffer settings: systemctl restart voipmonitor

Troubleshooting

Sensor Not Appearing in Cloud

First-Time Setup
Initialize Database

If you see failed read rsa key or loss connection errors, you must first log in to the Cloud GUI to initialize your database:

  1. Log in to Cloud GUI with your portal credentials
  2. This creates the necessary database tables
  3. Restart the sniffer: systemctl restart voipmonitor
  4. Verify sensor appears green in Settings -> Sensors
Verify Configuration
grep -E "cloud_token" /etc/voipmonitor.conf

Required setting: 

cloud_token = your_cloud_token_here

Also verify that MySQL parameters are commented out or removed.

Check Network Connectivity
nc -zv cloud.voipmonitor.org 443

Ensure outbound HTTPS (TCP 443) is allowed through all firewalls (local, corporate, cloud provider).

ARM64 Architecture Issue

On ARM64 (aarch64) systems, a known bug prevents cloud connectivity. Contact VoIPmonitor support for a corrected ARM64 static binary.

Symptoms:

  • Sensor runs locally (visible in logs)
  • Configuration is correct
  • Firewall allows traffic
  • Sensor does not appear in Cloud GUI

Solution: 

systemctl stop voipmonitor
# Download corrected binary from support
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup
cp voipmonitor-arm64-fixed /usr/local/sbin/voipmonitor
systemctl start voipmonitor

See Also



AI Summary for RAG

Summary: VoIPmonitor Cloud Service is a managed hosting model where customer runs on-premise sniffer while VoIPmonitor hosts database and web GUI. Service limits: 2000 concurrent channels, 25 days CDR retention, PCAP stored locally only. Free 30-day trial via portal. Setup: use installation script from portal or manually configure server_destination=cloud.voipmonitor.org, server_destination_port=60023, packetbuffer_sender=yes. Sniffer sends only CDR metadata to cloud; PCAPs stay local and stream on-demand. AWS deployment requires resource limits: ringbuffer, max_buffer_mem, maxpoolsize (critical to prevent disk full), and chmod 644 /dev/root for license. Troubleshooting: first-time users must log into Cloud GUI to initialize database (fixes "failed read rsa key"); ARM64 requires special binary from support.

Keywords: cloud service, hosted GUI, on-premise sniffer, server_destination, packetbuffer_sender, port 60023, CDR metadata, PCAP local storage, on-demand download, AWS, EC2, ringbuffer, max_buffer_mem, maxpoolsize, EBS volume, ARM64, cloud database initialization, failed read rsa key, loss connection, free trial, 2000 channels, 25 days retention

Key Questions:

  • How do I connect my sniffer to VoIPmonitor Cloud?
  • What are the required voipmonitor.conf settings for cloud connectivity?
  • Is my call data (PCAP) stored in the cloud?
  • How do I configure VoIPmonitor on AWS EC2?
  • What is the recommended maxpoolsize for AWS instances?
  • Why is my sensor not appearing in Cloud interface?
  • How do I fix "failed read rsa key" error?
  • Does VoIPmonitor Cloud offer a free trial?
  • What are the cloud service limits (channels, retention)?
  • How do I fix ARM64 cloud connectivity issues?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Cloud&oldid=11089"