APM数据采集的两种⽅式深⼊对⽐——探针埋点VS互联数据
本⽂约有5000字，浏览全⽂预计需要10分钟。
随着移动互联⽹、云计算、⼤数据、物联⽹等技术的迅猛发展，各种业务应⽤不断出现，IT应⽤复杂度呈现爆炸式增长，数据获取的⾼实时化、业务需求的快速迭代、以及产品和服务的即刻落地，这些⾼要求使运维团队所承受的责任更加沉重。
运维⼯程师既要保证服务和产品的可靠性、稳定性，优化服务、快速定位故障、提升⽤户体验等，同时还要为业务决策提供数据⽀撑，引领业务创新。应对上述挑战关键在于业务监控时能否获取全量、实时、精确的数据。获取数据有多种⽅式，本⽂对⽬前主流的两种获取数据⽅式——探针埋点与互联数据，进⾏深⼊对⽐分析。
1. Agent获取数据实现
Agent也就是常说的探针埋点，通过对⽣产服务器上的应⽤部署或者嵌⼊探针进⾏应⽤性能数据采集。这种⽅式能够提供⾮常完整与细粒度的监控数据采集，提供代码级的问题定位。但此⽅式对应⽤有侵⼊性，如果埋点代码异常，会对应⽤本⾝的性能和稳定性产⽣影响。
探针埋点的⽅式主要分为两类：
•以Zipkin为代表的代码侵⼊式埋点；
•以PinPoint为代表的字节码增强式埋点。
1.1 代码⼊侵式埋点 1.1.1 简介
代码侵⼊式埋点是指提供应⽤开发的SDK，或者提供集成埋点代码的框架供应⽤开发者调⽤。像Google这类具备框架研发能⼒的企业将植⼊点选在开发框架或通信框架中，确保基于统⼀框架开发或通信的应⽤天然具备埋点能⼒，开发团队除框架外⽆需关注埋点实现和调⽤⽅式。这种埋点⽅式优势在于使⽤框架后⽆需额外关注埋点能⼒，变相降低了埋点的成本，Twitter的Zipkin、淘宝的鹰眼、⼤众点评的CAT等都属于这类埋点⽅式。
代码侵⼊式埋点具有较好的扩展性，⽅便⽤户⾃定义采集的数据类型与层次。但⽆论提供框架埋点还是提供装备库、SDK的⽅式都需要侵⼊代码，在应⽤开发及框架升级等场景下，应⽤需要重新修改代码。同时，对于应⽤开发⼈员来说，精准地识别埋点位置也有难度，且基于代码侵⼊的埋点跟踪级别较低，⽆法获取⾜够详细的运⾏动态信息。
1.1.2 典型产品分析——Zipkin
Zipkin 是⼀款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper
的论⽂设计，由Twitter公司开发贡献。其主要功能是聚集来⾃各个异构系统的实时监控数据，⽤来追踪微服务架构下的系统延时问题。应⽤系统需要进⾏装备（instrument）以向 Zipkin 报告数据。Zipkin 的⽤户界⾯可以呈现⼀幅关联图表，以显⽰有多少被追踪的请求通过了每⼀层应⽤。Zipkin 以 Trace 结构表⽰对⼀次请求的追踪，⼜把每个 Trace 拆分为若⼲个有依赖关系的 Span。在微服务架构中，⼀次⽤户请求可能会由若⼲个后台服务负责处理，那么每个处理请求的服务就可以理解为⼀个 Span（可以包括 API 服务、缓存服务、数据库服务以及报表服务等）。当然这个服务也可能继续请求其他的服务，因此 Span 是⼀个树形结构，以体现服务之间的调⽤关系。Zipkin 的⽤户界⾯除了可以查看 Span 的依赖关系之外，还以瀑布图的形式显⽰了每个 Span 的耗时情况，可以⼀⽬了然地看到各个服务的性能状况。打开每个 Span，还有更详细的数据以键值对的形式呈现，⽽且这些数据可以在装备应⽤的时候⾃⾏添加。
- Zipkin架构图 -
根据上述架构图可以看到，Zipkin内部主要分为：Transport、Collector、Storage、API、UI五个部分。•Collector：负责接收各系统报告过来的追踪数据。
•Storage：默认使⽤Cassandra存储数据，也可以替换为其他存储，例如mysql5.6-5.7，ElasticSearch 2.x和5.x，以及⼀些第三⽅的存储。
•API：查询服务⽤来向其他服务提供数据查询的接⼝，以json api格式提供。
•UI：Web服务是官⽅默认提供的⼀个图形⽤户界⾯。
•Transport：负责运输从Service收集来的Spans，并把这些Spans转化为Zipkin的通⽤Span，并将其传递到存储层。
•Transport：负责运输从Service收集来的Spans，并把这些Spans转化为Zipkin的通⽤Span，并将其传递到存储层。
这种⽅法是模块化的，允许任何⽣产者接收任何类型的数据，Zipkin配有HTTP、Kafka、Scribe三种类型的
Transport。Instrumentations负责和Transport进⾏交互。
- Zipkin UI界⾯ -
Zipkin UI以依赖图表展⽰有多少跟踪请求经过了每个应⽤程序；如需解决延迟问题，可以过滤或者排序所有的跟踪请求，并且可以查看每个跟踪请求占总跟踪时间的百分⽐,⼀⽬了然地看到各个服务的性能状况。Zipkin的缺点是采⽤侵⼊式的埋点⽅式，需要提供多种类型的客户端SDK，会对应⽤性能和
稳定性产⽣影响。要减少或消除这种影响就需要在探针监测技术的研究和优化上投⼊较多研发成本，后续使⽤维护上也需要较多的⼈⼒成本。
1.2 字节码增强式埋点 1.
2.1 简介
字节码增强式埋点⽅式⽆需修改代码，不同的编程语⾔通过不同的技术在语⾔运⾏环境或基础库上植⼊。利⽤字节码增强技术，Java应⽤在启动JVM时通过不同的埋点插件覆盖不同的通信协议、中间件和开发框架，对Java基础调⽤代码进⾏函数级埋点。这种埋点⽅式的优势在于能够采集到堆栈级的调⽤信息及其他更多运⾏态信息，帮助使⽤者⽆需⽇志等辅助⼿段即可快速完成问题定位。代表性的开源产品PinPoint及⼤部分商业化产品都采⽤这类⽅式。
使⽤字节码增强技术进⾏APM数据采集时，通过在应⽤启动时配置Java Agent探针的⽅式主动⼲预应⽤代码⾏为，应⽤开发者⽆需进⾏代码修改，由APM产品来决定在哪些API进⾏数据埋点。理论上来说字节码增强技术能够在任意位置进⾏埋点。
1.2.2 典型产品分析——PinPoint
Pinpoint 是⼀个分布式事务跟踪系统的平台，其思路基于 Google Dapper，⽤于基于 Java 的⼤规模分
布式系统，通过跟踪分布式应⽤之间的调⽤，帮助分析系统总体结构和内部模块之间如何相互联系，并提供清晰的可视化视图来定位问题区域和潜在瓶颈。Pinpoint 由三个主要组件组成：Collector、Web和Agent，采⽤HBase进⾏存储。PinPoint可以实现如下功能：
•服务器地图：通过分布式系统的模块和他们之间的相互联系可视化来理解系统拓扑。点击某个节点会展⽰该模块的详情，如该节点当前的状态和请求数量等。
•实时活动线程图表：可以实时监控应⽤内部的活动线程。
•请求/响应分布图：在图表上拖拽查看被选中请求的更多详情。通过可视化的长期请求数量和响应模式来定位潜在问题。
•调⽤栈：在分布式环境中为每个调⽤⽣成代码级别的可视图，在单个视图中定位瓶颈和故障点。
•巡检：查看应⽤的其他信息，如主机CPU使⽤率、内存/垃圾回收、JVM参数等。
相⽐Zipkin，PinPoint可以收集更丰富的数据，但PinPoint是和被监控应⽤⼀起运⾏的额外应⽤，这增加了bug发⽣的可能性。虽然使⽤字节码增强使得PinPoint看上去不需要修改应⽤代码，但如果Pinpoint发⽣问题就会给应⽤造成风险。另外，PinPoint作为额外应⽤跑在系统上也会消耗部分系统资源，官⽹上给出的损耗在百分之⼏，但在实际的压⼒测试环境中发现，使⽤Pinpoint的性能损失可达3
0%以上。另外，作为开源项⽬的PinPoint还有待完善和改进，这也需要投⼊研发及后续使⽤维护的⼈⼒成本。
1.2.3 商业产品分析——Dynatrace
国内外知名的字节码增强埋点商业产品不少，本⽂以国外⾮常具有代表性的产品Dynatrace进⾏介绍。
Dynatrace通过轻量级的、在⽣产环境中可部署的架构组件，对进⼊应⽤的所有交易进⾏端到端的监控和分析，从单个⽤户点击浏览器开始，⼀直追踪到该点击动作在后台的代码执⾏流，贯穿整个应⽤，最终可以跟踪到此⽤户点击导致的数据库访问动作。
- Dynatrace架构⽰意图 -
如上图所⽰，Dynatrace由七个主要组件构成：
1.dynaTrace Agents：⼀个库⽂件（ .so 或 .dll），安装在运⾏JVMs/CLRs/原⽣(Native)进程的应⽤服务器上；
2.dynaTrace Browser Agents：以浏览器插件的⽅式安装在浏览器上 (Internet Explorer 6/7/8)；
3.dynaTrace Server：独⽴的 JAVA 进程，dynaTrace环境的核⼼组件，提供集中的配置和管理。它接收来⾃监控插件
和代理的信息并进⾏关联处理；
4.dynaTrace Analysis Server：独⽴的 JAVA 进程，负责离线分析⾼资源消耗的分析任务（如内存转储的分析）。在
POC环境中，常将它和dynaTrace Server安装在同⼀台机器上；
5.dynaTrace Collector：独⽴的 JAVA 进程，负责管理dynaTrace Agents的插桩和接收到事件后的处理；
6.dynaTrace Repository ：数据库，⼀般使⽤内嵌的数据库（dynaTrace Server 安装时⾃带），也⽀持使⽤
Oracle/SQL Server/DB2/PostgeSQL；
7.dynaTrace Client：表现层（基于 Eclipse），所有的配置任务或数据操作都要通过它完成。既可以安装在⽤户的本
地机器上，也可以通过Java Web Start从dynaTrace Server启动。
Dynatrace的核⼼功能
1. 交易分析。可以跨越WEB/Web Server/Java/.Net/C/CICS边界跟踪交易，同时记录和捕捉上下⽂环境，例如⽤户会话信息、⽅法参数、返回值、⽇志消息、异常详细信息等。
2. WEB请求性能分析。分析哪些 Web 请求⼊⼝存在性能瓶颈。
3. 数据库使⽤分析。分析执⾏时间长的 SQL 语句。
4. 交易热点分析。分析交易时间主要花费在哪些系统部件或 API 层上。
5. 应⽤CPU使⽤情况分析。出应⽤耗⽤CPU时间多的部件。
6. 线程问题分析。通过线程转储快速发现和定位多线程故障，线程死锁，以及由资源竞争导致的线程挂起。
7. 内存问题诊断。可视化显⽰应⽤的内存使⽤情况，确定应⽤每⼀层内存的内存需求以及分析垃圾回收对交易响应时间的影响。
Dynatrace的性能消耗
Dynatrace使⽤⾃动传感器（auto sensor）来定位任何运⾏缓慢的节点，它的⼯作原理是对CPU运⾏时长进⾏采样。采样频率设置越低，⾃动传感器的CPU采样间隔越长，Dynatrace的系统开销也就越⼩，最低为1%，⾮⽣产版本最⾼可达50%。
Dynatrace Agent部署前提条件和系统要求
1.⼀般情况下，需要⽤户提供部署dynaTrace Agents 所需的访问操作系统、应⽤服务器启动脚本和应⽤服务管理控制台的权限。
2.JAVA应⽤：需要在JVM启动选项中添加”-Xrun”或”-agentpath”选项。
3.NET应⽤：dynaTrace安装⼯具会设置环境变量COR_PROFILER将dynaTrace Agent 加载到环境中，运⾏应⽤的⽤户需要具有访问注册表和安装dynaTrace Agent .dll 的⽬录权限。要获取Windows性能计数器，⽤户要具有相应的权限（e.g. 性能监控组的成员）。
4.C/C++应⽤：使⽤分析原⽣应⽤的agent，需要修改源代码并在编译时链接 dynaTrace动态库，这意味着要有可⽤的构建环境并需要重新构建应⽤。
瀑布图插件5.Java/基于浏览器的应⽤：Internet Explorer 6/7/8 需要安装dynaTrace browser agent（IE插件）。
6.必须去除JVM/CLR上任何已有的远程调试器、分析和监控⼯具代理。
从上述介绍可以看出，与PinPoint类似，Dynatrace通过字节码增强埋点或类似技术在应⽤加载的过程中对⽤户代码进⾏动态修改。此类技术的优点在于可以对应⽤性能做⽐较完整的、分层次的监控，提供代码级的问题定位（前提条件是满⾜Agent部署条件），但是同样可能对应⽤性能和稳定性产⽣影响。因为要分析代码级的问题，所以对使⽤者也有⼀定的要求。除了应⽤性能数据外，如果⽤户还想获取业务相关数据、为业务决策提供数据依据，由经验决策向数据驱动决策转型（如利⽤全量交易过程数据实现真正的实时风控以及精准营销），采⽤埋点⽅式实现起来⽐较困难，需要消耗更多的⼈⼒和资源成本。
2. 互联数据实现 2.1 简介
互联数据（Wire Data）是指连接客户端和服务器之间的⽹络光纤所承载的全量、双向的通讯数据。它是被处理过的、⾼价值的业务可⽤数据源，是实时、直观了解系统业务运⾏状况最全⾯客观的参考数据资源。
通过实时地将⽹络中传输的海量数据重组⽽成的结构化数据，可以帮助IT运维⼈员创建⾏为基线、检测异常⾏为，进⾏实时地性能故障定位和排除等；同时，让运维团队贴近业务，可以⽤数据来监测业务的交易量、成功率、失败率等，为业务和运营团队提供数据⽀撑，让IT基础设施更好地提供澎湃动
⼒，为科技引领业务创新创造可能。
2.2 典型产品分析——天旦互联数据引擎
- 天旦互联数据引擎产品架构 -
- 天旦互联数据引擎技术原理 -
天旦互联数据引擎性能特点：
1.零风险。纯旁路采集真实⽹络数据，对现有业务应⽤的⼚商、系统等⽆要求，⽆需部署Agent, 对⽣产系统⽆影响。
所基于的端⼝镜像技术已经⾮常成熟，对⽹络设备性能⽆影响，详情可参见CISCO官⽅参考⽂献：
www.cisco/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html?
dtid=osscdc000283#anc55
2.⾼实时性。毫秒级别的低延迟输出，提升事中反欺诈、实时风控、客户体验等。
3.数据完整性⾼。跨业务条线旁路采集，提供⽆风险的全量交易过程数据，根据应⽤不同可以获取到设备ID、浏览器
ID、IP等信息。
4.使⽤和维护成本低。旁路部署、⽆需开发、系统架构简单易⽤，对运维⼈员的要求低。
5.快速落地。系统成熟、部署快，有⼤量成功案例，现有解码库可⽀持市⾯上绝⼤部分协议（包括⾦融⾏业的特有协
议，如⼆代⽀付、⽹银、卡交易等）。如需扩展新的数据源，可以通过镜像数据源并简单配置完成。
6.业务梳理：帮助客户梳理应⽤架构、提供业务性能指标基线，更精确地进⾏容量规划、云的规划和设计。
7.实⽤性⾼。解决传统运维⽆法满⾜的⾼可⽤、应⽤快速上线等需要的可靠捷径。
8.运维增值。不仅可以获取性能数据，帮助运维团队快速定位问题；还可将全量实时的过程业务数据输出⾄相关数据
应⽤系统，围绕运维建⽴数据⽣态，提升运维部门价值。
3.总结
探针埋点可以获取应⽤性能数据及系统资源使⽤数据，但总体使⽤和维护成本较⾼，需要⼀定的研发背景和⼈⼒投⼊。互联数据则不仅可以获取应⽤交易性能、⽹络性能数据，帮助运维团队快速定位性能问题，还可以零风险、实时、精准地获取全量业务过程数据（精确到逐笔交易的明细数据），为商业决策和业务创新提供数据依据，赋予运维团队相应的数据能⼒，帮助企业完成数字化转型；⽽且使⽤和维护成本较低，⽆需研发背景，运维⼈员可以轻松使⽤维护。基于Wire Data的天旦互联数据引擎产品是适应新时代、⾯向数字未来的APM数据获取⽅式。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。