Logging: Difference between revisions
No edit summary |
No edit summary |
||
Line 20: | Line 20: | ||
L=LiveSniffer_queue | L=LiveSniffer_queue | ||
Cl=Cleanspool queue | Cl=Cleanspool queue | ||
==heap[A|B|C]== | |||
===A=== | |||
number of % of used heap memory.If 100 voipmonitor is not able to process packets in realtime due to CPU or I/O. | |||
===B=== | |||
number of % used memory in packetbuffer. | |||
===C=== | |||
% used for async write buffers (if 100% I/O is blocking and heap will grow and than ring buffer will get full and then packet loss will occur) | |||
==[Mb/s]== | |||
total network throughput | |||
==tarQ== | ==tarQ== | ||
number of files in a queue | |||
==tarB== | ==tarB== | ||
MBs in tar buffer | |||
==tarCPU== | ==tarCPU== | ||
threads used for taring - its consumption | |||
==t2CPU== | ==t2CPU== | ||
Line 38: | Line 49: | ||
g:6.4/ - process_packets - registers | g:6.4/ - process_packets - registers | ||
r:7.3/ - process_packets - RTP | r:7.3/ - process_packets - RTP | ||
rm:24.6/ - RTP - packets shift, prepare for processing | |||
rm:24.6/ - packets shift, prepare for processing | |||
rh:16.7/ - RTP - search hash | rh:16.7/ - RTP - search hash | ||
rd:19.3/ - RTP - move to read queue | rd:19.3/ - RTP - move to read queue | ||
Line 57: | Line 67: | ||
if 'e' < N remove 'e' | if 'e' < N remove 'e' | ||
if 's' < N remove 's' | if 's' < N remove 's' | ||
==RSS/VSZ[323|752]MB== | |||
===RSS=== | |||
stands for the resident size, which is an accurate representation of how much actual physical memory sniffer is consuming. | |||
===VSZ=== | |||
stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card’s RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment. |
Revision as of 03:10, 15 February 2018
Messages from GNU GPL sniffer sensor service
Voipmonitor by default uses 'daemon' facility of a syslog to store status messages.
Default location
it is stored to /var/log/syslog(on debian/ubuntu)or to /var/log/messages(on centos/rh)
Messages file Change
You can find useful to store status info from voipmonitor to different file: For rsyslog use this in /etc/rsyslog.conf
if $programname == 'voipmonitor' and $syslogseverity <= '7' then /var/log/voipmon.log & ~
Status line details
SQLq
C=CDR_queue M=Message_queue R=Register_queue L=LiveSniffer_queue Cl=Cleanspool queue
heap[A|B|C]
A
number of % of used heap memory.If 100 voipmonitor is not able to process packets in realtime due to CPU or I/O.
B
number of % used memory in packetbuffer.
C
% used for async write buffers (if 100% I/O is blocking and heap will grow and than ring buffer will get full and then packet loss will occur)
[Mb/s]
total network throughput
tarQ
number of files in a queue
tarB
MBs in tar buffer
tarCPU
threads used for taring - its consumption
t2CPU
pb:10.5/ - packetbuffer - out of the buffer d:39.2/ - structs create for processing in t2 s:24.6/ - SIP - parse e:17.3/ - SIP - calls/messages search, struct creation c:6.8/ - process_packets - calls/messages g:6.4/ - process_packets - registers r:7.3/ - process_packets - RTP rm:24.6/ - RTP - packets shift, prepare for processing rh:16.7/ - RTP - search hash rd:19.3/ - RTP - move to read queue
Adding new thread is automatic
'd' is running after pb, if 'd' > 50%, new thread 's' (reasembles, sip parse) if 's' > 50%, new thread 'e' (callid search + structs create for calls), if 'e' > 50%, new thread 'c' (calls) if 'c' > 50%, new thread 'g' (registers) if 'g' > 50%, new thread 'r' (rtp)
Threads removing
if 'r' < N remove 'r' if 'g' < N remove 'g' if 'c' < N remove 'c' if 'e' < N remove 'e' if 's' < N remove 's'
RSS/VSZ[323|752]MB
RSS
stands for the resident size, which is an accurate representation of how much actual physical memory sniffer is consuming.
VSZ
stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card’s RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment.