中拔出溜的公司如何落地监控体系

又一项看似技术需求驱动，最终发现还是业务需求驱动的体系化建设。

1. 中拔出溜公司的特点

在传统软件行业中技术团队的发展(现状篇)中我专门针对中拔出溜公司特点进行过系统阐述。但就今天的主题，我再针对性补充一下：

1. 业务场景要求低。 这个是根因，之后介绍的一系列特点最终都能落回这一视角上。
   1.1 业务停止，系统重启，这些都不是事；而且系统基本就工作时间使用，其他时间还得被研发吐槽： 都下班了积极个毛线。
   1.2 出现了问题之后：都不要用系统了，我这日志翻看不过来（是的，研发人员都是登录服务器之后使用文本工具打开日志文件翻找原因的） —— 你想想， 只有其他操作都停止，我这边重放报错接口，错误日志的最后几条才会是我想要关注的。
   1.3 功能做出来就行，诸如系统稳定性，易操作性等非功能性需求无所谓啦。
2. CRUD研发。上述背景下，对于相应研发的要求自然不会高，技术方面会CRUD堆代码就完事了，重点是业务知识和经验。至于什么微服务化那更多是业务/标书需求，别太认真。
3. 无专业运维。就上面这个要求还要毛线的专业运维，研发和售后你们自己内部把相应职责分一下就完了。

以上背景之下，对于监控这种收益滞后的纯成本支出，肯定是能省就省：

1. 优先级严重滞后，叠加上人员认知不足，一般情况下除了日志之外没有其他系统运行时的常驻监控手段。
2. 即使日志这东西，也是"写的时候嫌麻烦，用到的那一刻才嫌少"；当时赌咒发誓，事后就是"事情都过去了，你还纠缠有意思吗"
3. 除此之外，其它的监控手段基本都被用成了事后监控，也就是接到用户反馈的问题（别问我为什么不是接到系统告警），三板斧用完发现还是没有头绪，才会病急乱投医地临时找一堆监控软件给装上。但往往是此刻问题已经发生，而最关键的"问题出现前后的监控数据"无法获取，这导致在面对一些偶发性问题时非常被动。

2. 达成共识

传统软件公司对于监控的推进，其实最重要的是取得均衡，找到那个动态变化的平衡点：

1. 一开始各方对于监控毫无概念，只是限于当前出现的棘手问题迫切希望能够通过纳入某些新鲜事物(例如监控)来缓解困境。
2. 这个时候你需要借助前期的大量积累和预演，能够在短期内帮助它们解决/至少让各方相信你的这步推进是让问题在向好的方向变化，如此在之后的合作中让对方愿意遵从你的建议做出一些改变，最终进入一个改进计划稳定迭代优化的良性发展中。（这一点不仅仅针对监控体系的落地）
3. 而这里面非常重要的一点就是你的方案不能要求对方对自身现状做出过多的调整和适应 —— 直接给出一个粗略的标准就是：这样的要求每多一条，推进成功率下降30%，起步阶段最好是对方不需要任何改动。毕竟对方直到现在都对监控投入不多，那说这一块并没有那么痛。在他们目前的认知里，当前属于极端情况，偶尔一两次可以接受。

我们的终极目标是在尽量少的团队阻力之下，以尽量低的成本，维持一个能够长期运行的监控体系，加快问题排查效率，增强系统稳定性，最终增加研发人员的工作价值感，幸福感。而这需要多方面努力，除了技术本身，团队现状，业务场景需求等等的考量更重要。

3. 推荐落地路线

3.1 理论解析

a. 监控的用途
抛开照本宣科地给出一大段监控或可观测性的基本定义，这里我更愿意给出自己对于"中拔出溜的公司"这个一限定条件下，对于监控功能的理解 —— 主要分两大块：

1. 尽快解决发现的问题。 被告知问题发生之后能够快速介入、定位、解决，实现高效排错。
   1.1 这个时间越短越好。
   1.2 这个在标准理论体系下意味着一个专有名词： MTTR (Mean Time To Repair，平均修复时间)，指系统从发生故障到维修结束之间的时间段的平均值。（这里我们暂时将系统问题发生时间和被发现时间等同）
2. 借助统计分析和专家知识挖掘系统里隐藏在海面之下的冰山。
   2.1 相较于上面的"排错已知问题"，这应该才是监控的更大价值体现。
   2.2 可惜对于业务导向的"中拔出溜公司"而言，因为项目周期等原因，对于这一块的重视基本等同于零。

b. 监控的五个层级

1. 端监控。 即客户端，例如APP，浏览器等。
2. 业务层监控。 例如QPS，每日订单量，每日注册用户数量等。
3. 应用层监控。应用监控。例如JVM，链路追踪等。（本场景下的重点）
4. 中间件监控。MQ，Mysql，redis等等。（本场景下的次重点）
5. 系统层监控。CPU，网速，磁盘IO，内存等等。（本场景下的次重点）

c. 可观测性的三支柱

1. Log。（本场景下的重点）
2. Trace。（本场景下的次重点）
3. Metrics 。 “通过查看和分析高维度和高基数数据，发现埋藏在复杂系统架构中的隐藏问题，而且不需要事先预测问题可能发生在哪里，以及问题发生的模式”

本小节接下来的部分我就给出自己多年实践后的思考总结 - 起步三板斧：

1. 从日志入手，辅助进行问题排查，以及尽力而为的Metrics。
   1.1 因为日志的普及性（相关人员即使再想偷懒，出于自身利益考虑他也得打印一些系统运行日志），所以将日志作为监控落地起步的第一阶段非常合适 —— 在不需要对方调整的情况下，先让对方看到一些好处，这会让之后的继续推进减少很多阻力。
   1.2 作为自下而上推动监控体系落地的起步阶段，你需要尽量做到一鸣惊人，为之后的进一步推进打下基础。
2. 接入traceId。
   2.1 初期只做到这一步！不要去想什么酷炫的链路图表展示，自下而上的方案推进最忌讳的就是冒进，小步前进并且持续监控改进措施执行时的相关表现。
   2.2 这一步在上一步打下的基础上推进会简单一些，一来你已经获得了基础的信任，二来这一项改动对于相关团队的工作量不高，都不会涉及业务代码的调整。
3. 纳入基础设施 / 中间件监控。对于无法稳定复现的问题，我们往往需要更多的监控信息来辅助我们的决策，这个时候就需要考虑其他层面的监控了。关于这个选择可就相当多了。在接下来的小节里再作专门介绍。

3.2 Loki + Promtail + Grafana 轻量级零侵入方案

相较于ELK的笨重，Linux-Grep命令的简陋，Loki这一套解决方案正好位于中间位置：

1. 既足够轻量；（Loki和Promtail都只是一个独立运行的exe应用&