pinpoint 在点我达的应用

李栋

随着公司技术架构的扩张,分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用,这些组件共同构成了繁杂的分布式网络,DaPoint可以很好的解决组件间调用链路追踪的问题,其基于java agent技术,基本对应用零侵入零耦合。

微服务是一把双刃剑,虽然系统解耦开发方便,但是随着服务数量的增多,排查问题也会越来越难。

在部署全链路监控之前,如果线上出现问题,需要使用比较古老的方式,跑到生产机上面去查问题,这个过程可能耗费大量的时间。

随着服务数量越来越多,调用链越来越复杂,这个耗费的时间可能越来越长。

在有了链路监控之后,就能很好的梳理服务之间的关系,追踪请求的调用链路,定位到问题。

所以有了 DaPoint 系统。

介绍

基于 Google Dapper 论文,通过一个全局的ID将分布在各个服务节点上的同一次请求串联起来,还原原有的调用关系。

Google Dapper

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure.

WechatIMG7

通过主页可以观察到整个拓扑的实时情况。

WechatIMG8

trace 详细的调用,可以看到调用链的细节信息。响应的时间,调用细节等等。

WechatIMG9

应用运行情况监控。

系统架构

Main

应用系统依赖一个探针组件,对应用来说是完全透明的,不需要去做任何的编程,基于 java agent 技术,只需要添加一些简单的 jvm 参数即可接入,之后会输出标准的日志。支持应用重启接入和热动态接入两种方式。

-Ddapoint.agentId=app
-Ddapoint.applicationName=app
-Ddapoint.log=/log
-javaagent:agent.jar 

日志数据首先会落到应用系统的磁盘上面,之后通过 filebeat 进行采集,推到 Kafka 集群里面。

之后会通过 storm 集群进行处理落库,这里有两条落库路线。

之前是将数据都写到 HBase 里。HBase 写入很快,通过 rowkey 查询也很快。但是如果做一些比较复杂的查询,HBase 不支持二级索引,必须自己在它之上构建二级索引。

原来在 HBase 中设计了索引表,但在发现这样不是很灵活,表设计也比较复杂,需要冗余很多数据。所以后来使用了 ElasticSearch,来支持复杂搜索。日志数据在 storm 处理后,一条路是直接送到 ElasticSearch 里建索引,另外一条路是调用链日志和其他数据直接落库到 HBase。

在 trace 查询的时候,首先到 ES 里根据查询条件定位到 trace id,然后通过 trace id 到 HBase 里把所有的相关请求拉出来。

基于 pinpoint 的改造

添加打印日志的输出方式

原有的方式是 agent 通过 TCP/UDP 将数据发送到一个 collector 集群,这样的方式不是很灵活。如果接收端地址变更,agent 端应用需要全部重启,接收端如果数据处理逻辑修改,也不易升级,而且如果处理程序挂掉,也无法消费之前的数据。

修改为打印日志并由 storm 处理后,避免了上述问题,也更易拓展。

agent 端

添加热加载功能,实现不重启应用来动态加载 agent 的目的。

添加更加详细的 jvm 监控指标。

界面

原有界面无法对 trace 进行过滤查找,只能通过散点图进行框选查看。所以添加了一个 trace 查询界面。

等等...

之后

Agent 配置中心,进行统一的配置管理。Agent 插件热加载。

界面的重构升级。

应用监控报警。

数据多维度聚合。