ATS线上报告个别日志过大无法写入问题的解决方法

访问日志是分析CDN线上问题的重要参考依据，但是我们在实际运维中发现很多部署点日志记录出现一些小问题，会造成相应的日志条目丢失。我们发现线上一些服务器上时常会报告如下问题：

diags.log中经常报如下错误：

[Mar 31 02:39:34.185] Server {0x2b1d85563700} NOTE: <LogObject.cc:616 (log)> Skipping the current log entry for access.log because its size (9136) exceeds the maximum payload space
in a log buffer
分析问题

这里已经指出了报错日志的代码位置在LogObject.cc:616，导致出错的函数位置的源码是





显然我们需要研究 _checkout_write()函数的实现，并关注返回为NULL的值，里面实际上是调用
result_code = buffer->checkout_write(write_offset, bytes_needed);
来控制多线程同步写日志，





上述日志信息所走的流程是





它是result_code的返回码LogBuffer::LB_BUFFER_TOO_SMALL，所以最终我们还得查看LogBuffer::checkout_write()返回该状态码的地方,注意如下函数的返回值
LB_ResultCode ret_val = LB_BUSY;
返回的该代码是





上面的比较，m_size的值很关键，我们需要关注m_size的默认赋值是多少？这是写日志的一个初始缓存的长度，字符串型的，在LogBuffer.cc中





它是调用它的构造函数生成的
LogBuffer(LogObject * owner, size_t size, size_t buf_align = LB_DEFAULT_ALIGN, size_t write_align = INK_MIN_ALIGN);





可以看出分配指定长度的缓存给m_unaligned_buffer，并将它对齐为m_buffer，动态释放内存的地方在析构函数中





建议gdb追踪来找到调用点，发现还是在LogObject.cc中有几处地方，都有如下代码
LogBuffer *b = NEW (new LogBuffer (this, Log::config->log_buffer_size));
现在继续追踪Log的配置项，在sourceInsight中搜索log_buffer_size得到



结果很清楚了，配置项配大点就可以了。
解决方法
在records.config中添加一项proxy.config.log.log_buffer_size，配置大些就可以了。直接热修改如下：
traffic_line -r proxy.config.log.log_buffer_size
traffic_line -s proxy.config.log.log_buffer_size -v 40960
traffic_line -x
如果还是报类似上面的错误，可以继续酌情修改这个值，总之，要根据业务的实际情况修改

更进一步修正

修改上述配置后，发现线上日志出现如下报错



经过查看，发现与另一个配置proxy.config.log.max_line_size有关，它的默认值也是9216

解决方法：

在records.config中添加一条配置(可根据实际情况酌情修改)

CONFIG proxy.config.log.max_line_size INT 15000

下面是修改前后的判决图



下面是源码追踪流程，不愿深究的可以略去。

调用流程追踪

报错地方的源码是



在source insight中追踪源码中的max_line_size可以看到基本调用流程。





剩下的是配置项的读取





总结：最终一个通用的设置，在records.config中加入：

CONFIG proxy.config.log.max_line_size INT 35000
CONFIG proxy.config.log.log_buffer_size INT 262144