問題背景
容器部署的skywalking，版本是6.6，trace-buffer文件夾佔用磁盤持續增加，最後撐爆上限20G。日誌
排查過程
- 方向1：消費慢致使trace數據在buffer裏堆積
很容猜測到這個方向，可是從es的狀態和日誌來看，沒有跡象代表寫入有壓力。排除rpc
- 方向2：數據存在不均衡，不一樣容器實例相差較大，懷疑是負載不均衡
skywalking使用grpc傳輸數據，長鏈接自己也不保證數據的均衡性，只保證鏈接數量的均衡，不會是形成問題的主要緣由部署
- 方向3：buffer清理機制失效
從社區裏查到資料，skywalking有定時器Timer按期清理trace-buffer，有時候確實能看到磁盤有少許的降低，說明機制存在，只是因爲某種緣由阻止其有效處理buffer。社區
- 方向4：endpoint過多
接入了24個項目，可是endpoint卻高達180w+，從skywalking做者那裏瞭解到endpoint過多會致使buffer較大。endpoint過可能是由於C端站點被爬取，不少404的uri也被註冊錄入。可是既然錄入成功，說明雖然endpoint多可是仍然能正常處理掉。排除。class
- 方向5：某個服務發送的數據有問題，沒法消費，致使堆積
直接打開trace-buffer裏的sw文件，發現數據都來自同一個服務，通過和負責人瞭解，這個服務上有服務也用了skywalking，不過是其餘部門的skywalking服務，和本部門部署的skywalking服務沒有隔離開，致使這個服務發送過來的數據沒法被skywalking服務消費處理堆積了。容器
處理
通知服務負責人暫時停掉數據發送，恢復正常。grpc