本文主要是介绍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
这篇关于ATS线上报告个别日志过大无法写入问题的解决方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
