log 與監控過載 Logging / monitoring overhead

原因 ID in-monitoring · 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）

發生故障時 log 會暴增，以同步方式送出 log 的伺服器會因為 log 變得更慢。

為什麼 發生錯誤，log 與指標的傳送量暴增 → 於是 log 收集器消化不及，同步傳送的伺服器只能等待 → 畫面上 故障時的卡頓、定格因為 log 變得更嚴重

症狀: 卡頓, 定格
因素: 停滯
誰會遇到: 整個伺服器
何時: 人潮湧入時, 偶爾隨機發生
負責單位: 主要負責 遊戲開發團隊（伺服器開發） · 協同基礎設施團隊（伺服器基礎設施）
遊戲開發團隊要做的事: 非同步傳送、取樣、緩衝區滿了就丟棄、相同的錯誤 log 合併後再送。
基礎設施團隊要做的事: 以故障時的暴增量為基準準備 log 收集器容量，收集器積壓時發出警示。
圖表上: 偶爾隨機飆高 · log 傳送量、log 收集器佇列
查看位置: 把伺服器每秒的 log 行數與位元組數、log 收集 agent 的佇列與丟棄數，和 tick 時間一起看。有執行緒停住時，用 bcc offcputime -p 看是否在等寫入或傳送 log
符合的跡象: tick 飆高的時間點 log 量往上衝到平常的數十倍，遊戲執行緒的等待時間集中在寫入、傳送 log 的呼叫堆疊
不符合的跡象: log 量與平常相同，或遊戲執行緒沒有在 log 那邊等待時，log 暴增只是故障的結果，要另外找最先出錯的原因
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

Logging in C# Microsoft
.NET 的 log 方法是同步的，儲存位置很慢時建議不要直接寫入，先寫到快速的儲存位置再搬移
Asynchronous loggers Apache Software Foundation
非同步 log 用佇列吸收短暫的暴增，但輸出持續很慢時佇列會滿，速度降到最慢的輸出速度，或依政策丟棄 log（Discard）
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
把執行緒停住、離開 CPU 的時間（off-CPU）依呼叫堆疊加總，-p 指定處理程序