Hi Jan, I tend to disagree here; parsing multi-line logfiles using Perl Scripts is a very, very ugly task, especially if it has to be done over and over again by different people for different purposes and where number of lines and formats have some change over various versions. Of course, sample scripts could be provided, but I would tend to think that an alternative log "mode" would be a very useful enhancement to the server. Now, given compared to the Good Old Days™ neither number of files per directory or number of open file handles per process or per system really pose a resource or performance challenge anymore, a setup where one would specify a CallTraceDirectory path, and then, in this directory, one log file per call would be written, with a duplicate of all log messages related to the call, Robert's task would become substantially easier. Files/Calls could still be organized by time (using the modification time stamp on the per-call logfile as the primary sort criteria) and call trace files could easily be aged out and deleted after a week or so using a simple "find -mtime" script. Thoughts appreciated, Florian. On 31.08.2011, at 17:17, Jan Willamowius 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. > > Regards, > Jan > > Robert Kulagowski wrote: >> I have over 90 systems connected to a GnuGK which runs as a proxy to >> the internet. I often get calls which fail, but because the >> gk_trace.log file tracks everything, it becomes impossible to follow >> the "thread" of a call setup because there doesn't seem to be a way to >> filter out just one particular call; so troubleshooting means trying >> to determine if a particular message in the log file is for some other >> call, a valid RCF, etc. >> >> How do people with larger configurations perform the troubleshooting >> and log analysis? >> >> Jan, is there some way to have GnuGK create a separate log file for >> each registered endpoint, and then just have gk_trace.log hold >> "everything else" and housekeeping? Or if the log file tracked which >> endpoint_id a particular log entry related to then it would be easy to >> grep. > > -- > Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________________ > > 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/ ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________________ 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/
