赞
踩
本文从最根本的可观察性出发,引出实现这种思想的APM(Application Performance Management)框架,通过对APM的核心组件和数据模型的理解,可以加深对ElasticAPM的理解。最后通过实战演练ElasticAPM,来实现应用的性能追踪。
“可观察性”不是供应商能够在系统之外单独交付的功能,而是您在构建系统时植根于其中的一个属性,就像易用性、高可用性和稳定性一样。设计和构建“可观察”系统的目标在于,确保当它在生产中运行时,负责操作它的人员能够检测到不良行为(例如,服务停机、错误、响应缓慢),并拥有可操作的信息以有效地确定根本原因(例如,详细的事件日志、细粒度的资源使用信息,以及应用程序跟踪)。这个目标看似平淡无奇,但组织在实现这一目标时会遇到诸多挑战,常见挑战包括:没有收集足够的信息;收集了太多信息,但没有提取出有指导意义的内容;这些信息分别存储在诸多不同的位置。
如上述引用内容可知,可观测性重点是解决运行中的系统在遇到问题时,较难定位问题的问题,尤其是在大规模分布式系统中,一个业务流程依赖上下游众多的系统,更是提高了定位问题的复杂度。而一个具备良好可观测性的系统,能够用很低的成本有效的定位关键问题所在。下图所示可观测性主要有三大支撑:
上面说的那么多,通俗一点讲举一个例子,当你负责的系统业务逻辑复杂,依赖的第三方服务或者中间件较多的前提下。有一天,你收到了一连串性能报警,你老板问你**为啥这个接口这么慢?**如果可观察性做的比较差的系统,你就疯狂的打log日志,统计各个代码行之间的耗时情况,然后上线,在茫茫日志的海洋里分析到底哪一行比较慢,如果找到了恭喜你,你是幸运的,只需要去掉日志或者改变日志级别,再上一次线就可以了!
但是,很有可能是没有找到,那会不会当时发生GC?当时带宽占用比较多?会不会当时服务器负载高?等等可能性,你由于没有完备的记录,又复现不了,就会很难保证你负责的接口是不是又会爆发性能报警问题,你的老板就会怀疑你的能力!很难受对嘛?
如果这时,天赐你一套功能完备的APM系统,你通过报警中写明的traceId,在APM平台中搜索出对应的调用链,发现你依赖的接口耗时很高,或者通过你的Metrics发现那段时间GC很频繁,再通过log拿到具体的执行信息,Bingo!相信问题已经八九不离十了,10分钟以内回复老板:“我找到问题了,原因是balabala”,没错,问我为什么要有APM,因为一切尽在掌握。
通过上一章节的分析,我们知道了什么是可观察性。那一款好的APM产品就是要提高应用的可观察性的。目前市面上大多数APM产品是应用性能监控(Application Performance Monitoring),但是在维基百科中定义的是应用性能管理(Application Performance Management)。
APM 在维基百科上的定义是应用性能管理(Application Performance Management),而市面上大多数APM产品定义则是应用性能监控(Application Performance Monitoring)。《What Is Application Performance Monitoring and Why It Is Not Application Performance Management》 此文认为应用性能监控是应用性能管理一部分,前者能帮你找到问题,而后者能帮你分析并解决问题。但实际上大部分APM产品都包含了分析问题的部分,并且业界也没有对两个定义作出明确的区分,所以基本上我们可以将两者视为是相同的。
具体可以参考官方文档,总结起来,就是ElasticAPM是在ELK的基础之上,做了应用性能监控组件,把本来就存在的Logging,Metrics,和APM引入的Tracing数据,整合起来,变成了一个一站式的应用可观察性平台。
Elastic APM由四个组件组成:
Elastic APM agent从其检测(instrument)的应用程序中收集不同类型的数据,这些被称为事件,类型包括span,transaction,错误和指标四种。
采用了最新版的ELK和Apm agent
Java agent: elastic-apm-agent-1.12.0.jar
Apm Server: apm-server-7.5.1-darwin-x86_64
ElasticSearch: elasticsearch-7.5.1
Kibana: kibana-7.5.1-darwin-x86_64
环境启动顺序如下
POM.xml,项目中需要引入apm-agent依赖,apm-agent默认会收集一些事件,比如HTTP请求和database queries,并且为了不侵入应用,采用了字节码织入技术来实现java-agent,使得apm-agent对业务系统变得透明,但是透明意味着不可控,apm还提供了public API,来手动可控的方式,来告诉agent采集这些信息。
具体的Java-agent有很多功能,本文不赘述,请参考官方文档
- <dependency>
- <groupId>co.elastic.apm</groupId>
- <artifactId>apm-agent-api</artifactId>
- <version>1.12.0</version>
- </dependency>
Controller代码
- @GetMapping("/test/{name}")
- public String test(@PathVariable String name) {
- String result = null;
- Transaction transaction = ElasticApm.currentTransaction();
- System.out.println(transaction.getTraceId());
- try {
- transaction.setName("WsyController#test");
- transaction.setType("CUSTOM");
- result = testService.test(name);
-
-
- } catch (Exception e) {
- transaction.captureException(e);
- } finally {
- //WARN co.elastic.apm.agent.impl.transaction.AbstractSpan - End has already been called: ''
- //注意,如果调用ElasticApm.currentTransaction();就不需要transaction.end();否则会报如上警告
- transaction.end();
- }
-
- return result;
- }
Service代码
- @Service
- public class TestService {
- public String test(String name) {
- Span span = ElasticApm.currentTransaction().startSpan();
- try {
- span.setName("test0-wsy");
- test1(name);
- } catch (Exception e) {
- span.captureException(e);
- } finally {
- span.end();
- }
- return "hello " + name;
- }
-
- public String test1(String name) {
- Span span = ElasticApm.currentTransaction().startSpan();
- try {
- span.setName("test1-wsy");
-
- } catch (Exception e) {
- span.captureException(e);
- } finally {
- span.end();
- }
- return name;
- }
- }
请求Controller之后,刷新Kibana,发现已经拥有了链路追踪
1、本文在单机版的环境中,测试通过,但是在分布式环境中,请求会串联起很多应用,那服务跟踪能否实现?实现的原理是什么?
2、Elastic APM可以自动采集http请求,在PRC分布式环境中,Elastic APM能否正常工作?是否必须采用 public API来实现?
1、APM可以提升系统的可观察性
2、ElasticAPM可以借助ElasticSearch和Kibana一站式的解决链路追踪
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。