共计 6404 个字符,预计需要花费 17 分钟才能阅读完成。
1. Pinpoint 概述
Pinpoint 是一个由韩国人编写的为大型分布式系统服务的链路跟踪平台,并提供大量链路跟踪数据分析汇总解决方案。自 2012 年 7 月开始开发,与 2015 年 1 月做为一个开源我的项目推出。(理解源码可 + 求求: 1791743380)
2. Pinpoint 次要个性
- 分布式事务跟踪,跟踪跨分布式应用的音讯。
- 自动检测利用拓扑,帮忙你搞清楚利用的架构。
- 程度扩大以便反对大规模服务器集群。
- 提供代码级别的可见性以便轻松定位失败点和瓶颈。
- 应用字节码加强技术,增加新性能而无需批改代码。
3. Pinpoint 劣势
- 无入侵:采纳字节码加强技术,新增性能无需批改代码。
- 性能高:对性能的影响十分小(资源使用量最小仅减少 3%),异步数据传输,采纳 UDP 协定让出网络连接优先级。
4. Pinpoint 架构简介
先看一下官网提供的架构图,如图:
[
](https://simple-spring-cloud-b…
Pinpoint 次要蕴含了 4 个组件:
- Pinpoint Agent:探针,附加到用于剖析的 Java 服务
- Pinpoint Collector:数据收集组件,部署在 Web 容器上
- Pinpoint Web UI:数据展现组件,部署在 Web 容器上
- HBase Storage:数据存储组件
架构图从上往下看,首先是通过 Agent 组件收集须要的数据,通过 UPD/TCP 的形式将数据发送给 Collector,由 Collector 将数据分析整顿过后存入 HBase,通过 Web UI 组件将剖析好的数据从 HBase 中读出,展现在现代化的 UI 界面上。
5. Pinpoint 数据结构简介
Pinpoint 中,外围数据结构由 Span, Trace, 和 TraceId 组成。
- Span: RPC (近程过程调用 /remote procedure call)跟踪的根本单元; 当一个 RPC 调用达到时批示工作曾经解决实现并蕴含跟踪数据。为了确保代码级别的可见性,Span 领有带 SpanEvent 标签的子结构作为数据结构。每个 Span 蕴含一个 TraceId。
- Trace: 多个 Span 的汇合; 由关联的 RPC (Spans)组成. 在同一个 trace 中的 span 共享雷同的 TransactionId。Trace 通过 SpanId 和 ParentSpanId 整顿为继承树结构.
-
TraceId: 由 TransactionId, SpanId, 和 ParentSpanId 组成的 key 的汇合. TransactionId 指明音讯 ID,而 SpanId 和 ParentSpanId 示意 RPC 的父 - 子关系。
- TransactionId (TxId): 在分布式系统间单个事务发送 / 接管的音讯的 ID; 必须跨整个服务器集群做到全局惟一.
- SpanId: 当收到 RPC 音讯时解决的工作的 ID; 在 RPC 申请达到节点时生成。
- ParentSpanId (pSpanId): 发动 RPC 调用的父 span 的 SpanId. 如果节点是事务的终点,这里将没有父 span – 对于这种状况,应用值 - 1 来示意这个 span 是事务的根 span。
6. Pinpoint 版本依赖
- Pinpoint 所须要的 Java 版本兼容:
PinpointVersionAgentCollectorWeb
1.0.x 6-8 6-8 6-8
1.1.x 6-8 7-8 7-8
1.5.x 6-8 7-8 7-8
1.6.x 6-8 7-8 7-8
1.7.x 6-8 8 8
1.8.0 6-10 8 8
1.8.1+ 6-11 8 8
- HBase 所须要的版本兼容
Pinpoint VersionHBase 0.94.xHBase 0.98.xHBase 1.0.xHBase 1.2.xHBase 2.0.x
1.0.x yes no no no no
1.1.x no not tested yes not tested no
1.5.x no not tested yes not tested no
1.6.x no not tested not tested yes no
1.7.x no not tested not tested yes no
1.8.x no not tested not tested yes no
PinpointVersionHBase0.94.xHBase0.98.xHBase1.0.xHBase1.2.x
HBase2.0.x
- Agent – Collector 所须要的版本兼容
Agent VersionCollector 1.0.xCollector 1.1.xCollector 1.5.xCollector 1.6.xCollector 1.7.xCollector 1.8.x
1.0.x yes yes yes yes yes yes
1.1.xnot tested yes yes yes yes yes
1.5.x no no yes yes yes yes
1.6.x no no not tested yes yes yes
1.7.xno no no no yes yes
1.8.x no no no no no yes
Agent Version Collector 1.0.xCollector 1.1.xCollector 1.5.xCollector 1.6.xCollector 1.7.xCollector 1.8.x
- Flink 所须要的版本兼容
Pinpoint Versionflink 1.3.Xflink 1.4.Xflink 1.5.Xflink 1.6.Xflink 1.7.XPinpoint Version
1.7.x yes yes no no no 1.7.x
1.8.x yes yes no no no 1.8.x
1.9.x yes yes yes yes yes1.9.x
Pinpoint Version flink 1.3.Xflink 1.4.Xflink 1.5.Xflink 1.6.Xflink 1.7.XPinpoint Version
1.7.x yes yes no no no 1.7.x
1.8.x yes yes no no no 1.8.x
1.9.x yes yes yes yes yes 1.9.x
7. Spring Cloud 与 Pinpoint 实战
在介绍实战之前,咱们先介绍一下 Pinpoint 部署构建。
笔者构建的一些前置条件:
java:1.8
CentOS:7.6
- HBase 部署
存储形式须要应用 HBase1.2.x 的版本,笔者这里抉择的是 HBase1.2.6,下载地址为 Apache 官网,举荐应用有端点续传性能的下载器下载(切实是有点慢),HBase 全版本下载地址:http://archive.apache.org/dist/hbase/,各位读者抉择本人喜爱的版本下载。
下载实现后,将 HBase1.2.6 放入 CentOS 的 opt 目录中,执行如下命令:
tar -xvzf hbase-1.2.6-bin.tar.gz
mv hbase-1.2.6/ /data/service/hbase/
批改 hbase 中 config 目录中的 JAVA_HOME,将这里的 JAVA_HOME 批改为本人本地的门路,笔者这里批改如下:
export JAVA_HOME=/opt/jdk1.8.0_221
批改实现后就能够进入 hbase 的 bin 目录,启动 hbase 了,执行如下语句:
./start-hbase.sh
启动胜利后,能够执行 jps,如果看到有 HMaster,可有证实启动胜利,如下:
19263 HMaster
也能够关上浏览器拜访:http://ip:16010/master-status,后果如图:
](https://simple-spring-cloud-b…
接下来咱们先把 Pinpoint 的 HBase 的构建脚本导入,进入 HBase 的 bin 目录下执行如下语句:
./hbase shell /opt/hbase-create.hbase
数据导入胜利咱们在 HBase 的 UI 界面上能够看到,如图:
](https://simple-spring-cloud-b…
前面的目录是笔者用来寄存 HBase 初始化脚本的门路,各位读者可依据状况自行替换,至此,HBase 环境筹备实现,接下来开始部署 Collector 和 Web UI。
- Collector 和 Web UI 部署
出于简略不便思考,不举荐初学者自行编译代码进行部署,能够间接应用官网提供的发行版本进行部署。
浏览器拜访链接:https://github.com/naver/pinpoint/releases/,间接下载以后最新 Release 版本即可,笔者当初看到的最新版本是 1.8.4,如图,须要下载的内容有 pinpoint-agent-1.8.4.tar.gz
、pinpoint-collector-1.8.4.war
和pinpoint-web-1.8.4.war
。
https://simple-spring-cloud-b…
首先须要筹备两个 tomcat,笔者这里下载的 tomcat8,解压两份后并重命名为 apache-tomcat-pinpoint-collector
和apache-tomcat-pinpoint-web
。
将 apache-tomcat-pinpoint-collector
中的 config 中的 server.xml 进行批改。
将 8005 改成 18005,8080 改成 18080,8443 改为 18443,8009 改为 18009。
同样也将 apache-tomcat-pinpoint-web
中的 config 中的 server.xml 进行批改。
将 8005 改成 28005,8080 改成 28080,8443 改为 28443,8009 改为 28009。
将 apache-tomcat-pinpoint-collector
中的 webapp/ROOT
清空,将 pinpoint-collector-1.8.4.war
放入并解压。解压实现后就能够进入 bin 目录应用 ./startup.sh
启动 tomcat 了,并且应用命令 tail -f ../logs/catalina.out
察看启动日志是否启动胜利。
同样,将 apache-tomcat-pinpoint-web
中的 webapp/ROOT
清空,将 pinpoint-web-1.8.4.war
放入并解压。解压实现后就能够进入 bin 目录应用 ./startup.sh
启动 tomcat 了,并且应用命令 tail -f ../logs/catalina.out
察看启动日志是否启动胜利。
当 Collector 和 Web UI 都启动胜利后,就能够应用关上浏览器拜访:http://ip:28080/#/main,首次拜访如图:
](https://simple-spring-cloud-b…
- Agent 启用
实战案例,本实战案例和上一篇实战案例保持一致,同样是 4 个服务,包含 Zuul-Service、Eureka-Service、Consumer-Service 和 Provider-Service。
接入形式和上一篇的 Skywalking 是统一的,都是应用探针技术接入应用程序,java -jar 的形式来加载 Agent 探针。
首先在工程的跟目录中执行 mvn install
,而后在 CentOS 的 opt 中新建 4 个目录,别离寄存 4 个打好包的工程。笔者这里创立的 4 个目录别离为/opt/project/consumer_service
,/opt/project/eureka_service
,/opt/project/provider_service
和/opt/project/zuul_service
,将 4 个 jar 包别离放入对应的目录中,并解压方才咱们下载好的 pinpoint-agent-1.8.4.tar.gz
探针,咱们将解压后的探针放在 /opt 的目录中,接下来,咱们应用如下命令,依次启动 4 个 jar 包:
java -javaagent:/opt/pinpoint-bootstrap-1.8.4.jar -Dpinpoint.agentId=consumer-service -Dpinpoint.applicationName=consumer-server -jar /opt/project/consumer_service/consumer-0.0.1-SNAPSHOT.jar
java -javaagent:/opt/pinpoint-bootstrap-1.8.4.jar -Dpinpoint.agentId=eureka-service -Dpinpoint.applicationName=eureka-server -jar /opt/project/eureka_service/eureka-0.0.1-SNAPSHOT.jar
java -javaagent:/opt/pinpoint-bootstrap-1.8.4.jar -Dpinpoint.agentId=provider-service -Dpinpoint.applicationName=provider-server -jar /opt/project/provider_service/provider-0.0.1-SNAPSHOT.jar
java -javaagent:/opt/pinpoint-bootstrap-1.8.4.jar -Dpinpoint.agentId=zuul-service -Dpinpoint.applicationName=zuul-server -jar /opt/project/zuul_service/zuul-0.0.1-SNAPSHOT.jar
上述命令执行实现之后,再关上 Web UI 查看显示状况。
首先关上浏览器拜访:http://192.168.44.129:8080/client/hello?name=spring](http://192.168.44.129:8080/client/hello?name=spring),页面失常显示 Hello, name is spring,查看 Pinpoint 的 Web UI,如图:
](https://simple-spring-cloud-b…
图分明的显示了咱们以后零碎的拓扑构造,横线下面的数字代表了调用次数,左边局部,最下面显示的是胜利和失败的状况,两头局部显示的是响应工夫,上面显示的是加载所应用的工夫。
查看器(Inspector):这里已 Zuul-Service 为例,Timeline 显示的是申请的时间段,Information 显示的是节点的一些以后信息,蕴含 Application Name、Agent Id、Agent 版本、JVM 信息、开始工夫等。
Heap 信息的应用状况,如图:
](https://simple-spring-cloud-b…
零碎 CPU、流动线程、响应工夫等信息如图:
](https://simple-spring-cloud-b…
更多 Pinpoint 的信息,读者能够通过官网 Demo(http://125.209.240.10:10123/#/main)或者自行构建试验来查看后果,这里不再一一赘述。至此,Spring Cloud 和 Pinpoint 的应用介绍也就实现了。更多无关 Pinpoint 的信息各位读者能够返回 Github 的官网进行查阅,地址为:https://github.com/naver/pinpoint。
8. 小结
这里总结一下整个案例的启动程序:
- 启动 HBase
- 启动 collector
- 启动 Web-UI
- 启动 Agent(Eureka、provider、consumer、zuul
- 利用调用
- 拜访 Web-UI 查看统计信息
同 Skywalking 一样,以上启动程序供各位读者参考,请各位读者最好依照以上程序启动,因为不同的组件之前其实是有相互依赖关系的,如果随便更改启动程序可能会造成某些未知问题。至此,Spring Cloud 和 APM 的相干操作就告一段落了。APM 能够很好的帮咱们了解零碎行为,也是剖析零碎性能的工具,更是产生问题故障的时候利器,能够帮咱们疾速的定位查找问题。