腾讯mini项目总结-指标监控服务重构

项目概述

本项目的背景是，当前企业内部使用的指标监控服务的方案的成本很高，无法符合用户的需求，于是需要调研并对比测试市面上比较热门的几款开源的监控方案（选择了通用的OpenTelemetry协议：Signoz，otel-collector，jaeger；uptrace不能商用），去重构原有服务，实现降本增效：减少监控服务本身的接入成本、存储成本，提高监控服务的性能。

项目目标

我们需要通过在服务中接入不同监控方案的组件，实现小而精的监控服务，最终给到企业一个测试报表，告诉他们不同的监控方案在成本与性能上的对比。

项目原先需求

个人角色

开发、测试

本人负责一种监控方案（SigNoz）的接入以及测试；
实现了OTEL Log的上报；
负责调研如何跨服务监控链路及链路关系图；
负责编写并优化监控服务代码，实现无感化接入OTEL SDK、提高可扩展性；
负责替换原项目服务中用到的kafka消息处理框架（使用Watermill-kafka Pub/Sub），并进行性能测试。

项目成果

针对原服务需求，设计了SLI，然后成功在原服务接入了两种监控方案进行指标收集和上报，对监控服务代码进行了无感化和可扩展性的优化，制作出SRE报表。
对不同的监控方案进行了测试，但因为测试经验不足、过程不规范，导致结果不可信。

项目的“开发”部分

监控对象

Venus 是负责性能事件上报的服务
Profile 是负责分析性能事件的服务

项目的“测试”部分

最后一周进行的测试流程是不规范的，结果无意义。自己也能从这个错误的过程中吸取些教训。
不规范在：

目标不清晰，使用的手段效率较低
缺少对测试的基础知识，经验不足，走过来全是坑，时间成本高

项目实施总结

小组日程

7月6日~7月13日：熟悉需要监控的服务，并针对该服务设计需监控的SLI；
7月14日~7月20日：接入需调研的监控方案的组件到服务当中，学习通用的可观测性协议：OpenTelemetry；
7月21日~7月25日：在需监控的服务中接入OpenTelemetry SDK，完成trace、metric、log的上报；
7月26日~7月29日：没提出什么需求，在导师对提交的代码review后，解决问题；了解、学习其他成员完成的任务内容。
7月30日~8月4日：调研3种监控服务的cpu、内存的可行性方案；调研如何搭建跨服务链路追踪和本服务的链路关系图。
8月5日~8月10日：没什么需求，研究了下使用到的一些第三方库的源码，解决服务运行时碰到的一些小问题。
8月11日~8月19日：完成新的扩展任务：使用新的kafka消息处理框架替换原有的框架并进行性能测试，解决过程中遇到的难点。
8月20日~8月25日：中期汇报，完成导师提的一些需求，接入腾讯云clickhouse集群。
8月26日~8月30日：OliverDing导师召集会议，安排具体的测试任务，在导师的帮助下尽力完成3种监控方案的存储、性能的测试对比。

个人在项目实施过程的优点及缺点

优点：

完成我这个开发角色应该完成的任务；
有一定的主动性，会主动研究源码或查阅资料解决问题；
积极，不管是在完成任务还是讨论问题、方案上。

缺点：

对问题的整体来龙去脉没理清楚就动手；
很长一段时间都不知道离项目的真正需求有多远，只会听安排（导致整体项目是不被自己把控）
不知道怎么样组织、驱动成员并合理分工（虽然我不是组长角色）

项目问题

本次项目是以失败告终的。项目真正的需求是在8月26日与导师开完会后，才领到的，就是“测试”“测试”“测试”！，看完我们的小组日程，很容易就总结出了项目失败的原因：

完成了对服务的指标监控后，没有立刻开展测试的工作，而是没需求了或者去完成一些扩展任务；
过多关注在本项目的“开发”上，实际应该将重心放在“测试”上（90%的时间花在开发上、10%的时间留给最终最重要的测试）。因为当初本项目招人时，提的需求看起来都是与开发有很大关联的，但需求不断再变化。改需求这个事情是能接受的，不过在“测试”领域上，真的是一点经验没有，没有花时间去学习相关的技术，导致项目最后几天内需要给出测试报表时，“一股脑盲目测试”，测试过程不合理不规范就得把结果全部推翻再重来，产生了很大的时间成本。虽然导师全力帮助我们解决一些问题，但是奈何成员们几乎都没“测试”经验，时间也非常紧急，失败便成了必然。
针对于本项目组8个人在这50多天完成的成果，先不谈成功与否，我和组长都觉得我们只需3、4个人即可完成到相同的程度（暂且不谈离真正的需求差多远）。这里我想表达的是：项目任务安排和成员分工这两个环节是出现了问题的。

总结沉淀

本人经过此项目后，熟悉了几套监控方案的部署，积累了一些方法和经验，比如：

如何通过搭建跨服务链路追踪，对多个服务进行监控；
在完成监控服务无感化接入的任务时学习到：如何优化代码，减少对原服务的代码侵入，提高了对代码的可扩展性的关注；
解决问题的方式：多利用搜索引擎，遇到问题先看官方文档和FAQ，不要“闭门造轮子”，多去参考官方的示例，避免增加时间成本，重复造轮子。

体会与收获

项目学习的新知识
- 通用的可观测性协议：OpenTelemetry和一些实现的方案及组件：Signoz、otel-collector、jaeger、prometheus、grafana
- 分布式监控链路追踪系统的搭建；
- 熟悉了Go语言（goroutine、test、benchmark）和一些服务中使用到的开发框架和中间件：fiber、viper、kafka、cobra、zap、watermill-Kafka Pub/Sub等等。
- 监控cpu、内存等的方式：Pprof、cAdvisor、docker stats
- 对clickhouse有更多的认识，比如：shard、replica（https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/replication ）
代办
- 课余时间去阅读Google的SRE，本项目涉及到其中的一部分：Monitoring，目前我对整体SRE还是没一个清晰的概念。之后我需要能够用一句话去总结SRE到底是什么
参与此课程的感想与建议
对于本次项目失败的结果，我最大的感受是非常非常非常地惋惜！首先是我们组是最多人的（8个），但是做出这种成果，我对8个人消耗的时间成本感到不能接受（虽然只有3、4个人是主力）
虽然项目没完成真正的需求，项目体量是比以前自己的做过的项目大，收获也非常多，与组员一起加班赶工的日子也是累并快乐着！