有点标题党，真展开说太大了，争取就事论事糊弄完事…

缘起

  • 参加了个ARTS打卡群，第一期的ARTS最终在这里
  • 真不知道第一个share到底写个啥
  • 碰到线上故障
  • 和一起排查的兄弟推断是metricbeat的一个deployment形式部署的实例引起的
  • 我看了一眼k8s里面的配置，发现deployment和daemonset两种用的同一个镜像
  • 遂有下文

  • 当然还有为了完成打卡

    分析

    先记录我的观点，但其实是一个疑问的起点吧

  • 其实算是第一感觉，基于监控目的的不同，可以算是两个不同功能的东西，那么为什么不是两个构件呢？

    探究

  • 我首先找到了源码工程，找一个特定的分支来看吧

  • 直接进入证据阶段，这里是关于上面引文关于k8s中，metricbeat部署形式的目录
  • 翻两个源码，比如：
    • node的——这个按上面说的应该算是节点上的吧，daemonset方式面对的场景
    • apiserver的——这个应该算是整个集群中一个状态那种把，deployment方式面对的场景

  • 看到都import了至少同一个包，github.com/elastic/beats/v7/metricbeat/mb

    关于metricbeat现状的结论

  • 这个就相对容易推断最原初的动机了

  • 首先不光是这两类我认为不同的功能，连这metricbeat整个的功能代码，都是beat家族整体目录下的，在一起管理源码，所以一起出包，但是理由不充分，人家filebeat也在一起就分别出包了啊
  • 接下来是前面特别记录的，import同一个依赖，也不充分，看起来libbeat包是大家都依赖的啊，那为什么有的分filebeat，有的分为metricbeat呢

  • 那么只能有一个解释了，其实算是两点吧：

    • 这两类功能还不足以各自独立门户
    • 从发布管理的角度，合并在一起的管理成本更低

      结论

      或者应该叫观点？share不说是要观点么，怎么描述呢：

  • 我的观点是我理解了metricbeat为什么两类部署用同一个二进制包的原因了，但是不认同，为什么呢？

  • 依赖外部形态的特点不足以说明这两类部署目的形式上就要被给予足够关注

    • 简单的说吧，不是一眼就能明白针对两个目的就得部署两套东西
    • 结果就是它文档里就得特别说么，而文档如何被有效阅读呢？我觉得得有直观的东西去引导你，不同的部署二进制包，是一个足够强劲的提示力量

      其他

      还有刚才零零碎碎想到的一些东西，但是不去展开了

  • 首先观点不一定是对的，就是一家之言么，还好我感觉我挑的这个主题，这个例子，也无所谓对错，所以安心睡去，不去瞎争辩个啥

  • 我的技术背景怎么也还是算是后端java开发吧，当然我其实也算是做过前端coding的人
    • 微服务关联到篇可以被称党的标题上的
    • 从我们自己的实践的角度来说，我目前是支持一开始尽量别拆的太碎了，没好处
    • golang这个工程我没试，golang我也不懂，我觉得特别的打出两个包来也不是难事，这种代码工程组织架构的形式，应该是每一个工程，或者维护工程的人可以学习的
    • java，就是maven的多模块儿？似乎不太好用
    • java9开始的多模块是不是能达到上述分分合合的发布的自由度，说实话我不懂，我不知道
    • 适当的重复应该不是一个太过于罪恶的事情，重复本身就是一种设计强调和表达，只要它本身是陈述式的，简洁的，否则一种引用的似的形态实在是也不是那么的干净
      • 比如刚才上面apiserver那个go源码，import一个社么prometheus的包，这，无伤大雅的也是丑，说明有些东西还是耦合了吧
  • 到此为止，完成作业为主