[
https://issues.apache.org/jira/browse/TS-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3133:
----------------------------------
Description:
In our production systems, we have proxy.config.log.log_buffer_size set to the
default value of 9216. However, we do see some very large URLs resulting in
larger log entries (about 26k bytes long). This basically results in the
warnings like the below from ATS (going into diags.log). This is good, but, the
problem is that, these WARNING messages alone fill up/flood the diags.log
pretty fast (which itself is not rotated right now - refer TS-306). The correct
solution to this is to increase the log buffers, which we are implementing,
but, it might be nice to not flood the diags.log with the below WARNINGs as
that might result in losing/missing out on other critical/important WARNINGs.
We are thinking of implementing some sort of throttling on these kind of
WARNINGs (for e.g. 1 in every 1000 entries along with a count of how many times
the log was not displayed).
Please provide comments/suggestions.
{code}
[Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
entry for squid.blog because its size (11000) exceeds the maximum payload space
in a log buffer
[Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
the current log entry because its size exceeds the maximum line (entry) size
for an ascii log buffer
{code}
was:
In our production systems, we have proxy.config.log.log_buffer_size set to the
default value of 9216. However, we do see some very large URLs resulting in
larger log entries (about 26k bytes long). This basically results in the
warnings like the below from ATS (going into diags.log). This is good, but, the
problem is that, these WARNING messages alone fill up/flood the diags.log
pretty fast (which itself is not rotated right now). The correct solution to
this is to increase the log buffers, which we are implementing, but, it might
be nice to not flood the diags.log with the below WARNINGs as that might result
in losing/missing out on other critical/important WARNINGs. We are thinking of
implementing some sort of throttling on these kind of WARNINGs (for e.g. 1 in
every 1000 entries along with a count of how many times the log was not
displayed).
Please provide comments/suggestions.
{code}
[Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
entry for squid.blog because its size (11000) exceeds the maximum payload space
in a log buffer
[Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
the current log entry because its size exceeds the maximum line (entry) size
for an ascii log buffer
{code}
> Logging NOTE filling up diags.log
> ---------------------------------
>
> Key: TS-3133
> URL: https://issues.apache.org/jira/browse/TS-3133
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
> Affects Versions: 5.0.1
> Reporter: Sudheer Vinukonda
> Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
>
> In our production systems, we have proxy.config.log.log_buffer_size set to
> the default value of 9216. However, we do see some very large URLs resulting
> in larger log entries (about 26k bytes long). This basically results in the
> warnings like the below from ATS (going into diags.log). This is good, but,
> the problem is that, these WARNING messages alone fill up/flood the diags.log
> pretty fast (which itself is not rotated right now - refer TS-306). The
> correct solution to this is to increase the log buffers, which we are
> implementing, but, it might be nice to not flood the diags.log with the below
> WARNINGs as that might result in losing/missing out on other
> critical/important WARNINGs. We are thinking of implementing some sort of
> throttling on these kind of WARNINGs (for e.g. 1 in every 1000 entries along
> with a count of how many times the log was not displayed).
> Please provide comments/suggestions.
> {code}
> [Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
> entry for squid.blog because its size (11000) exceeds the maximum payload
> space
> in a log buffer
> [Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
> the current log entry because its size exceeds the maximum line (entry) size
> for an ascii log buffer
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
