apm是什么意思（pm和apm是什么意思）

APM，全称：Application Performance Management ，目前市面的系统基本都是参考 Google 的 Dapper（大规模分布式系统的跟踪系统）来做的，翻译传送门《google 的Dapper 中文翻译》

思考下：不遵守该理论的是伪 APM，耍流氓吗？

APM 的核心思想是什么？ 在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。比如两个应用服务节点之间使用 HTTP 作为传输协议的话，那么这些标记就会被加入到 HTTP 头中。可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的，常用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。

有业务痛点，才要寻求解决方案，个人认为，APM 需要优先解决测试环境下两个场景问题，基于测试先行的原则考虑：

优先关注宏观数据，并不是说测试人员无须关注微观层面的问题，在测试角度来看，先解决性能测试环境的数据采样、收集问题，再去评估生产环境，而线上的链路监控需要研发跟运维去配合，【研发角度场景】相对于测试人员来说是弱关注了。

目前比较贴合 Google Dapper 原理设计的，Pinpoint 优于 Zipkin。Pinpoint 对代码的零侵入，运用 JavaAgent 字节码增强技术，添加启动参数即可。并且符合【测试角度场景】性能测试调优监控的宏观；当然，结论太早了，会有疑惑：

“ Spring Cloud Slueth 和 zipkin 之间的关系是什么？ “

需要看详细对比的，详见下图：

本质上 Spring Cloud Slueth 与 Pinpoint 没有可比性，真正对比的是 Zipkin，Spring Cloud Slueth 聚焦在链路追踪和分析，将信息发送到 Zipkin，利用 Zipkin 的存储来存储信息，当然，Zipkin 也可以使用 ELK 来记录日志和展示，再通过收集服务器性能的脚本把数据存储到 ELK，则可以展示服务器状况信息了。Zipkin 的总体展示，也是基于链路分析为主。

Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.

架构图对应说明：

Pinpoint 消息的数据结构主要包含三种类型 Span，Trace 和 TraceId。

网上太多部署文档，这里不详细说明，简要说明下：

注意版本要求：

有两种方式启动：

方式一：修改 tomat 目录下 bin/catalina.sh，在 Control Script for the CATALINA Server 加入以下三行代码：

复制代码

第一行：pinpoint-bootstrap-1.6.2.jar 的位置第二行：agentId 必须唯一, 标志一个 jvm第三行：applicationName 表示同一种应用：同一个应用的不同实例应该使用不同的 agentId, 相同的 applicationName

方式二：SpringBoot 启动

复制代码

Pinpoint 对代码注入的封装非常类似 AOP，当一个类被加载的时候会通过 Interceptor 向指定的 *** 前后注入 before 和 after 逻辑，在这些逻辑中可以获取系统运行的状态，并通过 TraceContext 创建 Trace 消息，并发送给 Pinpoint 服务器。但与 AOP 不同的是，Pinpoint 在封装的时候考虑到了更多与目标代码的交互能力，因此用 Pinpoint 提供的 API 来编写代码会比 AOP 更加容易和***。

搭建一个 java 开源项目 jforum ，跑在 tomcat 下，使用 jmeter 进行压测，用户 100 个：

查看应用程序的其他详细信息，如 CPU 使用率，内存 / 垃圾收集，TPS 和 JVM 参数。

第一：PinPoint 从宏观上看：总体链路、服务总体状态（cpu、内存等等信息），符合【测试角度场景】性能测试调优监控的宏观；第二：Spring Cloud Slueth 需要结合 Zipkin 从微观来看：自身无法单独提供展示，要结合 Zipkin 展示链路问题（并没有服务器总体状态的展示），更多服务器性能状况等信息展示需要定制脚本通过 ELK 收集展示，符合【研发角度场景】性能测试调优监控的微观；

总的来说两者是结合体，要单独使用的话，从测试业务上来看：PinPoint 满足，性能测试调优监控的宏观【测试角度场景】

访问某个 API，后端应用服务产生的一系列链路，为何请求一次有 23 次数据库访问呢？这里就是需要排查的的地方，详细看看 CallTree，找出可优化的 SQL 查询语句。

另外，在做性能测试的时候，服务器并发的 IO，PP 不断写入也会产生瓶颈，需要后续解决。

通过 jmeter 对标签库进行简单压测，脚本如下：

通过 APM 发现问题如下：

pquery.do 的 res 高达 6782ms，需要安排开发进一步排查定位代码问题

另外一种场景，测试人员无法在页面获取到的信息（有些情况下，测试人员是没有服务器权限），这些是服务底层的异常信息，可以通过 CallTree 来查看。

Pinpoint github

Pinpoint 源码解析（三） Dapper，大规模分布式系统的跟踪系统 Pinpoint 学习笔记 Pinpoint v1.5.0 APM 视频介绍

原文地址：https://www.infoq.cn/article/apm-Pinpoint-practice/?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

本文内容由互联网用户自发贡献，该文观点仅代表作者本人，因此内容不代表本站观点、本站不对文章中的任何观点负责，内容版权归原作者所有、内容只用于提供信息阅读，无任何商业用途。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站（文章、内容、图片、音频、视频）有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至353049283@qq.com举报，一经查实，本站将立刻删除、维护您的正当权益。