APM：系统监控的应用报告
一、主流的APM应用概况：
Pinpoint：基本不用修改源码和配置文件，只要在启动命令里指定javaagent参数即可，对于运维人员来讲最为方便；
Zipkin：需要对Spring、web.xml之类的配置文件做修改，相对麻烦一些；
CAT：因为需要修改源码设置埋点，因此基本不太可能由运维人员单独完成，而必须由开发人员的深度参与了，而很多开发人员是比较抗拒在代码中加入这些东西滴；
推荐的顺序：Pinpoint-->Zipkin-->CAT
原因很简单，就是这三个工具对于程序源代码和配置文件的侵入性，是依次递增的：
相对于传统的监控软件（Zabbix之流）的区别，APM跟关注在对于系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因，而不仅仅像传统监控软件一样只提供一些零散的监控点和指标，就算告警了也不知道问题是出在哪里。
https://blog.csdn.net/konglongaa/article/details/55807192
二、APM监控的关注点有哪些？
请求的响应时间（平均响应时间、多数的请求响应时间）
接口的调用关系，各个接口被调用的次数
请求的URL
发送请求的Client端信息：IP、hostname等
请求的HTTP类型（GET、POST）
请求的端口号、协议（HTTP、HTTPS）
Server端的服务名
对数据库的增删改查的操作
异常信息的抓取（异常的堆栈信息，包含异常触发的代码位置）
三、Elastic APM的表现怎么样？
以上各个监控的指标有哪些没有实现的？
1、接口的调用关系
2、触发异常的代码定位
对异常的抓取能力：
1、后台异常 ，例：500
| 500异常 | 无catch,无 throw | catch | throw |
| dicover | context.response.status_code 200 | processor.event span | processor.event error |
| error.exception.message NullPointerException | |||
| processor.event error | context.response.status_code - | context.response.status_code 200 | |
| processor.name error | |||
| Dashboard | 可以抓取异常 | 没有异常的记录 | error.exception.message NullPointerException |
| 页面报错 | 有报错 | 无报错 | 有报错 |
2、页面异常，例：404
| 404异常 | 无catch,无 throw | catch | throw |
| dicover | context.response.status_code 404 | context.response.status_code 404 | context.response.status_code 404 |
| processor.event transaction | processor.event transaction | processor.event transaction | |
| Dashboard | 没有作为异常处理 | 没有异常的记录 | 没有异常的记录 |
| 页面报错 | 有报错 | 有报错 | 有报错 |