ELK甩锅记
事情的起因是想从全链路日志中清洗出需要调整的接口，在 jaeger ui
中查看时，发现几乎每条数据都会出现invalid parent span IDs=xxxx错误，开始怀疑是不是因为迭代就
go context
中的数据丢失了。所以直接找运维同学上线上服务确定了日志文件中是否有相关数据。幸运的是日志文件中确实存在相关数据的。
现在问题转变成了：是 filebeat 采集问题；还是 logstash 消费问题；或者是 es 的服务问题？
对于 filebeat 原来我们是粗略的读过源码并且有尝试修改的，且针对这块流程运行测试过，应该是问题不大，但是对于消息还是 es 写入问题没有大的把握。不过既然确定了方向那就一一验证好了。
用 kibana 的开发工具，读取集群的状态：
用 _cat 或者 _nodes
可读取获取服务信息，输入 GET _cat | _nodes 会主动提示相关内容
如果遇到的用法不知道时也不用担心。直接打开文档阅读即可。
针对本次问题中我因为关心的是写问题，所以直接查看了 thread_pool 相关信息
这样能知道相关的 thread_pool中各各种类型的数据，有点不直观。通过阅读文档，是可以直接查看某种行为的：
通过增加 write 行为的过滤，我们可以确定确实有大量的 rejected 存在。这时基本可以确定 logstash 和 es 的写入这一段过程中存在问题。排查的范围又缩小了一些。但是作为开发的我确定可以把问题先丢回给运维侧处理了。（自己也会偷偷的进一步验证）
ps：上述信息也可以通过 _nodes 相关接口查看
2GET _nodes/prod-ops-es7-node-14/stats/thread_pool
GET _nodes/stats
当前运维给的结论是：我在排查过程中，他们已经在做 logstash 到 vector 的迁移，迁移后问题确实少了很多，但是还是会存在个别丢日志情况。