CSV CDRs allow you to set the format. So you could setup a template that emits JSON, but only containing the fields you need.
Before doing this, you should really have done performance profiling to make sure this is actually a bottleneck. Unless you’re already CPU or IO bound, it’s probably
not worth the hassle. Yes, it does take a noticeable amount of resources to handle the big CDR files, but a: as Ken says it’s handy for debugging and b: hopefully you’re making enough profit margin that it doesn’t matter – just add another box.
As far as pushing CDRs to a remote server, you probably don’t want to do this inside FS. This is because if the send fails (networking, remote server reboot,
etc.) you may still want the CDR. The default behaviour of writing to disk if the send fails means you need a backup codepath that reads off disk and processes CDRs. This codepath won’t be as well tested or used, making it more likely to fail when you least
want it to (i.e. when normal CDR sending is failing). Might as well write to disk in every case, then use a message queue to move the CDRs off. If you mainly want to reduce network IO, then pre-process the CDRs before enqueueing them.
-Michael
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org]
On Behalf Of Jurijs Ivolga
Sent: Monday, 18 January, 2016 8:49
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] mod_format_cdr and mod_json_cdr are writing too much data
Hi,
I appreciate a lot your help, but it will be much more helpful if you can just point where too look or maybe you can send more detailed instructions?
I need to decrease json CDRs, so I'm little bit lost, why you pointing to csv cdr.
I need to use either mod_format_cdr or mod_json_cdr modules, cause I plan to push later CDRs to remote server.
Is it possible somehow decrease logs generated by mod_format_cdr or mod_json_cdr modules?
If yes, please let me know how.
Thank you for your help!
With kind regards,
Jurijs
2016-01-18 16:33 GMT+02:00 Sergey Safarov <s.safarov@gmail.com>: