skywalking问题排查记录
排查过程
- 方向1：消费慢导致trace数据在buffer里堆积
很容猜想到这个方向，但是从es的状态和日志来看，没有迹象表明写入有压力。排除
- 方向2：数据存在不均衡，不同容器实例相差较大，怀疑是负载不均衡
skywalking使用grpc传输数据，长连接本身也不保证数据的均衡性，只保证连接数量的均衡，不会是造成问题的主要原因
- 方向3：buffer清理机制失效
从社区里查到资料，skywalking有定时器Timer定期清理trace-buffer，有时候确实能看到磁盘有少量的下降，说明机制存在，只是由于某种原因阻止其有效处理buffer。
- 方向4：endpoint过多
接入了24个项目，但是endpoint却高达180w+，从skywalking作者那里了解到endpoint过多会导致buffer较大。endpoint过多是因为C端站点被爬取，很多404的uri也被注册录入。但是既然录入成功，说明虽然endpoint多但是仍然能正常处理掉。排除。
- 方向5：某个服务发送的数据有问题，无法消费，导致堆积
直接打开trace-buffer里的sw文件，发现数据都来自同一个服务，经过和负责人了解，这个服务上有服务也用了skywalking，不过是其他部门的skywalking服务，和本部门部署的skywalking服务没有隔离开，导致这个服务发送过来的数据无法被skywalking服务消费处理堆积了。
处理
通知服务负责人暂时停掉数据发送，恢复正常。
以上是 skywalking问题排查记录 的全部内容， 来源链接： utcz.com/z/518981.html
