Hi Uri,
Yes, we know that all diag logs could configured to pipe to syslog. But
different diag log level have different purpose. If mix every log level into
syslog, it would be hard to track specific issues.
Attached with a graph show how ATS diag log works with current default
configuration.
Thanks and Regards,Kang
On Thursday, June 18, 2015 8:15 AM, Uri Shachar <ushac...@hotmail.com>
wrote:
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
