链路追踪(pinpoint)-部署使用
背景
随着项目微服务的进行,微服务数量逐渐增加,服务间的调用也越来越复杂,我们急切需要一个APM工具帮我们监控各个服务的性能及对服务间的调用进行跟踪,而通过调研多个开源APM工具后,最终我们选择了pintpoint:
pinpoint是基于java开发的,利于项目后期对源代码的修改
集成pinpoint不需要修改一行代码
pinpoint有非常直观的UI,符合项目的当前需求
pinpoint的社区还是挺活跃,一般提问题第二天就有项目的committer回复
简介
Pinpoint是一个开源的 APM (Application Performance Management/应用性能管理)工具,用于基于java的大规模分布式系统。在使用上力图简单高效,通过在启动时安装agent,不需要修改哪怕一行代码,最小化性能损失(3%)。
通过源码你也能发现,pinpoint包含3个主要的组件:
Collector, 收集应用中agent发送的数据并存储到Hbase中
Agent, 是和应用一起启动的和应用共享JVM,定时发送数据给Collector
Web UI, 从hbase中读取数据并展示给用户,之后会有demo展示其功能
支持的模块
JDK 6+
Tomcat 6/7/8, Jetty 8/9
Spring, Spring Boot
Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
Thrift Client, Thrift Service
MySQL, Oracle, MSSQL, CUBRID, DBCP, POSTGRESQL
Arcus, Memcached, Redis
iBATIS, MyBatis
gson, Jackson, Json Lib
log4j, Logback
分布式追踪原理
pinpoint的实现是基于Google Dapper论文,Google dapper提出了一个简单的解决方案来解决分布式追踪的问题。这个解决方案通过在发送消息时添加应用级别的标签作为消息之间的关联。例如,在HTTP请求中的HTTP header中为消息添加一个标签信息并使用这个标签跟踪消息。
如下图所示,在微服务之间的一次请求过程,请求经过的每个节点时都会生成一组TxId,SpanId,pSpanId并发送到collector中,TxId体现了三次不同的RPC作为单个事务被相互关联,同时Pinpoint可以通过SpanId,pSpanId发现关联的n个Span,并将这n个span排列为继承树结构。
实战集成打包
项目使用的是pinpoint 1.6.2, 官网已经有更新了,目前功能够用,不打算更新。
在打包之前你需要将jdk6,jdk7,jdk8在要打包的机器上装好,通过下面3个命令export出来,也不知道为什么打包这个需要装3个版本的jdk, 确实有点反人类。
export JAVA_8_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home
export JAVA_6_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
export JAVA_7_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home
github中clone下来,打开agent/src/main/resourse-local/pinpoint.config,resource-release下的文件也是一样
profiler.collector.ip=collector部署的机器ip
profiler.sampling.rate=10 ## 按照10%概率抽样
打开web/src/main/resources/hbase.properties, 修改hbase的连接地址:
hbase.client.host=hbase地址
hbase.client.port=hbase端口
打开collector/src/main/resources/hbase.properties, 修改hbase的连接地址:
hbase.client.host=hbase地址
hbase.client.port=hbase端口
在主目录下输入mvn package -DskipTests=true打包, 会生成下面3个重要的文件,留好它们后面需要用
web/target/pinpoint-web-1.6.2.war
collector/target/pinpoint-collector-1.6.2.war
agent/target/pinpoint-agent-1.6.2.tar.gz
部署collector和web
下载最新的tomcat,解压缩将上面的war包部署到webapps目录下,如下是部署的例子,其中
portal部署文件: ROOT.war, 这个是由build打包过程中的web/target/pinpoint-web-1.6.2.war重命名而来
collector部署文件:collector.war这个是由build打包过程中的collector/target/pinpoint-collector-1.6.2.war重命名而来
启动tomcat, 检查一下tomcat的log没有错误.
访问tomcat的地址,如果部署正常,则能看见UI,只是目前没有数据部署agent
由于项目是springboot开发,采用内嵌的tomcat容器,打成jar包后,启动的时候采用如下脚本:
export APPLICATION_NAME=TEST
tar xvf pinpoint-agent.tar.gz
exec java -jar -Xms768m -Xmx768m -javaagent:./pinpoint-bootstrap-1.6.2.jar -Dspring.profiles.active=dev -Dpinpoint.agentId=myvm -Dpinpoint.applicationName=$APPLICATION_NAME xxx.jar
启动后再刷新一下web ui的界面,会发现已经有一个应用的数据显示的。
优缺点总结
优点:
使用字节码增强使得pinpoint不需要现有代码的修改,可以随时切换。
直观的图形化的界面,支持分布式的集群监控,能够对同一个服务不同instance同时记录。
提供报警机制,可以自由定制。
可开发插件定制需要的指标,例如rabbitmq插件。
缺点:
字节码增强技术让应用容易造成风险。如果问题发生在pinpoint中,它会影响应用。
文档目前比较少,社区还没有很活跃。