Hi Daniel,
Note that we already support your first solution via syslog (for
traffic.out and
diags.log) -- you can set a different backend for log types/priorities
(check out proxy.config.diags.output.<priority>
Regarding the second option -- If the logging volume is small you
can probable get by with logrotate (with the copytruncate option), if
it's high and you can't afford to lose a couple of lines then you'll
need a significant internal buffer...
Cheers,
Uri
On Thu, 18 Jun 2015 00:28:16 +0000 Daniel Xu <danie...@yahoo-inc.com.INVALID>
wrote:
> Background
> Yahoo JIRA issue Apache JIRA issue (TS-306)Currently, there is no log
> rotation implemented for traffic.out, diags.log, and manager.log. Each of
> those files is logged into using a different and unique way. This is in
> contrast to the logging subsystem used to record the proxy accesses and
> errors, which implements rotation. For example, the following files can be
> written into in these ways. Note: these are not the only ways the files are
> written into.
> traffic.out:Logs that are sent to stdout and stderr are forwarded to
> traffic.out
> diags.log:Everything logged by using the Diags macros (Note(..), Error(..),
> …) are put into diags.log
> manager.log:traffic_manager logs its messages with fprintf’s and
> mgmt_{log,elog,fatal,..} functions (which are deprecated) from
> mgmt/utils/MgmtUtils.h. Some of those messages find their way into manager.log
>
> Problem
> Since those files aren’t being rotated, they can get too large for various
> reasons (core, naughty plugins, proxy, etc). Furthermore, the lack of a
> unified logging system makes changes to the logging infrastructure more work
> than one would expect.
>
> Solutions
> To solve these problems, we have a couple options:
>
> - Pipe logs from traffic.out, diags.log, and manager.log into a 3rd party
> logging utility [1]
>
> - Pros
>
> - Virtually no changes to existing code base
> - Easy
> - Apache httpd & daemon tools already do this
>
> - Cons
>
> - Not an elegant solution
>
> - Use the trafficserver script to spawn a daemon that periodically “stops the
> world” (ie the logs wouldn’t flush) for all logging calls, and rotates the
> files [1]
>
> - Pros
>
> - No difficult changes need to be made the current infrastructure, we would
> only need to figure out how to 1) “stop the world” and 2) reload file
> descriptors
>
> - Cons
>
> - It’s hard to say how big the interim buffer (for holding all the logs while
> the world stops) should be
> - Not the most elegant solution
>
> - Reuse the proxy logging infrastructure, and make a LogObject managed by the
> proxy’s global LogObjectManager for each of the log files we want to
> implement rotation for.
>
> - Pros
>
> - No repeated code
> - We would have a unified logging infrastructure
>
> - Cons
>
> - Significant changes to code base
> - Would be difficult to log events before the proxy logging infrastructure
> starts up [2]
>
> Comments
> James Peach has previously mentioned that log rotation for diags.log should
> be implemented the same as all other rotated log files here
>
>
> ----------
> [1] Kang Li; earlier proposal
> https://docs.google.com/document/d/1c9E0i8N3krL3msiHOLpgR99UzNUAt5N6FP1L3W3ghGs
> [2] http://articles.qos.ch/internalLogging.html
