容器中云应用的左移监控方法

左移是一种软件开发和运维的方法，强调在软件开发生命周期早期进行测试、监控和自动化。左移方法的目标是通过早期发现问题并迅速解决，预防问题的发生。

当你早期识别出一个可扩展性问题或错误时，解决它更快且更具成本效益。将低效代码迁移到云容器可能会很昂贵，因为它可能触发自动扩展并增加你的月度账单。此外，在你能够识别、隔离并修复问题之前，你将处于紧急状态。

问题陈述

I would like to demonstrate to you a case where we managed to avert a potential issue with an application that could have caused a major issue in a production environment. 

I was reviewing the performance report of the UAT infrastructure following the recent application change. It was a Spring Boot microservice with MariaDB as the backend, running behind Apache reverse proxy and AWS application load balancer. The new feature was successfully integrated, and all UAT test cases are passed. However, I noticed the performance charts in the MariaDB performance dashboard deviated from pre-deployment patterns.

这是事件的时间线。

8月6日14:13，应用程序使用包含嵌入式Tomcat的新Spring Boot jar文件重新启动。

14:52，MariaDB的查询处理速率从0.1增加到88每秒查询，随后增加到301每秒查询。

同时，系统CPU使用率从1%上升到6%。

最后，JVM在G1年轻代垃圾收集上花费的时间从0%增加到0.1%，并保持在那个水平。

该应用在用户验收测试（UAT）阶段出现异常，每秒发出300次查询，远超设计预期。新功能的引入导致数据库连接数增加，从而引发了查询量的急剧上升。然而，监控仪表板显示，在新版本部署前，相关指标均显示正常。

解决方案

这是一款采用Spring Boot框架、通过JPA查询MariaDB的应用。设计初衷是在两个容器上运行以保持最低负载，但具备扩展至十个容器的能力。

若单个容器能生成每秒300次查询，那么当十个容器全部运行时，是否能处理每秒3000次查询？数据库是否拥有足够的连接数以满足应用其他部分的需求？

我们别无选择，只能回归开发者层面，深入Git仓库检查变更。

新变更涉及从一张表中提取几条记录进行处理。我们在服务类中观察到了以下代码片段：

List<X> findAll = this.xRepository.findAll();

不，在Spring的CrudRepository中不使用分页的findAll()方法并不高效。分页通过限制获取的数据量来减少从数据库检索数据所需的时间，这是我们主要关系型数据库教育所教授的。此外，分页有助于保持较低的内存使用，防止应用程序因数据过载而崩溃，并减少Java虚拟机的垃圾收集工作量，这在上述问题陈述中已提及。

此测试仅在一个容器中使用了2,000条记录。如果这段代码迁移到生产环境，那里大约有200,000条记录分布在最多10个容器中，那可能会给团队带来巨大的压力和担忧。

应用程序通过在方法中添加WHERE子句进行了重构。

List<X> findAll = this.xRepository.findAllByY(Y);

功能恢复正常。每秒查询次数从300降至30，垃圾收集的努力恢复到原始水平。同时，系统的CPU使用率也有所下降。

学习总结

从事站点可靠性工程（SRE）的任何人都会认识到这一发现的重大意义。我们能够据此采取行动，而无需提升至一级严重性警报。如果这个有缺陷的软件包被部署到生产环境中，它可能会触发客户的自动扩展阈值，导致即使在没有额外用户负载的情况下，新的容器也会被启动。

从这个故事中，我们可以总结出三个主要要点。

首先，从一开始就启用可观察性解决方案是最佳实践，因为它可以提供事件历史记录，有助于识别潜在问题。没有这些历史记录，我可能不会对0.1%的垃圾收集百分比和6%的CPU消耗给予重视，代码可能会被释放到生产中，造成灾难性后果。将监控解决方案的范围扩展到UAT服务器帮助团队识别潜在的根本原因，并在问题发生之前预防它们。

其次，性能相关的测试用例应该存在于测试过程中，并且应该由具有可观察性经验的人员进行审查。这将确保代码的功能性得到测试，同时也测试其性能。

第三，云原生的性能跟踪技术对于接收高利用率、可用性等方面的警报非常有用。为了实现可观察性，您可能需要配备正确的工具和专业知识。祝编码愉快！