使用 Java 8 在嵌入式 Tomcat 8.5 上启用 TLS 握手的可观察性（日志记录/指标）

Question

我们正在运行 Spring Boot API，我们在 API 本身中终止 TLS。在广泛搜索后，我们多次观察到 CPU 使用率过高是由于有人创建了许多连接（合法或错误，因为客户端证书被拒绝）或未使用 TLS 恢复。为了防止将来出现这些耗时且代价高昂的搜索，我们希望记录握手失败或成功的时间，以及为什么以及是否使用会话恢复。我们并没有特别依赖于我们当前的堆栈，升级到不同的服务器，如 Undertow 或 WebFlux，和/或新版本的 Java 也很好。同样，我们可以使用 APR、NIO 或本机绑定来实现这些目标。以下其他问题表明，目前没有开箱即用的解决方案。他们建议扩展JSSEImplementation或创建自定义 SSL Socket Factory，或将 NIO 适配器的级别转为 Debug。这些解决方案感觉很脆弱，我想知道是否有基于事件或回调的更可扩展的机制。或者，我们可以从 Java 启用握手日志，但这些日志很冗长，这样做会导致显着的性能下降。更新 1： 我尝试走使用自定义 SSLServerSocketFactory 的路线。在sun.security.ssl.SSLServerSocketFactoryImpl回报sun.security.ssl.SSLServerSocketImpl上绑定它返回一个很好SSLSocket的接受。我可以始终包装该接受方法以添加完成处理程序。唯一的缺点是：SSLServerSocketFactoryImpl是最终的，所以我不能只是包装它。这意味着我需要复制大量代码，但它仍然只能为我提供成功握手的指标。复制代码将是一种维护负担，因为这是 JRE 特定的代码。

Answer 1

这是一个单独的服务器还是负载均衡器后面的一组服务器？

您可以考虑“重新部署”服务器，这样您就有一个具有相同配置但启用了 JAVA OPT 调试 ssl:handshake 的副本。

现在在负载平衡器上，您将一部分流量定向到调试服务器以对您感兴趣的活动进行采样。

或者，您可以在打开调试的不同端口上的同一服务器上部署另一个 tomcat 实例。（这不是想法，因为它会增加服务器上的负载，您提到在请求增加时可能已经遇到麻烦。）

所以也许你没有负载均衡器，但你可能有防火墙，看看你的防火墙是否有状态并且可以为你“分割流量”。

如果当前服务器是 linux 服务器，您可以在我上面提到的“双本地安装”示例中使用 iptables 来执行此操作。像这样：https : //www.webair.com/community/simple-stateful-load-balancer-with-iptables-and-nat/

没有一个复杂的解决方案。

如果您没有负载均衡器，您可能需要考虑它，因为它为您提供了很多灵活性来处理各种情况，而不仅仅是这种情况。