使用Elastic APM做应用性能监控

使用Elastic APM做应用性能监控

本文主要包含五个部分。第一部分对应用性能监控（APM）相关的概念进行了介绍，包括可观察性和应用性能监控；第二部分将Elastic APM和业界流行的APM产品Apache SkyWalking进行了对比；第三部分对Elastic公司推出的APM产品相关的组件和数据模型进行了介绍；第四部分介绍Elastic APM的使用实践，最后在第五部分进行了总结。

一、概念

可观察性

包括我在内，相信很多人都会对这个名词比较陌生并且产生疑问：“可观察性是什么？”。按照文章《借助 Elastic Stack 实现可观察性》的定义：

“可观察性”不是供应商能够在系统之外单独交付的功能，而是您在构建系统时植根于其中的一个属性，就像易用性、高可用性和稳定性一样。设计和构建“可观察”系统的目标在于，确保当它在生产中运行时，负责操作它的人员能够检测到不良行为（例如，服务停机、错误、响应缓慢），并拥有可操作的信息以有效地确定根本原因（例如，详细的事件日志、细粒度的资源使用信息，以及应用程序跟踪）。

那么这个概念又是什么怎么出现的呢？文章《观察之道：带你走进可观察性》提到：

可观察性进入人们的视野是来自于 Apple 的工程师 Cindy Sridharan 的博文“监控与观察”（Monitoring and Oberservability）。 但我认为，Google 著名的 SRE 体系在之前就已经奠定了可观察性的理论基础。

打造可观察性的系统包括三个要素：

image.png

1. 日志：程序运行产生的事件，可以详细解释其运行状态；
2. 指标：一组聚合数值，主要用于监控基础设施（机器、容器、网络等），但也有应用会用于监控业务层面，比如开源搜索系统Elasticsearch就有关于查询或写入量、耗时、拒绝率等应用层面的指标；
3. 应用性能监控（APM）：深入到代码层面的追踪（或监控），包括程序内部执行过程、服务之间链路调用等情况，能轻易的找到程序“慢”的原因。APM最常见被用于对web服务器中一次请求处理过程的追踪，包括内部执行逻辑、外部服务的调用及它们相应的耗时。

介绍完可观察性这个概念，下面将介绍文章的主题APM。

应用性能监控（APM）

对于大部分应用程序来说性能都是很重要的一个因素，尤其对于比如网站、手机app等直接由用户访问的应用来说更是如此，因为性能较差的应用将会直接影响其用户体验。因此，能对应用进行性能监控变得非常重要，这将帮助我们找到性能瓶颈并优化。

应用性能监控（Application Performance Monitoring，APM），是对应用程序性能和可用性的监视和管理。 APM努力检测和诊断复杂的应用程序性能问题，以维持预期的服务等级。

APM 在维基百科上的定义是应用性能管理（Application Performance Management），而市面上大多数APM产品定义则是应用性能监控（Application Performance Monitoring）。《What Is Application Performance Monitoring and Why It Is Not Application Performance Management》 此文认为应用性能监控是应用性能管理一部分，前者能帮你找到问题，而后者能帮你分析并解决问题。但实际上大部分APM产品都包含了分析问题的部分，并且业界也没有对两个定义作出明确的区分，所以基本上我们可以将两者视为是相同的。

Gartner Research 将APM按功能分为五个维度（2016年将这5个维度归纳至3个），业界的APM产品的主要功能也都基本包含在内。

img

1. 最终用户体验监控（End user experience monitoring）。通过监控用户的行为以期优化用户体验。比如：监控用户和web界面/客户端的交互，并记录交互事件的时间。
2. 运行时应用程序架构（Runtime application architecture）。理解服务间的依赖关系、架构中应用程序交互的网络拓扑。
3. 业务事务（Business transaction）。产生有意义的SLA报告，并从业务角度提供有关应用程序性能的趋势信息。
4. 深入组件监控（Deep dive component monitoring）。通常需要安装agent并且主要针对中间层，包括web服务器、应用和消息服务器等。健壮的监控应该能显示代码执行的清晰路径，因为这一维度和上述第二个维度紧密相关，APM产品通常会将这两个维度合并作为一个功能。
5. 分析或报告（Analytics/reporting）。将从应用程序中收集的一系列指标数据，标准化的展现成应用性能数据的通用视图。

二、Elastic APM和Apache SkyWalking对比

这部分将对Elastic APM和目前比较流行的开源APM系统Apache SkyWalking进行一些主要功能上的对比。

