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

项目概述

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

项目目标

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

项目原先需求

腾讯mini项目总结-指标监控服务重构_第1张图片

个人角色

开发、测试

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

项目成果

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

项目的“开发”部分

腾讯mini项目总结-指标监控服务重构_第2张图片

监控对象

  • 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种监控方案的存储、性能的测试对比。

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

  • 优点:
  1. 完成我这个开发角色应该完成的任务;
  2. 有一定的主动性,会主动研究源码或查阅资料解决问题;
  3. 积极,不管是在完成任务还是讨论问题、方案上。
  • 缺点:
  1. 对问题的整体来龙去脉没理清楚就动手;
  2. 很长一段时间都不知道离项目的真正需求有多远,只会听安排(导致整体项目是不被自己把控)
  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 )
      腾讯mini项目总结-指标监控服务重构_第3张图片
  • 代办

    • 课余时间去阅读Google的SRE,本项目涉及到其中的一部分:Monitoring,目前我对整体SRE还是没一个清晰的概念。之后我需要能够用一句话去总结SRE到底是什么
  • 参与此课程的感想与建议
    对于本次项目失败的结果,我最大的感受是非常非常非常地惋惜!首先是我们组是最多人的(8个),但是做出这种成果,我对8个人消耗的时间成本感到不能接受(虽然只有3、4个人是主力)
    虽然项目没完成真正的需求,项目体量是比以前自己的做过的项目大,收获也非常多,与组员一起加班赶工的日子也是累并快乐着!

你可能感兴趣的:(Go沉淀,opentelemetry,kafka,go,SigNoz,Jaeger,clickhouse)