分布式系统已经诞生了很长时间，随着计算能力和存储价格的降低，我们见证了分布式系统大爆炸的时代，现代互联网公司规模都变得异常庞大，系统也变得越来越复杂，给监控工作带来了极大的难度：海量日志数据如何处理，服务如何追踪，如何高效定位故障缩短故障时长……

监控作为运维工作中最重要的环节，一直是运维工作者关注的话题，技术工作者关注的话题也就是我们InfoQ关注的方向，本次InfoQ记者就采访了监控领域的专家吴其敏，请他来聊一聊分布式监控系统的那些事儿。吴其敏是平安银行零售网络金融事业部首席架构师，曾在eBay工作多年，先后担任过大众点评和携程的架构负责人，同时吴其敏也是开源的实时监控系统CAT的作者。

另外，吴其敏老师将担任本届InfoQ全球运维技术大会CNUTCon的联席主席，听说有几个出品人也是吴其敏老师的学生哦～

InfoQ：大型分布式系统中常用的监控手段有哪些？

吴其敏：我理解的常用监控手段：

按监控层次分：业务监控、应用监控和基础监控等；
按监控日志来源分：基于日志文件监控、基于数据库监控和基于网络监控等；
按监控领域分：前端监控、后端监控、全链路监控、业务间监控等；
按监控目标分：系统故障监控、业务指标监控、应用性能监控、用户行为监控、安全合规监控等。

监控领域非常复杂，像开源实时分布式监控系统CAT，从监控分层看，它擅长应用监控，有一定的业务监控和基础监控能力；它是基于网络来完成日志数据的传输的，将来会支持日志文件和数据库作为数据源；它已经覆盖前后端监控能力，通过良好的实施可以做到全链路监控和业务间监控，监控的目标更是非常多样化。但CAT对监控团队的技术开发和运维能力提出了很高的挑战，一般在大型互联网公司，都设有专门的监控研发团队，基于CAT做二次开发，支持业务的多样化需求。

InfoQ：分布式系统的监控难点有哪些？如何解决？

吴其敏：太多了！以CAT为例，CAT在美团点评每天新增监控日志量有400TB以上（部分系统日志采样），在携程也早就超过300TB，在这样的数据量压力下，通常情况下的一个小问题都会被放大千倍万倍，成为一个大问题，要么是系统稳定性受到影响，要么系统吞吐量有问题，要么系统出现热点导致资源使用不平衡而浪费，要么存储系统顶不住等，最可拍的是监控出问题导致的业务问题。

CAT在设计之初就充分认识到监控领域是一个深水区，对每一方面领域问题都非常重视，对每一个新报表都经过长时间多角度的推敲认证，在编码实现时每一行核心代码都经过严格Review，最极端的情况下一个类每一行代码Review后都需要修改。

CAT具备单机开发条件，也就是说只要一台机器，一下子就可以将CAT系统启动起来，进行开发、测试和排障，开发效率极大提升，同时核心系统有大量单元测试覆盖，辅以完善的建模和代码生成工具，研发效率保持很高。

CAT可以做到监控CAT（最底层监控除外），即构建起了一个最小的应用场景，同时可以完善CAT自身能力，这一点也是非常重要的；轻量而独立的平台，是CAT的一个重要特点，很多人经常会问：Spring是现在最流行的框架，功能强大，CAT为什么不依赖它？我想说这里面有一个依赖层次问题，一般都是高层依赖低层的，不会底层要反向依赖高层的，否则会出现什么问题呢？其实这就是典型的耦合性问题，底层依赖于高层，底层的应用范围就会收到严重的约束，就像C#是一门好语言（除了PHP哈），C#要在 .NET CLR上运行，.NET有需要跑在windows上，就很容易想象.NET现在所面临的窘境了。当然 .NET core经过改造应该也是可以跑在Linux上了，但是功能还是收到很大的限制。

像CAT客户端SDK，我们刚开始的目标就是可以跑在JDK 1.6以上，各种不同的平台上，包括Spring和其他技术栈。有了这一个假设，就意味着CAT要尽可能少的依赖其他运行时组件，如果一定要依赖的话，最好也要避免与上层应用发生任何冲突，比如最基本的log和网络通讯组件netty等。但是在系统集成方面，CAT是可以与各种流行的规范、系统和组件做更好的集成的，比如标准的J2EE Web项目，只要做WAR配置一个filter即可，针对spring也可以加一个自动注册的filter等等，做这些外围的集成，挑战应该不会很大，大家也可以自己完成。