从上述对比可以看出Elastic APM比Apache Skywalking更胜一筹，更多APM产品的对比可以参考文章《应用性能监控（APM）》第二部分“选型”。

三、Elastic APM介绍

Elastic APM是一个Elastic Stack的应用性能监控（APM）系统，它能够：

1. 实时的监控软件服务和应用：为传入的请求，数据库查询，对缓存的调用，外部HTTP请求等收集有关响应时间的详细性能信息，使得可以轻松快速地找出并解决性能问题。
2. 自动收集未处理的错和异常以及它们的调用栈，让你能快速定位新错误并且跟踪错误出现的频率。
3. 收集机器级别以及特定agent的指标（比如Java JVM和Go Runtime的指标）。
4. 支持分布式追踪：使你能够在一个视图中分析整个服务架构的性能。更多关于分布式追踪的概念可参考google的dapper 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》
5. 支持真实用户监控（Real User Monitoring，RUM）：可捕获用户与客户端（例如Web浏览器）的交互。

组件

Elastic APM由四个组件组成：

• APM agents：以应用程序库的形式提供，收集程序中的性能监控数据并上报给APM server。
• APM Server：从APM agents接收数据、进行校验和处理后写入Elasticsearch特定的APM索引中。虽然agent也可以实现为：将数据收集处理后直接上报到ES，不这么做官方给出的理由：使agent保持轻量，防止某些安全风险以及提升Elastic组件的兼容性。
• Elasticsearch：用于存储性能指标数据并提供聚合功能。
• Kibana：可视化性能数据并帮助找到性能瓶颈。

image-20190930150212401

数据模型

Elastic APM agent从其检测（instrument）的应用程序中收集不同类型的数据，这些被称为事件，类型包括span，transaction，错误和指标四种。

• Span 包含有关已执行的特定代码路径的信息。它们从活动的开始到结束进行度量，并且可以与其他span具有父/子关系。
• 事务（Transaction） 是一种特殊的Span（没有父span，只能从中派生出子span，可以理解为“树”这种数据结构的根节点），具有与之关联的其他属性。可以将事务视为服务中最高级别的工作，比如服务中的请求等。
• 错误：错误事件包含有关发生的原始异常或有关发生异常时创建的日志的信息。
• 指标：APM agent自动获取基本的主机级别指标，包括系统和进程级别的CPU和内存指标。除此之外还可获取特定于代理的指标，例如Java agent中的JVM指标和Go代理中的Go运行时指标。

四、Elastic APM使用实践

这部分将通过基于go gin http框架和java spring-boot 开发的两个demo介绍Elastic APM的使用实践。

使用版本：

• APM Java agent： 1.x
• APM Go agent： 1.x
• APM Server: 6.8.2
• Elasticsearch 及 Kibana: 6.8.2 基础版

APM Agent与Server的版本兼容情况见：Agent and Server compatibility

APM Java Agent

对于在支持技术中的库，APM Java Agent 能够自动检测应用程序性能和跟踪错误，例如，它记录传入HTTP请求的事务（Transaction）和数据库查询的Span。这得益于javaagent提供的字节码注入功能。

对于不支持的库或具体业务代码，可以使用Public API 手动采集性能数据。

自动检测（instrument）

spring-boot-demo是一个基于spring boot的简单web程序，提供了”新增用户“和”查询所有用户“两个接口。此demo中使用了 Web框架 Spring Web MVC 以及数据库连接库 JDBC，agent将自动检测这两个库而无需修改代码。根据文档中的介绍：

• Spring Web MVC： 自动为一个controller请求生成一个APM 事务（Transaction），名称格式为ControllerClass#controllerMethod
• JDBC: 自动为JDBC 查询自动创建DB类型的APM span，包括由hibernate等ORM所执行的查询。

试试看效果。

1. 对spring boot demo发起两次http请求： 添加一个用户以及获取所有用户信息

[root@VM_17_4_centos spring-boot-demo]# curl localhost:8080/user -XPOST -d name=First -d email=first@xx.com
Saved

[root@VM_17_4_centos spring-boot-demo]# curl localhost:8080/user
[{"id":1,"name":"First","email":"first@xx.com"}]

1. 在kibana APM界面可视化
2. 在Services列表出现我们的demo服务spring-boot-demo，说明请求APM agent已有数据上报

image-20191009155709486

• 点击服务名 spring-boot-demo，可以看到关于服务的APM整体性能数据：

image-20191009155640104

可以看到“Request”中已经有了我们的两次接口请求UserController#getAllUsers 和 UserController#addNewUser。

