【CAT魔改】CAT-LOCAL项目的诞生

相关项目地址：项目地址

1. 项目背景

本项目的背景是监控系统在小型技术团队始终无法实现真正的落地（这里的小型技术团队指代研发人员拢共也就五到十个人，以及虽然看似研发人员过百，但同时支撑着几十个项目，平均下来每个项目也就是三，五个人），总是有如镜花水月 —— 知道是个好东西，但受限于本身业务压力大，又无专业运维团队支撑等等诸多因素，导致始终无法落地。

本项目正是为了解决这个问题，最大化降低监控体系在小型技术团队落地的难度，让团队能够尽快感受到监控的优点，助推监控体系在团队的实际落地。

2. 技术原理

本项目直接以大众点评开源的GitHub - CAT中的cat-client-for-java作为技术基础。

直接复用CAT久经考验的日志模型，以及基于ThreadLocal的实现方式, 即不介入cat-client sdk中前期的日志收集和日志模型组装的逻辑，尽可能地站在巨人肩膀上。
主要的自定义改造点位于cat-client sdk将收集来的日志通过netty发送给服务端的那部分代码实现处，为了实现CAT的去服务端化，我们注释掉了这部分代码实现，同时引入自定义的扩展点，之后的自定义需求都基于该扩展点实现。
更多的原理和实现介绍，以及相关的演示地址等等，还请移步项目地址。

3. 项目优势

这个必须得有，哪怕编笔者也得给各位看官编几条。

关于这一点，我在半年前的【CAT魔改】独立化cat-client已经有所介绍，这里我们再陈述一遍，同时补充一些新的理解：

无额外依赖，只需要引入相关Maven依赖即可实现既有系统对于相关链路监控功能的集成，快速、高效、实际运维成本为零。这对于小型技术团队，历史项目，单体项目非常友好。
复用。站在巨人的肩膀上，CAT在大众点评的大规模应用说明cat-client收集日志的效率和完备性上是不存在问题的，相较于笔者之前设想的"参考Mybatis源码研究之ErrorContext来自己实现一个基于ThreadLocal的链路日志收集组件"，CAT无疑提供了一个极高的起步平台。
更大的灵活性。相较于CAT服务端既定的展示规则，魔改后的CAT让我们可以针对自身业务，提供更为个性化的日志收集逻辑。举个现实的例子：CAT服务端展示层的慢请求过滤时长极限值为5秒钟，但在笔者所参与的部分业务逻辑，其时间相对要长不少，这导致曾经项目组进行性能优化时，需要额外花费较多时间筛选出真正异常的请求。
与官方CAT标准版无缝对接，完美兼容一个系统从小到大的全过程。本项目弥合了小项目，大监控之间的裂缝，系统在规模逐步扩大的过程中，可在调用端无感知情况下，随时由本组件直接切换到CAT标准版，客户端无需任何改造，最大限度降低监控体系在技术团队的落地阻力。（只需要客户端将Maven依赖切换回标准版即可）。
与官方CAT标准版的对比可参见： - ProcessOn - 与官方开源版本的对比。

4. 项目展望

本项目意图：

作为大众点评开源的CAT标准版的前哨战，以最低的学习曲线吸引研发人员来使用CAT监控平台。
正如在CAT作者在看大众点评如何通过实时监控系统CAT打造7*24服务中所介绍的" 并不是所有人都能很清楚知道和接受CAT怎么用，相对资深同事更加容易接受。很多其他的公司部署了CAT，就是因为有好几个同事都是从点评离职过去，部署起来的。"，虽然CAT的依赖组件已经很少，但通过进一步降低入门门槛，吸引更多来的人来接受监控体系对于系统的必要性认知，这个重要性怎么强调都不为过。
助力系统的监控常态化，不论你这个项目规模多大，哪怕你是一个人的项目，我们也希望你能从中收益，而且按照CAT-LOCAL的设想，团队规模越小，越能从中受益，毕竟集成几乎零成本。

综上，本项目的实现方式有诸多问题，但它最大的好处是能够让原本对监控毫无概念的团队能够第一时间感觉到其好处，我们意图不惜一切代价（甚至不惜违背基本的监控理念）也要将监控的概念在技术团队推进下去，因此这个项目诞生了。

5. 补充内容

5.1 补充 - 为何监控难以落地？

究其原因主要有：