再说说数据量方面的挑战吧，如果每天有300TB的数据量，意味着正常情况下平均每秒要处理6GB的数据量（高峰时加倍，与网站业务类型有关），至少需要60块千兆网卡（1Gb）共同来完成，先不说监控数据怎么采集，就传输这么多数据到CAT系统做分析就是一个很大的挑战。有人会说，能不能做客户端先做一些预处理，比如聚合分析，或者灰度采样，或者压缩？可以，但是这可能会牺牲数据处理的多样化（有些报表会没有明细）和时效性，并且增加业务节点的计算和存储负担。传输问题最核心的是如何解决多节点间负载不均衡的问题，这个问题看似是小问题，实际上是一个涉及整个系统架构的机制问题，CAT在这方面有很多考虑，细节将来有机会再分享。

传输问题之后是就是怎么消费的问题，CAT在日志消息的序列化/反序列化效率，日志消息异步化分发和独立线程内消费，分领域分时段统计等机制（小时报表、日报表、周报表、月报表等）。CAT有一个很好的机制是可以做到在单一线程内，不强调线程安全，可以大大简化代码编写要求，降低同步问题发生的概率，保持代码良好的可读性，和运行时高效率。但是从长远发展来看，存储问题是大数据量应用永远要面对的挑战。存储不但要解决吞吐问题，不能有堆积，同时还要解决财务成本问题，关注性价比，小企业还好，大企业会特别关注这一块。CAT的存储引擎已经发展到了第六版本（V6），每一个版本都是重新设计，从头再来。V6版本从构思到编码、到整合验证上生产，历史半年之多，方方面面的挑战都很大。结果不错，它与V5引擎读写效率大幅提升，文件数大大减少（具体数字尤勇在美团点评的CAT分享中有提及）。

如果上面说的都是技术实现方面的挑战，那么CAT监控实施落地将是另一个挑战。不管是在代码中做侵入式埋点，还是通过字节码技术做无侵入埋点，监控首先要解决的是目标设定，到底要解决什么问题，关注什么指标，不管现存的还是潜在的，如果没有问题就不需要监控。如果目标明确了，第二步就可以指定方案，怎么样通过已有的机制解决，或者使用新的创造性的方法，达到目标。接下来就是方案的落地实施了，数据在哪里，需要通过什么手段拿到，通过CAT API 传递到后台分析。最后一步，就是等系统上线有结果后，需要去做验证，是不是真的达到了预期，还是目标设定需要调整。这四步可以不断迭代，直到各种监控问题都可以被解决。

InfoQ：目前国内外有哪些比较好的分布式系统监控项目？

吴其敏：国内外分布式系统监控项目应该有很多，能开源并且愿意开源的不多，最近比较常用的，国外有ELK、ZipKin和Pinpoint，国内的有CAT、SkyWalking、Open-falcon等。真正经过大公司的多场景和大流量考验的应该不多，CAT算一个吧。目前CAT在国内数百家公司有自发部署，感兴趣的开发者有上千人。最近美团点评对CAT的开源高度重视，大力投入，加上几个大中型互联网公司（如携程，平安银行、猎聘网、陆金所等）的大量应用，相信CAT将来会更加广泛应用。ELK是基于日志文件做监控的，ZipKin和Pinpoint有些功能不错，小公司用的多一点，相对比较简单，功能不是很丰富，公司做大了以后会碰到很多可扩展性方面问题。

InfoQ：分布式监控系统应该包含哪些模块？

吴其敏：一个监控系统往往包含日志采集、日志传输、日志分析、日志报表、日志存储和报表展示等关键模块，系统通过每一个模块等分工协作来共同完成。不同的产品应该有不同的侧重点和优势，CAT架构设计力求简单高效，开发简单，运维简单、高效运行。之前跟一个大厂做过一个对比，它的监控系统机器数与被监控的应用机器数比是30左右，而CAT是300。

InfoQ：为什么会想做CAT这个项目，CAT的优势在哪些方面，还有哪些地方不那么完善？

吴其敏：说起来话长，应该说是7年前（2011年末）我刚到大众点评的时候（那时候美团与点评还没有合并），本来是信心满满的，以为在eBay十多年学了一身的本领，可以大展身手的。没想到当时大众点评整个网站经常有各种各样的故障，弄得大伙不得安宁，领导们也很着急，出问题总是导亲自在现场指挥，甚至亲自到电脑上排查问题，也不乏有凑热闹者将领导围得里三层外三层，场面非常壮观（可惜当时没有拍照）。一会怀疑网络问题，一会怀疑数据库问题，一会有怀疑缓存有问题，…（此处省略一万字）。但问题终究是问题，不会因为你是领导就卖你个面子，放你一马，所以最后故障解决时长总是很长，就是故障恢复了，根因也是不清不楚的。故障过程中经常会有比较沉重冷静的工程师，突然大叫一声，我在什么机器什么日志中发现有什么样的报错，可能与故障有关。大家一听，不妨一试，做相应处理后，一会故障现象消失，故障结束。然而，怎么缩短故障时长，故障是怎么形成的，根因是怎么定位的，还有大家应该从此次故障中吸取什么样的教训，经常是不明不白的。

