APM，Application Performance Management
APM理论模型大多借鉴 google dapper 论文，Twitter的zipkin，Uber的 jaeger，淘宝的鹰眼，大众的cat，京东的Hydra等
APM从使用上，原理以及搭建进行讲解；分别以大厂自建和开源两条路线介绍，真切感受监控在日常开发、大促活动、故障保障等方方面面的价值。

APM核心

APM主要有三个方面的内容

  1. Logs 日志
    1. 企业日志系统
    2. 错误收集系统
  2. Traces 链路追踪
  3. Metrics 报表统计

接触任何一个 APM 系统的时候，都可以从这三个方面去分析它到底是什么样的一个系统

APM应用场景

Java 语言、web 服务、每个应用有多个实例、以微服务方式部署
每个应用的不同实例分布在不同的 IP 上

1 Logs 日志

Logs 对各个应用中打印的 log 进行收集和提供查询能力。
我们在排查特定的请求的时候，是非常依赖于上下文的日志的。

以前我们都是通过 terminal终端 登录到机器里面去查 log（我好几年都是这样过来的），
但是由于集群化和微服务化的原因，继续使用这种方式工作效率会比较低，
因为你可能需要登录好几台机器搜索日志才能找到需要的信息，所以需要有一个地方中心化存储日志，并且提供日志查询。

ELK

Logs 的典型实现是 ELK （ElasticSearch、Logstash、Kibana） 平台
ELK最核心的就是 ES 的储存和查询的性能得到了大家的认可，经受了非常多公司的业务考验。

  • Logstash 负责收集日志，然后解析并存储到 ES
  • Kibana 是一个非常好用的工具，用于对 ES 的数据进行可视化，简单来说，它就是 ES 的客户端
  • Elastic 其实除了 Logs 以外，也提供了 Metrics 和 Traces 的解决方案，不过目前国内用户主要是使用它的 Logs 功能

主流的日志采集方式

  1. 一种是通过一个客户端程序 FileBeat，收集每个应用打印到本地磁盘的日志，发送给 Logstash；
  2. 一种则是每个应用不需要将日志存储到磁盘，而是直接发送到 Kafka 集群中，由 Logstash 来消费。

Logs 系统的数据来自于应用中打印的日志，它的特点是数据量可能很大，取决于应用开发者怎么打日志
Logs 系统需要存储全量数据，通常都要支持至少 1 周的储存。
每条日志包含 ip、thread、class、timestamp、traceId、message 等信息，它涉及到的技术点非常容易理解，就是日志的存储和查询。
排查问题时，通常先通过关键字搜到一条日志，然后通过它的 traceId 来搜索整个链路的日志。

2 Traces 系统

traces 记录整个调用链路

Logs和 Traces的区别

Traces 系统离业务更远一些了，关注的是一个请求进来以后，经过了

  • 哪些应用
  • 哪些方法
  • 分别在各个节点耗费了多少时间
  • 在哪个地方抛出的异常等，Traces 用来快速定位问题。

Logs 系统使用的是开发者打印的日志，是最贴近业务的；

Traces 系统定义了一套 API，把客户端的模型固化下来；
当前比较主流的 Traces 系统中，Jaeger、SkyWalking 是使用这个规范的，而 Zipkin、Pinpoint 没有使用该规范。

请求的时序图

image.png
从上面这个图中，可以非常方便地看出；
这个请求经过了 3 个应用，通过线的长短可以非常容易看出各个节点的耗时情况

点击某个节点，我们可以有更多的信息展示，比如点击 HttpClient 节点我们可能有 request 和 response 的数据
通过链路分析，很容易就可以看出来这个请求经过了哪些节点、在每个节点的耗时、是否在某个节点执行异常等。

3 Metrics 报表统计

用于各种报表数据的收集和展示
Metrics 方面做得比较好的开源系统，是大众点评开源的 Cat

深度剖析开源分布式监控CAT
https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html

transaction 视图，它展示了很多的我们经常需要关心的统计数据
image.png

Metrics 和 Traces 之间的区别

Metrics 做的是数据统计，比如某个 URL 或 DB 访问被请求多少次，P90 是多少毫秒，错误数是多少等这种问题；
Traces 是用来分析某次请求，它经过了哪些链路，比如进入 A 应用后，调用了哪些方法；
之后可能又请求了 B 应用，在 B 应用里面又调用了哪些方法，或者整个链路在哪个地方出错等这些问题。

Metrics 和 Traces 之间的联系是非常紧密的，它们的数据结构都是一颗调用树，区别在于这颗树的枝干和叶子多不多；
Traces 系统中，一个请求所经过的链路数据是非常全的，这样对排查问题的时候非常有用；
如果要对 Traces 中的所有节点的数据做报表统计，将会非常地耗费资源，性价比太低。

Metrics 系统就是面向数据统计而生的，所以树上的每个节点我们都会进行统计，所以这棵树不能太“茂盛”

哪些数据值得统计

首先是入口，
其次是耗时比较大的地方，比如

  1. db 访问
  2. http 请求
  3. redis 请求
  4. 跨服务调用等，有了这些关键节点的统计数据以后，对于系统的健康监控就非常容易了。