滑县网站建设哪家专业,北京哪里做网站好,wordpress关键词插件吗,做网站商城前景怎么样篇幅一#xff1a;APM基础篇\\1、什么是APM?\\APM#xff0c;全称#xff1a;Application Performance Management #xff0c;目前市面的系统基本都是参考Google的Dapper#xff08;大规模分布式系统的跟踪系统#xff09;来做的#xff0c;翻译传送门《google的Dappe…篇幅一APM基础篇\\1、什么是APM?\\APM全称Application Performance Management 目前市面的系统基本都是参考Google的Dapper大规模分布式系统的跟踪系统来做的翻译传送门《google的Dapper 中文翻译》\\思考下不遵守该理论的是伪APM耍流氓吗\\APM的核心思想是什么 在应用服务各节点相互调用的时候从中记录并传递一个应用级别的标记这个标记可以用来关联各个服务节点之间的关系。比如两个应用服务节点之间使用 HTTP 作为传输协议的话那么这些标记就会被加入到 HTTP 头中。可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的常用的协议就相对容易加入这些内容一些按需定制的可能就相对困难些这一点也直接决定了实现分布式追踪系统的难度。\\2、为什么要用APM?\\有业务痛点才要寻求解决方案个人认为APM需要优先解决测试环境下两个场景问题基于测试先行的原则考虑\\\优先关注宏观数据并不是说测试人员无须关注微观层面的问题在测试角度来看先解决性能测试环境的数据采样、收集问题再去评估生产环境而线上的链路监控需要研发跟运维去配合【研发角度场景】相对于测试人员来说是弱关注了。\\3、市面上有哪些APM工具\\Pinpoint\\tPinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.https://github.com/naver/pinpoint\\tSkyWalking\\tA distributed tracing system, and APM ( Application Performance Monitoring ) .http://skywalking.org\\tZipkin\\tZipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.http://zipkin.io/\\tCAT 大众点评\\tCAT基于Java开发的实时应用监控平台包括实时应用监控业务监控。https://github.com/dianping/cat\4、先说结论\\目前比较贴合 Google Dapper 原理设计的Pinpoint 优于 Zipkin。\Pinpoint对代码的零侵入运用JavaAgent字节码增强技术添加启动参数即可。\并且符合【测试角度场景】性能测试调优监控的宏观\当然结论太早了会有疑惑\\“ Spring Cloud Slueth和zipkin之间的关系是什么 “\\需要看详细对比的详见下图\\\\5、再说对比\\本质上 Spring Cloud Slueth 与 Pinpoint 没有可比性真正对比的是ZipkinSpring Cloud Slueth 聚焦在链路追踪和分析将信息发送到Zipkin利用 Zipkin的存储来存储信息当然Zipkin也可以使用ELK来记录日志和展示再通过收集服务器性能的脚本把数据存储到ELK则可以展示服务器状况信息了。Zipkin的总体展示也是基于链路分析为主。\\\\篇幅二Pinpoint实战篇\\1、Pinpoint架构图\\Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.\\架构图对应说明\\Pinpoint-Collector收集各种性能数据\\tPinpoint-Agent探针与应用服务器例如tomcat)关联部署到同一台服务器上\\tPinpoint-Web将收集到的数据层现在web展示\\tHBase Storage收集到数据存到HBase中\2、Pinpoint的数据结构\\Pinpoint 消息的数据结构主要包含三种类型 SpanTrace 和 TraceId。\\Span 是最基本的调用追踪单元\\t当远程调用到达的时候Span 指代处理该调用的作业并且携带追踪数据。为了实现代码级别的可见性Span 下面还包含一层 SpanEvent 的数据结构。每个 Span 都包含一个 SpanId。\\tTrace 是一组相互关联的 Span 集合\\t同一个 Trace 下的 Span 共享一个 TransactionId而且会按照 SpanId 和 ParentSpanId 排列成一棵有层级关系的树形结构。\\tTraceId 是 TransactionId、SpanId 和 ParentSpanId 的组合\\tTransactionIdTxId是一个交易下的横跨整个分布式系统收发消息的 ID其必须在整个服务器组中是全局唯一的。也就是说 TransactionId 识别了整个调用链SpanIdSpanId是处理远程调用作业的 ID当一个调用到达一个节点的时候随即产生ParentSpanIdpSpanId顾名思义就是产生当前 Span 的调用方 Span 的 ID。如果一个节点是交易的最初发起方其 ParentSpanId 是 -1以标志其是整个交易的根 Span。下图能够比较直观的说明这些 ID 结构之间的关系。\\\3、Pinpoint部署\\网上太多部署文档这里不详细说明简要说明下\\注意版本要求\\有两种方式启动\\方式一修改tomat目录下bin/catalina.sh在Control Script for the CATALINA Server加入以下三行代码\\\CATALINA_OPTS\$CATALINA_OPTS -javaagent:/home/webapps/service/pp-agent/pinpoint-bootstrap-1.6.2.jar\\CATALINA_OPTS\$CATALINA_OPTS -Dpinpoint.agentIdpp32tomcattest\\CATALINA_OPTS\$CATALINA_OPTS -Dpinpoint.applicationName32tomcat\\\第一行pinpoint-bootstrap-1.6.2.jar的位置\第二行agentId必须唯一,标志一个jvm\第三行applicationName表示同一种应用同一个应用的不同实例应该使用不同的agentId,相同的applicationName\\方式二SpringBoot启动\\\java -javaagent:/home/webapps/pp-agent/pinpoint-bootstrap-1.6.2.jar -Dpinpoint.agentIdpp32tomcattest -Dpinpoint.applicationName32tomcat -jar 32tomcat-0.0.1-SNAPSHOT.jar\\4、代码注入是如何工作的\\\Pinpoint 对代码注入的封装非常类似 AOP当一个类被加载的时候会通过 Interceptor 向指定的方法前后注入 before 和 after 逻辑在这些逻辑中可以获取系统运行的状态并通过 TraceContext 创建 Trace 消息并发送给 Pinpoint 服务器。但与 AOP 不同的是Pinpoint 在封装的时候考虑到了更多与目标代码的交互能力因此用 Pinpoint 提供的 API 来编写代码会比 AOP 更加容易和专业。\\5、Pinpoint实战效果演示\\搭建一个java开源项目jforum跑在tomcat下使用jmeter进行压测用户100个\\\\t服务器图ServerMap\\\t通过可视化其组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关组件的详细信息例如其当前状态和事务计数。\\t\\t\\t实时活动线程图Realtime Active Thread Chart\\\t实时监视应用程序内的活动线程。用了官方图当时没截图\\t\\t\\t请求/响应散布图Request/Response Scatter Chart\\\t可视化请求计数和响应模式以确定潜在问题。可以通过在图表上拖动来选择事务以获取更多详细信息。\\t\\t\\t调用栈信息CallStack\\\t增强分布式环境中每个事务的代码级可见性识别单个视图中的瓶颈和故障点。\\t\\t\\t检查器Inspector\\t\查看应用程序的其他详细信息如CPU使用率内存/垃圾收集TPS和JVM参数。\\6、总结\\第一PinPoint从宏观上看总体链路、服务总体状态cpu、内存等等信息符合【测试角度场景】性能测试调优监控的宏观\第二Spring Cloud Slueth需要结合Zipkin从微观来看自身无法单独提供展示要结合Zipkin展示链路问题并没有服务器总体状态的展示更多服务器性能状况等信息展示需要定制脚本通过ELK收集展示符合【研发角度场景】性能测试调优监控的微观\\总的来说两者是结合体要单独使用的话从测试业务上来看PinPoint满足性能测试调优监控的宏观【测试角度场景】\\7、项目场景\\访问某个API后端应用服务产生的一系列链路为何请求一次有23次数据库访问呢这里就是需要排查的的地方详细看看CallTree找出可优化的SQL查询语句。\另外在做性能测试的时候服务器并发的IOPP不断写入也会产生瓶颈需要后续解决。\\8、标签库项目简单压测\\通过jmeter对标签库进行简单压测脚本如下\\通过APM发现问题如下\\pquery.do的res高达6782ms需要安排开发进一步排查定位代码问题\\\\另外一种场景测试人员无法在页面获取到的信息有些情况下测试人员是没有服务器权限这些是服务底层的异常信息可以通过CallTree来查看。\\9、应用服务接入APM后的链路全景蜘蛛网图\\\\参考文献\\Pinpoint githubPinpoint源码解析三Dapper大规模分布式系统的跟踪系统Pinpoint学习笔记Pinpoint v1.5.0 APM 视频介绍
