pinpoint与zipkin的比较
经过本周部署和测试pinpoint监控平台的工作,我对这套开源系统有了更进一步的认识。
初次见到pinpoint这套系统时,我被它各方面优秀的特征所折服:无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面和告警系统,再加上开课啦事业部的使用背书。对我们来说可以说是一套完美的解决方案。
但是,经过对它的仔细研究和实际落地测试后发现。现实往往没有想象的那么美好,pinpoint这套监控系统,还是有一些短板的。就拿它和Spring Cloud Sleuth + Zipkin这套解决方案做对比:
对比点 |
Zipkin(Z) |
Pinpoint(P) |
说明 |
技术性 |
|
√ |
Z依赖于spring框架的API支持,监控内容有限 P采用字节码注入,监控程度更深,范围更广 |
接入成本 |
|
√ |
Z需要对应用改造,加入配置和依赖框架 P只需要在服务器打下探针,上层业务不需要动 |
扩展性 |
√ |
|
Z使用http和json这种轻量级协议,比起P使用探针和Thrift传输协议。更易于扩展和集成第三方接口 |
兼容性 |
√ |
|
Z对spring cloud的支持更好。Z是大公司(Twitter)出品,社区活跃度也更高,插件也更多 |
产品 |
|
√ |
从产品角度讲,P无论是从UI界面,还是功能点上都更好,是款更成熟的产品 |
性能 |
√ |
|
由于监控策略的不同,Z更加支持自定义采样策略,而P更倾向于全量采集。因此,虽然P的系统设计对性能优化的更好,但是对服务器的压力,还是P更高 |
总结
从短期目标来看,Pinpoint 确实具有压倒性的优势:无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。但是长远来看,学习 Pinpoint 的开发接口,以及未来为不同的框架实现接口的成本都还是个未知数。相反,掌握 Zipkin 就相对容易,而且 Zipkin 的社区更加强大,更有可能在未来开发出更多的接口。在最坏的情况下,我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码,而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候,Pinpoint 官方提供的报表是否能满足要求也不好说,增加新的报表也会带来不可以预测的工作难度和工作量。