背景：
随着中国互联网市场的扩大，全栈监控系统也越来越重要了，网络上介绍全栈监控的文章也是越来越多。类此种种文章一旦多了，一些相关技术也就众所周知，所以这篇文章不讲那么多技术性问题，更多的是关于对全栈监控的一些思考与建议。
关于全栈监控，很多人都知道“what is”，但是很多人都不知道“How to do”。
关于“what is”，比较宏观且有价值的介绍当属左耳朵耗子的“分布式系统关键技术：全栈监控”。由于这是付费产品，如果想了解为什么全栈监控越来越重要，可以复制关键词搜索文章，总会有那么一些文章介绍（很多参考了耗子叔的文章），在这里不做复述。全栈监控很多时候也会被说成“全链路监控”，所以如果搜索不到可以换一个关键词试试。
在这里谈谈“How to do”里面，当前市场上存在的开源的全栈监控系统，和我这些年参与全栈监控工作的一些选型与开发上的思考，以做参考。关于实现理论，现代全栈监控体系基本脱胎于Google的Dapper，相关论文参考： bigbully.github.io/Dapper-translation/
开源系统调研：
目前开源的全栈监控系统主流主要有：zipkin、HTrace、Opentracing、cat、pinpoint、skywalking、Uber Jaeger等等
zipkin：一个老牌的开源全栈监控系统，其优点就是体系庞大，各种插件多，只要你敢对他进行深入到代码层次的研究，它就能满足你的大流量系统的链路监控，客户端包含各大流行编程语言（zipkin官网客户端介绍）。其缺点最明显的，就是它致力于规范化，它的数据采集没有真正做到非侵入式，例如java的数据采集，你需要对业务项目的配置文件进行各种配置，有多少项目就得配多少次。同时，前端“简洁”得过分，如果想要更多数据与功能，二次开发是免不了的。
HTrace、Jaeger、Opentracing: 基本跟zipkin类似。HTrace和Jaeger兼容zipkin，在它的基础上封装了一层；Opentracing现在专注于给链路监控定义统一的标准规范，后来zipkin也适配了它的规范。这三个框架比起zipkin来没有优势，知名度也远不及zipkin，为了方便分析，下面的内容，对这三个框架不做介绍，以zipkin为主。
cat：美团点评开源出来的一个开源全栈监控系统，与zipkin类似。优点就是比zipkin轻量，同时经过了美团自己的流量校验。同时，对于中国用户来说，它是中文的啊！东西也就那么点，用起来还是很方便的啊！缺点也是他比较轻量，有插件，需要配置，插件涉及不到的地方还必须自己代码埋点。同时还会有各种坑需要填，毕竟美团也没有全部开源，其他人爱咋用咋用。
pinpoint：一个精于java的全栈监控系统，其优点就是java客户端非侵入式，需要的配置全都在pinpoint项目目录下，与业务项目无关，在启动参数中进行插拔式配置就行，如果有自己的自动发布系统（如：Jenkins），在发布系统中配置好就可以使用，业务开发的同学简直是躺着就能看数据。其缺点就是，项目比较小型，服务不够稳定，不适合大型大流量系统的监控；同时，前端的数据显示不够成熟，客户端插件还会有些bug。这些坑，需要二次开发自己补。存储方式用的是HBase。
skywalking：最近几年崛起的新一代全栈监控系统，基本与pinpoint类似。同样对java非侵入，同样的业务开发躺赢，同样的项目比较小型，同样的会有坑。该系统在数据上适配Opentracing规范，集群的存储方式用的是elasticsearch。
简略的了解完这些系统之后，就得思考一下几个问题：
1. 直接拿过来用，可以吗？
答：可以！！只要能忍受各种监控项缺失，各种服务不稳定，各种功能想要又没有，只要流量不大，架构不是很复杂，勉强用一下，尝一下全栈监控的好处，那是可以的。
2. 不想付出人力成本开发，又想要一个完善的且稳定的监控系统，可以吗？
答：可以！！把全栈监控交给其他团队帮你做吧！！
3. 难道就没有两全齐美的方式，既不用人，也不用钱，就能得到一套全栈监控系统吗？
答：有！！只要愿意等，等到开源全栈监控系统完善的那一天，就可以。
以上几个问题是不是很熟悉？当然熟悉了，因为就目前中国软件市场来看，差不多半斤八两。随着系统发展到一定程度，微服务大行于自身系统，各种问题暴露频繁之后，于是想到需要一套全栈监控。而就目前的各位老板思维中，监控这一块还归属于运维，就连某条也逃不脱这个“固化思维”的影响。一旦归属于运维，就容易落入一个思维误区：全栈监控市场已经成熟，轮子已经有了，只要拿来运维就行，就想省点经费。简单四个字就是：“拿来主义”。
想过以上三个问题，如果还坚持直接拿来用，那么在此推荐：pinpoint或者skywalking。因为它真的是业务开发躺赢，只要找运维搭建好服务，然后发布系统中配置好就行了。事实上，中国很多公司都是这样选择的，你并不孤单，虽然用起来难受点。反正你也没想过要付出大代价大力发展监控体系，反正你也没觉得自家公司的系统发展壮大与监控体系息息相关。
如果坚持直接拿来用，那么看到这里也就行了，下面的内容看了也是浪费时间，止步吧。还是那句话，其实你不孤单。
要做掌控者
说句大实话，笔者是真的不推荐直接拿来用的。想要发展壮大自己的系统，全栈监控系统是息息相关的，全栈监控做不好，系统一旦壮大，出了问题只能干瞪眼。
如果不直接拿来用，那该怎么用？或者干脆自己开发一套全栈监控系统？
这个问题，其实看看目前的各个大厂就知道了，包括某里，某团某评，某鹅等等，都在大力发展自己的全栈监控，甚至cat都是美团点评开源的自己的监控系统。
题外话： 要不要自己再开发一套，这其实就是个造轮子的问题(目前有轮子，只是没能满足各位老板的欲望)。说到轮子，就想到咱们要不要再造一个。想到要不要造轮子，我就想到传得沸沸扬扬的一种说法：“程序员总是喜欢造轮子”。这话甚至不下一次地从运维的同学口中说出来，更不要说各位节俭的老板，所以有必要再问一问。没办法，老板掌管着一切，问一句，想一想，给出答案，给自己一个交代，也给老板一个交代，更是给老板背后的投资人一个交代。 网络上已经存在各种各样的回答，从程序员的角度剖析：为什么程序员要重复造轮子。可是，我更想从另一个角度问一问：外界人总爱说程序员喜欢重复造轮子，对此你怎么看？在这里遇到的“外界人”已经够多了。当你以框架开发的角度去看问题时，业务开发就可以“外界人”地问你：已经有一个开源框架了，为什么还要做一个。当你以基础建设开发的角度去看问题时，运维就可以“外界人”地问你：已经有一个开源系统了，为什么还要做一个。当你以开发的角度看问题时，你的领导就可以“外界人”地问你：为什么造轮子浪费时间。层层递增，现在，连老板和投资人都听说了：我们程序员就喜欢造轮子，浪费资源。问题很尖锐，但还是得发自灵魂地问一问。 这个问题，仁者见仁，智者见智，其中有一个回答的一句话很中肯：只要是扎扎实实想要做大做强的公司，在时间资源允许的情况下，能自己造轮子就自己造轮子。与之相反，炒概念，赚快钱的公司，能用别人的轮子就用别人的轮子。 如果对这个问题有兴趣的，点一下链接看看各位大神们的回答，有想法的话也希望能写下来大家讨论：外界人总爱说程序员喜欢重复造轮子，对此你怎么看？
很残酷的现实是不是。回到全栈监控这件事，其实也是一样的问题。如果想做大做强，这轮子你是必须造的。或从0到1，或从1到2，在现有轮子的基础上封装再造。
从0到1这种大型项目，一般是大厂，或者能短期内能发展为大厂的公司才会去做。这里面的选型也就不用再说，理论也不用说，因为就目前全栈监控市场，理论性论文已经趋向成熟，把论文应用到实践中足以让你做出一个满意的全栈监控系统，需要的只是一个能做事的团队。大厂组建团队不难。
那么从1到2，就是中小型厂子比较容易接受的方式了。要从1到2，就要从目前的开源市场中选一个1出来，然后找人做（找会的人做，这里不考虑做不了的情况，不会就学，“你”弱不是“你”有理的理由）。
具体怎样选，需要根据各自不同的系统架构和偏好进行分析，然后根据条件过滤。
通过官方文档和开源源码调研，笔者发现，各个系统都有自己的优缺点，列举四个浅显的过滤条件：
- 系统的编程语言：主要用的什么编程语言，用了多少种编程语言。如果编程语言庞杂，那么pinpoint和skywalking几乎可以过滤掉了。
- 收集数据的方式：pinpoint和skywalking：非侵入式字节码增强收集。zipkin和cat：通过配置 API
- 系统稳定性，根据系统架构可以看出系统稳定性对比：zipkin > cat > (pinpoinit ≈ skywalking)
- 系统轻重程度，与系统稳定性成正比，由重到轻依次是：zipkin > cat > (pinpoinit ≈ skywalking)
PS：所谓的系统轻重，是相对而言的。在这里，pinpoinit和skywalking是最轻量级的了。但是对于连编译打包开源项目都困难重重的同学来说，就算这里的“最轻”也可能是他的“重量”级系统。
接下来聊点更深入点的分析：
如果系统编程语言主要以java为主，又喜欢轻量级系统，那么不妨使用pinpoint或者skywalking。虽然它们各种坑需要填，但是非侵入式字节码增强的数据采集方式，让业务开发躺赢，一美遮百丑。当然pinpoint和skywalking也尝试提供其他语言的客户端，就是不太理想。
那么，pinpoint和skywalking又该怎样选呢？
首先看客户端对业务的影响，pinpoint的客户端自己设计了一套独特的数据压缩技巧，使其数据收集对业务的性能损耗大大低于其他主流的开源框架，经笔者测试，在配置合理的情况下（有些配置是非必要项，这就是pinpoint有坑的地方），压力测试业务代码100%采样，pinpoint的客户端，CPU损耗在5%左右。skywalking的客户端使用的是常规的json数据，这样的客户端，性能损耗在12%左右。一般情况下，业务对这点差别无太大感知，但是对于一个最求极致体验的程序员来说，能压下来就压下来。然而，json的优点却是：明码可见。
然后看服务端与应用前端。存储方式，pinpoint使用的是HBase，skywalking使用的是elasticsearch。在性能上来说，理应是HBase占优。可是在搜索上，肯定elasticsearch占优。这也就导致了这两个系统存在差异：当数据大量写入，且实时查看数据时，pinpoint查看更快捷，skywalking在功能上却更多一点（比如txId搜索和path搜索等）。
最后总结就是：各有千秋。不过如果愿意改源码，这点区别都可以优化过来，pinpoint可以自己建立索引进行搜索数据，skywalking可以建立更完善的机制优化查询，就看用的人怎样用了。
无论pinpoinit和skywalking在java客户端做得多好，都逃不了一个致命的弱点，那就是客户端兼容的开发语言少。所以，一旦遇到不同开发语言应用在同一套系统的情况，这两个全栈监控就不太适合，除非自己帮开源社区做贡献开发出来。这时候，zipkin和cat就是比较好的选择了。
那么，zipkin和cat又该选择哪一套呢？
首先看客户端，zipkin不同开发语言的客户端相当多，兼容也多，详见：zipkin客户端官网( https://zipkin.io/pages/tracers_instrumentation.html)。cat的略少，详见：cat客户端github(https://github.com/dianping/cat)。
然后再看服务端，zipkin存在各种选型，灵活多样，详见：zipkin官网( https://zipkin.io/pages/extensions_choices.html)。cat的略少，详见：cat的gihub，用的是自己的算法，存储较为固定。
最后可以得出判断，zipkin是一个灵活多样的重量型的全栈监控系统，可以说已经形成了一个监控体系。而cat略轻，只能算是一个全栈监控系统。也就是说，cat的部署和架构理解都比zipkin简单。但是相对于性能来说，肯定是zipkin能扛流量。然而，只要流量没有太高，cat也已经满足（这里的太高，以美团点评的流量为参考）。如果有信心，把自身流量提升超过美团点评的，最好使用zipkin；如果没有，使用cat就比较快捷。
无论用zipkin还是cat，如果自己有那个研发条件，自己再开发一个支持java的非侵入式字节码增强的客户端，那么，pinpoint和skywalking的竞争优势将不成优势。事实上，这种兼容的客户端，已经出现，只是开发它的人没有开源而已。当然也有可能是在哪个笔者没注意的角落里。
开源市场已经有了各种不一样的轮子，可是最坑的地方就是，这些轮子会让老板您误以为自己可以躺赢。一个“不重复造轮子”就可以用起来的坑，跳不跳，是不是很纠结？
来源：
https://www.toutiao.com/i6943456167528251941/
