Common body of support emails

Revision as of 15:13, 28 July 2020 by Petr.halounek (talk | contribs) (→‎1000 channels)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

HW sizing

1000 channels

CPU E5-2620-v4 will be sufficient:
expecting 4(7) cores used for sniffer, 4(9) for db+web server. (with HT enabled)

expecting 4GB for sniffer, 4GB for webserver, rest for db+OS

Storage for full packet records (HDD Disk with 7k+rot/min): (1MB = 1minute for 2 streams in g711) If you have 2 legs then for 14 days of full recording:
Real usage can be different - but this is how we can estimate very aproximately:

1MB x (60min x 24hour x 14days) x 2 (legs count) x 1000(count of max sim calls) x 1/3 (33% Ratio - expectation of daily minutes in compare to peak time) = 13TB. 

Storage for DB SSD: This mainly depends in average CPS (calls per second) which differs in each installation.
You can count aproximately 2KB/CDR(call) with compression enabled.

For example:
If we count 200 000 calls per day (connected also refused), then aprox usage per day is 500MB - keeping CDRs for 1 month results in aprox 15GB for one year aprox 200GB. (not including registrations or 
options/subscribe/notify) requests.

Install & configure client/server in packetmirror mode


install just the sniffer service there on pbx where you want to collect information:

then edit /etc/voipmonitor.conf and take care on common setting options like:
spooldir - where health information (rrds) will be stored
max_buffer_mem - maximum allowed RAM allocation for packet buffers (before send to central when network is slow it can queue the pacckets into RAM)
interface - which INTERFACE(s) to sniff on.
sipport - which TCP packets will be also sent for analyze (all UDP packets are re-sent)
ringbuffer - allocated ram for ringbuffer (packets queue between driver and kernel)

Then define also client/server specific options for client side:
# this example configuration will process packets and sends only CDR to the server.
# id_Sensor needs to be < 65536
id_sensor = unique_number 
server_destination = serverip
#needs to be defined same as server_bind_port option on the central server 
server_destination_port = 60024
server_password = somepassword
packetbuffer_sender = yes

Then on dedicated voipmonitor server install whole voipmonitor system (sniffer+GUI+DB) using installation instructions:
Use any LTS distrubution we tested:

then set common options like you did on client + maxpoolsize option that tells the maximum size of a packet captures in a spooldir, and plus cleandatabase option that will tell for how long will be CDRs 
kept in memory

When used for production (collecting lot of data) make sure to correctly set database for best performance (also keep in mind that maxpoolsize option not includes size of db /var/lib/mysql that will grow 
with count of CDRs stored inside.

Also set the server side options in a server:

after above set restart voipmonitor service on the server (check /var/log/syslog or /var/log/messages if it periodicaly print its state, or some errors appeared at startup)
then start service on client side and check syslog / messages there. 

If client can connect to master server you will see in browser after login to GUI in settings->sensors that the client with its id_sensor were autoadded into list of sensors.