问题背景
容器部署的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