在这样的一种情况下，我突然意识到，原来公司最缺的是应用监控，上面的一堆问题只是缺乏好监控而导致的现象。现在大家可能知道，eBay内部有一套很好的应用监控叫CAL，据说是eBay的一大法宝。我没有参与CAL的研发，但是我是资深的用户，时不时也会给兄弟团队分享CAL的使用经验。于是我主动请缨要做监控，写下CAT第一行代码，刚开始的几个月就是我一个人，从架构师到程序员，从后端到前端，从测试到运维，全部自己搞定。

CAT的优势应该有很多，分布式集群、丰富的实时报表、全量日志采集、高可靠/高可用系统等。监控领域这么大，CAT不完善的地方肯定也是很多了，比如学习门槛高、定制难、易用性不够、与其他生态的集成度不够、对语言的支持还是不够多（虽然已经有了对C/C++、Python、golang、Node.js等语言对支持）、对异步多线程的支持力度不够、后台配置管理有待加强、与docker等云集成不够等等。这些都是将来需要与社区一起不断完善的，也欢迎大家加入到CAT的社区来。

InfoQ: 在研发CAT时有哪些印象深刻的事情？

吴其敏：还是讲一讲CAT刚开始研发时的事吧，当时大众点评已经有一个监控系统Hawk，它是基于数据库存储日志的（那时候还没有ELK），已经开发了近一年时间，基本能用，正在全面推广阶段。我加入大众点评后，听完他们介绍以后，就觉得可扩展性很有问题。于是提出要研发一套新的监控系统，画了一个好大的一个脑图（可惜那台电脑坏了，图拿不出来），跟公司相关同事介绍需求的时候，大家听得一愣一愣的，现场连一个问题也没有，我当时的感觉是：他们肯定觉得老吴在吹牛，反正架构师嘛大家都懂得，说说都是容易的。当我要求Hawk系统停止推广，一下子很多人来找我，表示各种担忧或者不解。那是时候，我就下定决心，一定要做CAT，玩意搞砸了就走人呗，反正eBay是随时欢迎我回去的。然后我就一个人默默的做设计和开发，现在想想或许这就是我作为一个人程序员最好的时光，每天都很充实。还记得那时我的领导找我吃饭时，问我要什么样的支持，我就跟领导说，给我几个月时间，甭管我做什么，怎么做，请不要打断我，就是对我最大的支持。领导同意了我的要求，后来也做到了。经过2个月的奋战，我做出了第一版CAT原型，越领导时间给领导做demo，场景是事先设计好的，也就是在应用正常运行时中做后台随便搞几个错误，看看CAT能不能精准抓到，准确告诉我错误在哪里，作为架构师这点小技能还是有的。当时演示很成功，领导当场就高兴地站起来，拍拍我的肩膀，表示支持我继续研发。在得到领导的认可和信任后，后面的进展相对来说就比较顺利了。当然也不是一帆风顺的，出现过几个小波折，也帮人背过黑锅，但总体上还算顺利。

InfoQ：云原生时代的监控有什么特点？

吴其敏：云原生时代对应用架构提出了全面的挑战，监控方面也不例外。但是本质核心的东西没有变，只是形式有不同。以docker为例，云上应用监控它的粒度比物理机和虚拟机VM都要小，以前很多系统是以IP地址来区分集群节点的，如果一个docker实例的IP地址不断地变化，会对监控有挑战；在Kubernetes的Pod中的docker实例，可能是内部IP地址，对外可见IP地址是Pod地址，这样可能会导致一些场景串不起来；另一方面，docker容器应用生命周期可能会比较短，VM上的应用是重部署，docker则是销毁重建，对监控系统可能会有一些新的影响。

InfoQ：在监控领域还关注哪些方面？

吴其敏：在监控领域我倒是比较关注Visibility，我经常打跟人比方，系统是你开发的，就像你养的小孩，并不意味着你就了解它，随时掌握它的情况。这其中有太多的可变因素可以影响系统的各种架构特性。比如环境配置问题、网络连通问题（这也是背锅侠之一）、脏数据问题、服务依赖问题、应用负载问题、机器性能问题、甚至是JVM和OS问题，这些你都是不知道的，也很难事先预测准确。这就需要将这些问题指标通过一种方式展现出来，让你很清楚它的状态。没有度量就没有改进，没有监控你就是瞎子，无的放矢。然而提升系统的Visibility是很难的，因为它是给人看的，人的要求是多变的，现在这个阶段是这样，等过了这个阶段就有更高的需求了，所以伺候好人是很难的。CAT在易用性方面是有待提高的，但现阶段CAT主要还是在打造更多的问题场景，先解决基本的温饱问题，体验好不好可以留给社区解决。

创作场景

专访 CAT 监控系统作者吴其敏：聊聊分布式系统监控那些事儿