系统规模小。首先你的团队规模就决定了你这个系统也就是个用户量撑死大几千，内部人员使用的小系统，加之没有专业运维团队的支持，系统部署也是怎么简单怎么来，甚至不惜为此减少诸如Redis，Nginx，Kafka之类需要额外部署组件的使用。这个时候你要是给上一套监控系统，那每次的的部署流程中，监控反而成了最大的部署压力来源。而且系统小基本也就意味着利润低，公司老板势必要求接尽量多的项目来满足对于利润的追求。质量不够，数量来凑！所以在这类中小型软件公司中，一个团队同时负责好几个项目并不是什么新鲜事，而这势必带来更大的运维压力。
系统多地部署。一般to B / to G端用户特别注意数据的安全性，而且需求各异，这种情况下系统单独部署在客户自己服务器上基本成为了唯一的选择，而随着系统的受众增加，在没有专业运维团队支持下，研发人员势必希望系统部署更简单一些。
系统维护时间长。对于to B / G的系统，一般维护期都比较长，而且期间随着对于相关政策的变更，以及相关操作人员对于系统的熟悉，个性化的需求势必层出不断，这样系统将陷入频繁的变更中，这个时候对于兼任部署任务的研发人员来说，你别我整那些有的没的，你就告诉我部完Tomcat还要不要部署别的。
系统受众的特性。对于to B / G的系统，人们形成的共识就是界面难看，系统卡顿，反应慢，这也算是在诸多前辈的努力下为我们这些后辈打下的好基础（注意这不是反讽）。于是即使是同一个人，在操作政府网站填报信息，以及操作淘宝/京东等软件填报信息时候，表现出的容忍度是有着天壤之别的，这一点都不用证明了，各位看官应该都有切身体会。于是因为系统用户容忍性高，系统开发人员完全可以直接现场排错，生产环境当测试环境用，也没有什么生产系统不能停的说法。而且系统也就刚上线的时候不太稳定，但那时候我们人都在现场，客户就喜欢看这个，觉得这钱花得值；等之后稳定了，钱也收了，我还要你这监控干锤子？而且双方都没指望这系统能用很多年，后续的维护升级指不定啥时候，搞不好就是个一次性的系统，监控个寂寞啊？
人员能力偏低。这一点算是上面第一小点"系统规模小"的延申，小系统也就意味着较低的技术要求，意味着系统收益不会很大，这时候老板失心疯挖几个技术大牛来，开发系统那点收益都不够支付第一个月工资的。而且没有哪个大牛觉得生活太美好了，过来挑战下人生忆苦思甜吧。人员能力偏低也就造成团队很可能根本没有系统运维的概念（虽然他们都从事过相关的工作），也不知道监控对于一个在线运行的系统意味着什么？正所谓"一切的问题最终都是人的问题"，在一个对监控毫无概念的团队中推进监控体系，难度不难想象。
领导层的犹豫。小型技术团队的领导一般都是小型公司一步步熬年限上来的，他们的主要优势集中在业务的熟悉和工作经验的年限上，加之上面这些原因，所以一般客户明确要求日志审计之后，领导才会考虑让系统加上这功能，否则这一项将永远是重要但不紧急的事情，而且永远重要，永远不紧急，永远热泪盈眶。

5.2 补充 - 本项目历史

虽然直到现在才发布，但是对于CAT的研究，是自18年，基于cat2.0版本就开始了。

而且即使是本项目的原型，也是自半年前就开始实施了。（参见【CAT魔改】独立化cat-client）

本组件主打链路追踪，将请求处理相关的信息收集展示在同一个页面下，加速排错。当然正如提供的演示地址中展示的一样，也是完全支持你把日志系统里的日志全部打到CAT里来的。
关于报表统计之类的，建议切换到官方CAT，或者使用本组件提供的扩展功能，将日志存入数据库来做reports，但是不太建议将官方CAT HOME端的reports报表功能再移植过来，本组件无意取代标准版CAT。
至于告警这一块，可以使用本组件提供的扩展功能，将一些异常的SQL，请求信息记录在专门的表/文件中，定期清理，房子要经常打扫才能保证长期使用，而不是彻底脏了才想起来打扫一下，技术债务是要收利息的。

6. 感言

有同学看到"补充 - 为何监控难以落地？"可能会痛心疾首，一群目光狭隘的门外汉。但是很不巧，笔者自18年明确提出要在系统中引入监控系统至今，一直都是处于热情满满推荐，对方不置可否地冷处理，再推荐，再次冷处理的循环往复。

理想终须照进现实，"应该"是你指导自己坚持下去的原因，但绝对不是理想变成现实的理由，为了目标实现，你需要坚定你的信念，然后不断思考和尝试弥合目标和现实之间的鸿沟，面对外界的变化做出反应，找出各种办法，只为实现你的目标。

现实不符合你的预期很正常，因为这是一个真实的世界，你需要做的是改造它，而不只是在那里想这个世界应该是怎么样。如果你认为你是对的，就让它向着你认为正确的方向演进。

7. Links

ProcessOn - 与官方开源版本的对比
【CAT魔改】独立化cat-client
【CAT魔改】独立化cat-client - 扩展功能 - 前后端规范审计
【CAT魔改】扩展cat-consumer实现自定义服务端收集日志
【CAT魔改】为cat-home添加链路追踪查询
APM 介绍与实现
GitHub - CAT