一、主要目标
考虑接入应用性能监控主要想解决如下问题:java
- 分布式链路追踪
- 应用级别性能监控(jvm等)
- 低侵入
二、选型
方案 | cat | zipkin | pinpoint | skywalking |
---|---|---|---|---|
依赖 | Java 6 7 八、Maven 3+ MySQL 5.6 5.七、Linux 2.6+ hadoop可选 | Java 6,7,8 Maven3.2+ rabbitMQ | Java 6,7,8 maven3+ Hbase0.94+ | Java 6,7,8 maven3.0+ nodejs zookeeper elasticsearch |
实现方式 | 代码埋点(拦截器,注解,过滤器等) | 拦截请求,发送(HTTP,mq)数据至zipkin服务 | java探针,字节码加强 | java探针,字节码加强 |
存储 | mysql , hdfs | in-memory , mysql , Cassandra , Elasticsearch | HBase | elasticsearch , H2 |
jvm监控 | 不支持 | 不支持 | 支持 | 支持 |
trace查询 | 支持 | 支持 | 须要二次开发 | 支持 |
stars | 5.5k | 9.1k | 6.5k | 4k |
侵入 | 高,须要埋点 | 高,须要开发 | 低 | 低 |
部署成本 | 中 | 中 | 较高 | 低 |
基于对应用尽量的低侵入考虑,以上方案选型优先级pinpoint>skywalking>zipkin>cat。node
三、原理
基于咱们的选型,重点关注pinpoint和skywalking。mysql
3.1 google dapper 主流的分布式调用链跟踪技术大都和google dapper类似。简单介绍下dapper原理:nginx
span 基本工做单元,一次链路调用(能够是RPC,DB等没有特定的限制)建立一个span,经过一个64位ID标识它,uuid较为方便,span中还有其余的数据,例如描述信息,时间戳,key-value对的(Annotation)tag信息,parent_id等,其中parent-id能够表示span调用链路来源。 web
上图说明了span在一次大的跟踪过程当中是什么样的。Dapper记录了span名称,以及每一个span的ID和父ID,以重建在一次追踪过程当中不一样span之间的关系。若是一个span没有父ID被称为root span。全部span都挂在一个特定的跟踪上,也共用一个跟踪id。 trace 相似于 树结构的Span集合,表示一次完整的跟踪,从请求到服务器开始,服务器返回response结束,跟踪每次rpc调用的耗时,存在惟一标识trace_id。好比:你运行的分布式大数据存储一次Trace就由你的一次请求组成。 sql
每种颜色的note标注了一个span,一条链路经过TraceId惟一标识,Span标识发起的请求信息。树节点是整个架构的基本单元,而每个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。shell
总体部署结构: bootstrap
- 经过AGENT生成调用链日志。
- 经过logstash采集日志到kafka。
- kafka负责提供数据给下游消费。
- storm计算汇聚指标结果并落到es。
- storm抽取trace数据并落到es,这是为了提供比较复杂的查询。好比经过时间维度查询调用链,能够很快查询出全部符合的traceID,根据这些traceID再去 Hbase 查数据就快了。
- logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID,根据traceID查询是很快的。
3.2 pinpoint tomcat
3.3 skywalking 服务器
以上几种方案数据采集端都采用了字节码加强技术,原理以下:
在类加载的过程当中,执行main方法前,会先执行premain方法来加载各类监控插件,从而在运行时实现整个链路的监控。四、部署
下面重点介绍pinpoint部署,目前咱们线上是集群部署,总体架构以下:
机器 | 部署应用 |
---|---|
master | zookeeper,hadoop,hbase,pinpoint-collector |
node1 | zookeeper,hadoop,hbase |
node2 | zookeeper,nginx,hadoop,hbase,pinpoint-web,pinpoint-collector |
搭建pinpoint线上用了三台服务器,master、node一、node2。应用数据采集端agent-client将采集到的数据经过udp发送到部署在node2的nginx,经过负载均衡分流到两台pinpoint-collector服务器,落库经过hadoop集群master节点负载均衡到两台hbase服务器上。
4.1 编译
pinpoint编译条件比较苛刻,须要jdk6,7,8环境。
4.2 hbase
集群部署,须要先搭建hadoop集群,hbase集群。搭建完成后初始化表,执行 ./hbase shell /pinpoint-1.7.2/hbase/scripts/hbase-create.hbase,能够根据本身对历史数据的需求设置表的ttl时间。
4.3 pinpoint-web
/pinpoint-1.7.2/web/target/pinpoint-web-1.7.2.war拷贝到tomcat webapps目录下 修改tomcat目录/webapps/pinpoint-web-1.7.2/WEB-INF/classes/hbase.properties hbase配置启动
4.4 pinpoint-collector
/pinpoint-1.7.2/collector/target/pinpoint-collector-1.7.2.war拷贝到tomcat webapps目录下,修改tomcat目录/webapps/pinpoint-collector-1.7.2/WEB-INF/classes/hbase.properties和pinpoint-collector.properties配置并启动
4.5 agent
将/pinpoint-1.7.2/agent整个目录拷贝到应用服务器指定目录下修改/agent/target/pinpoint-agent-1.7.2/pinpoint.config配置业务应用启动时增长参数-javaagent:/root/agent/target/pinpoint-agent-1.7.2/pinpoint-bootstrap-1.7.2.jar -Dpinpoint.agentId=application01 -Dpinpoint.applicationName=application
具体集群部署能够参考: blog.csdn.net/yue530tomto…
须要注意: 默认配置的日志级别是DEBUG,会产生海量日志,要将其修改为INFO级别
五、功能简介
首页能看到应用的拓扑信息,接口调用的成功失败数,响应时间等。
能够查看具体的某一次请求的整个调用链路信息 能够查看jvm相关信息 针对某个慢请求,咱们能够经过pinpoint跟踪整个调用链,从而定位慢在哪里。