• 点击“Request”中的请求UserController#addNewUser，可以看到这个请求（对应一个“事务”事件）相关的信息：

image-20191009155954561

在页面上方是关于请求耗时、每分钟请求数以及响应时间分布情况的图表，而下方是一个事务（Transaction）的详细信息，包括在Timelines中展现请求处理中各组件的耗时情况（在此例中是使用JDBC进行数据库操作）。

手动检测

除了自动检测的方式外，我们还可以为指定的代码片段手动收集性能数据。

下述例子给”添加新用户“接口增加了一个耗时操作（Thread.sleep(1000)）并为其创建名为Thread.sleep的 span，以及为这个span添加了自定义标签opArg，值为1000。

	@PostMapping(path="") // Map ONLY POST Requests
	public @ResponseBody String addNewUser (@RequestParam String name
			, @RequestParam String email) throws Exception {

		// 除了在框架默认采集的span外，还可以的给指定的代码片段增加自定义span
		Transaction parent = ElasticApm.currentTransaction();
		Span span = parent.startSpan();
			try {
			span.setName("Thread.sleep");
			span.addLabel("opArg", 1000);
			// do your things
			Thread.sleep(1000);
		} catch (Exception e) {
			span.captureException(e);
			throw e;
		} finally {
			span.end();
		}
		// 创建User
		User n = new User();
		n.setName(name);
		n.setEmail(email);
		userRepository.save(n);
		return "Saved";
	}

重新构建运行demo后看看执行效果。

• 调用”添加用户“接口

[root@VM_17_4_centos spring-boot-demo]# curl localhost:8080/user -XPOST -d name=Second -d email=second@xx.com

• 在kibana查看Timeline，已经出现了名为Thread.sleep的span

image-20191009161150430

分布式追踪（distributed tracing）

分布式追踪是现代应用程序性能监视的关键功能之一， 随着软件应用程序体系结构从单一体系结构转变为分布式的基于服务的体系结构，跟踪请求如何在系统间流动的能力也变得至关重要。

使用分布式跟踪，请求事务被链接到一起形成一个跟踪，其中包括端到端性能，即如何处理请求以及其中包含哪些服务。 分布式跟踪使开发和运维人员可以根据上下文关联各个事务的性能，从而快速查明最终用户体验的瓶颈。

Elastic APM在6.5开始支持分布式跟踪

为了演示分布式服务跟踪，这里引入一个新的demo程序 gin-demo，基于go语言的http web框架gin 开发，功能为：查询一个用户id对应的所有商品订单。

在spring-boot-demo中，为了能在调用gin-demo http接口时将事务（Transaction）id传递给它以支持分布式追踪，需要使用在 Supported technologies - Networking frameworks 中提到的网络库，这里选择的是Apache HttpClient库。

两个demo程序的调用关系如下图所示：

image-20190929233736630

调用spring-boot-demo 获取用户信息接口/user/:id，其内部将会通过调用gin-demo接口/user/:id/orders获取用户的订单信息

[root@VM_17_4_centos ~]# curl localhost:8080/user/1
{"user":{"id":1,"name":"First","email":"first@xx.com"},"orders":[{"id":"1","productID":"1","userID":"1"}]}

1. 在kibana查看分布式跟踪信息

image-20191009200902054

到这里实践部分就已经结束了，若你想了解更多Elastic APM的使用实践，可以参考官方提供的demo opbeans。

五、总结

应用性能监控（APM）作为可观察性系统三个要素中的重要一员，有着其他两者（日志和指标）所无法做到的事：能帮助我们深入到代码层面的追踪（或监控），包括程序内部执行过程、服务之间链路调用等情况，能轻易的找到程序“慢”的原因。

在和其他产品的对比方面，通过对Elastic APM和Apache Skywalking进行对比发现Elastic APM在功能上更胜一筹。

最后在使用方面，可以看到有部分语言（Java、.Net、Node.js）的一些库得益于“注入”的技术，可以在不需要侵入代码的情况下就能进行应用性能监控，使用上非常便利；而对于未提供这种技术的语言（Python, Ruby, Javascript, Go ），Elastic APM也为一些库提供了方便使用的SDK。即使上述两种方式对你的应用程序都不适用，你也可以使用Elastic APM为各语言都提供的 Public API 的手动采集。

参考

• 《借助 Elastic Stack 实现可观察性》
• 《观察之道：带你走进可观察性》
• Application Performance Management wikipedia
• 《What Is Application Performance Monitoring and Why It Is Not Application Performance Management》
• 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》