Common body of support emails: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
== 1000 channels == | == 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 4(7) cores used for sniffer, 4(9) for db+web server. (with HT enabled) | ||
RAM 32GB | |||
expecting 4GB for sniffer, 4GB for webserver, rest for db+OS | 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: | 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. | 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. | You can count aproximately 2KB/CDR(call) with compression enabled. | ||
For example: | 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. | 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 & configure client/server in packetmirror mode= |
Latest revision as of 15:13, 28 July 2020
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) RAM 32GB 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
Hello, install just the sniffer service there on pbx where you want to collect information: https://www.voipmonitor.org/doc/Sniffer_installation#Step_by_step_for_64bit_linux_procedure 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 ``` https://www.voipmonitor.org/doc/Sniffing_modes#client.28remote.29_sensor_configuration Then on dedicated voipmonitor server install whole voipmonitor system (sniffer+GUI+DB) using installation instructions: Use any LTS distrubution we tested: http://www.voipmonitor.org/doc/Content 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 https://www.voipmonitor.org/doc/Data_Cleaning 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. https://www.voipmonitor.org/doc/Scaling#MySQL_performance Also set the server side options in a server: https://www.voipmonitor.org/doc/Sniffing_modes#server.28central.29_sensor_configuration 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.