訪問日志是分析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线上报告个别日志过大无法写入问题的解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。