背景

今天早上，我们平台应用报错“java.lang.OutOfMemoryError: unable to create new native thread”异常。

处理

一开始，我们看到有2个核心应用报异常，认为是这2个应用问题，急忙重启这2个应用所有节点；
接下来又发现有其他非核心业务也报这个异常，同时重启过的应用还是时不时报这个异常。

判断

基于上面这些现象，我基本确定不是单个应用的问题，可能是K8S集群某台机器有问题。

为什么这么判断？

“java.lang.OutOfMemoryError: unable to create new native thread”看起是个OOM，但和堆内存OOM有区别。
Java应用，我们一般设置堆内存大小和线程的栈大小，对创建线程的数量通常不控制。应用能创建多少线程，和系统的内存数量、系统支持的最大线程数有关。
这么多应用一起报这个异常，核心应用和非核心应用都有，而且这些应用并不在同一个调用链路上，所以判断和这些应用无关，应该与应用所在机器有关。

细化排查

接下来，我发现应用日志有些问题：输出这个异常日志的应用，并不是它报这个异常，而是它发起http请求其他应用，其他应用返回这个异常，真正有异常的是这些应用。
通过在查询条件上增加响应码500来过滤，发现一个诡异问题：过滤完一条日志都没有了。

没有日志是什么问题？

通过查询日志服务，发现增加响应码500过滤后，今天虽然没有日志，但昨天有日志，同时还发现昨天的日志都是同一个K8S的worker节点上应用输出。
我们接着排查这个worker节点的监控，发现一些告警，如下

这个worker节点在昨天22点20分报Conntrack表满异常，这个时候节点上的应用也报“java.lang.OutOfMemoryError: unable to create new native thread”异常。
这个worker节点上应用今天没有日志，是因为logtail组件重启异常，导致日志无法正常输出到日志服务。

结论

确认是K8S集群的这个worker节点异常，导致这个节点上的应用报异常。
但到底是我们应用引起的，还是这个节点的其他组件引起，目前还在与阿里沟通，查看这台节点的日志，以定位到问题根因。