最近生产环境发生了一个问题，背景就是在服务处理一些任务过程中，偶尔有些任务是处理失败的，触发了业务监控告警。针对这个问题，我当时初步追了一下，发现内部的一个微服务存在调用异常，表现是connection reset异常。之后我就把这个小问题抛给了对应的负责的小伙伴跟踪。
之后，我就去忙别的，这个小伙伴是新入职没多久，工作2年多，经验尚浅，安排给他跟踪，一来是他负责的项目，二来，也可以让他追一些问题了解公司的业务，最后还可以通过追问题，来锻炼他排查问题的能力，我想是这么安排，但是实际操作起来，有点出乎我的意料。
恰好哪天，公司的racher监控平台发生异常使用不了，中午饭后，我问了一下小伙伴，跟出什么问题了没，他的回答让我有点吃惊
`说看不到服务对应的是哪个节点的日志，不知道怎么看日志，其次是到服务都运行很正常，最后微服务太多了，不知怎么查`
针对小伙伴疑问，有这么个思路，需要小伙伴自己思考
1.racher查看不到对应的是哪个服务节点，可以通过别的监控平台上看，比如kibana,又或者可以到跳板机上连接进入服务器通过 ll -rt 命令查看最新的服务日志就知道是什么节点了；
2.查看日志方面，如果racher上看不了，也可以按照上面的方式，进入服务中，直接通过 less cat more等等命令查看，每个节点针对发生的数据的时间都去狂扫看看，也是一种学习的过程
3.微服务是比较多，但是，我已经初步定为是那个服务的问题了，就针对那个服务的几个节点都排查一下，如果里面还有涉及别的微服务，也是可以钻到别的微服务上进行跟踪，实在不行，把对应的微服务的代码从gitlab上拉下来，从代码上跟进也是一种思路的，当然这样就会比较慢
4.在都不知道怎么入手的情况下，可以问问身边的小伙伴，怎么去操作，身边总有人知道了解，整个流程下来，是可以学到很多东西，特别是刚进入一个新公司的时候。
从追问题上来看，小伙伴还需要进一步的努力。
最后问题的解决过程是这样的，从发生的时间入手，在Kibana上，过滤出请求异常的服务节点，在5个服务节点中最后发现有一个服务节点请求一直处于异常，没有办法正常应答，而那个服务节点所在的Kubernetes.node.name 和之前的几个服务存在connot create native thread 的问题处于同一个，而我们的微服中请求异常时会重试3次，3次都是同时打在这个有问题的节点上才会表现处理，所以背景里面表现的是偶尔一下任务是处理失败的。当然了，有问题的服务健康检查是通过的，所以k8s没有把它剔除掉。
另外发现一个问题，在排查问题过程中，发现小伙伴负责的服务内，狂打一些健康检查相关的日志，对排查定位问题造成一定的干扰，这块是需要优化的点，已让小伙伴进行优化，看看他咯。
