Robert Kulagowski wrote: > On Wed, Aug 31, 2011 at 11:18 AM, Robert Kulagowski <rkulagow@xxxxxxxxx> wrote: > > On Wed, Aug 31, 2011 at 10:17 AM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote: > >> Hi Robert, > >> > >> all messages for a call have the same callID and you can grep for > >> that. Its a bit complicated by the fact that the messages are printed > >> out over multiple lines, so its a job for a small Perl script or > >> similar. If you want to take it a step further you can do 2 passes, one > >> to find all calls for a specific endpoint ID and then collect all > >> messages for those calls in the 2nd pass. > >> > >> Doing that server side would be a major hassle and imagine how > >> inconvenient all those trace files would be if you have hundreds of > >> calls at the same time. > > Jan, have you given any thought to adding a "per-host" option for > logging in a future version of GnuGk? I know that it may not be > useful with 100's of hosts/simultaneous calls, but in my environment, > with 100 endpoints and 11 to 12 simultaneous calls that often last > longer than 60 minutes, it would be immensely useful during > troubleshooting to be able to maintain a consistent mental "thread" as > debugging is occurring. > > Even just being able to specify at the status port that a certain > endpoint needs to be logged to a special file would be great. So far I haven't though about it much. In my daily work I get by fine with the current trace files and my set of Perls scripts to filter them. But I do agree that there are situations where an ordinary user might find per endpoint tracing useful. I quickly counted that we have around 1400 tracing statements inside GnuGk that we would each have to touch and decide if they are call related or not. I think the the non-call related trace messages (like a database failing, status port connects etc.) would probably belong into all open traces, because they give the background why things might fail. Then there are some directly call related messages, like protocol messages that go over the wire, those are mostly easy to associate with an endpoint. but then we have a lot of call related trace messages where we currently don't pass in the call into the processing function. In all those cases we would have to rewrite the tracing to either pass call information or trace them to all open traces. The volume of work required aside, lets discuss if this would cover common tracing needs. Regards, Jan -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
