《观测云有观点》第一期精彩内容回顾
栏目介绍
为了让更多的新朋友们了解到「可观测」的重要性和便利性，也为了让老朋友们多一个开放交流的固定平台，更为了帮助观测云能一直走在正确的迭代方向上，观测云倾心打造《观测云有观点》互动直播栏目。观测云有观点是观测云旗下一档近距离与核心用户交流的栏目由介绍、分享和讨论三个环节组成，每个月定期更新，参与的嘉宾都将获得「观测行动官」的身份，现场参与：
为了让更多的新朋友们了解到「可观测」的重要性和便利性，也为了让老朋友们多一个开放交流的固定平台，更为了帮助观测云能一直走在正确的迭代方向上，观测云倾心打造《观测云有观点》互动直播栏目。观测云有观点是观测云旗下一档近距离与核心用户交流的栏目由介绍、分享和讨论三个环节组成，每个月定期更新，参与的嘉宾都将获得「观测行动官」的身份，现场参与：
- 近距离了解观测云最新产品迭代计划和想法；
- 与其他如您一样优秀的观测行动官们，一同分享可观测性最佳实践；
- 提出您的观点或建议，连麦交流，收获满满
直播文字实录：
开场：
各位观测行动官大家下午好!感谢大家今天参与我们观测云有观点第一期!今天到场的观测云侧的同学有我们的观测云的CEO蒋烁淼先生，研发负责人陆宏鸣先生，产品负责人曹新宇女士，以及我们的生态负责人蔡文瑜先生。那我们今天就开始今天的活动吧！各位可以随时举手连麦提问哦，那首先我们有请观测云CEO蒋烁淼先生带来观测云时间线原理以及最新功能迭代的更新介绍。
观测云时间线原理说明
蒋烁淼：
这个我们6月6号的整个更新，其中里面涉及到这个比较重要的这个数据保存策略。这件事情我想展开来说一下，就针对我们的这个更新日志来做一个说明，因为实际上这个观测云这边呢，针对这个时间线作为计费，其实是做了一个蛮大的调整。就是实际上我们在不同的客户使用过程中发现时序数据库 TSDB作为时间线它其实是非常贵的，因为我们其实发现一个现象，在无论是国内的或者国外的这种和时序相关的呢，一般都提供统一的数据保存策略，我那天和某公司的小伙伴有过一次交流，他们私有化解决这个时序保存策略呢，是通过两个集群，一个 A集群保存7天的数据，然后一个 B集群保留大概2个月的数据，用这种方式来实现一个相当于不同时间周期的数据保存策略。 然后再加上之前包括像热云科技也遇到了比方说 spot 节点它可能平时可能主机量并不大，但是可能在一瞬间，他可能会增加几百台服务器，这种这种动态的策略，我相信在云和云原生时代，实际上这种动态策略是非常常见的，所以如果采取统一的这个数据保留策略。包括我们可以看到像美国的 DataDog它其实也是统一的保留策略那么会导致非常非常贵。
这个贵体现在两个方面，一个方面就是说可能从计费计价角度来说用户会看到这个指标非常贵，指标这个这一部分的存储非常贵在我们调整之前，可以看到的这个价格可能比日志链路等等数据加起来还要多，这个显然是不太合理的。 因为指标数据相对于这个这个业务数据呢，实际上日志或者说链路的数据呢，实际上是信息密度更低的一种数据，它虽然它的数据量非常恐怖，但是它的信息密度比较低。
我们通常只能通过趋势或者周期性去判断他是不是具备有这个有价值，那其实是一个信息密度比较低的数据，那么我们为了这个信息密度比较低的数据，却要付大量的成本这样是不太合理的。那原因是什么呢？我这里做一个解释，就是我们之前也发过一个针对 InfluxDB的一个时间线的一个设计的一个原理性的文章吧，其实国内或者国外的这个时序数据库都是大同小异的，就是大家都有个时间线的概念原理上其实特别简单。 就是我们描述时序数据其实是描述在一个空间纬度上连续的数据。所以比方说你有五台主机CPU，那么每个主机可能是一个 Host Name，他的值不一样，可能是 abcde 这五台主机。 那么这五台主机产生的时间线就是5条时间线，那么如果说你要追踪每台主机中的每一个核假设都是8核的 cpu那就会变成20条时间线，这8乘以5就40条时间线，所以时间线它其实是非常多的。那么如果我们以前可能如果是单虚拟机的状况其实我们当时测算过，一台服务器的时间线可能就是在100条上下。但是今天产生那个超级变量什么变量呢？就是容器因为pod其实他其实是不断的，每次重启以后他就会生成新的时间线因为pod name一旦发生改变，他的数据记录就不在原有的那条时间线上了，而是分裂出一条新的时间线，那么这件事情在XX家的那个场景中，就更恐怖了。因为他们的这个做法基本上就是每开一个应用就产生一条时间线。这个每次就开一个应用就开一个pod，那一个pod就带来一组时间线而这个pod的生命周期，可能甚至都可能是短短的几个小时，甚至都不超过一天，那在这种非常疯狂或者说非常动态的一个 Infra 的一个一个状态下。如果时间线的存储策略是完全统一的，比方说30天那就意味着，我们我们的用户可能在为他已经不需要的数据付费，这是第一点。
第二点呢我们作为这个服务的提供方也在为不需要的数据客户不需要的数据在付出存储，尤其是内存的成本因为时间时间数据的大部分的这个索引是通过内存的，就你时间线越多意味着占用这个存储服务器的内存越多，相反数据反而是连续被压缩的，而时间线作为索引其实它会占据大量的内存，所以又导致我们内存会出现一种炸裂的情况，所以等于说我们的成本也很高，客户可能拿到的这个数据其实已经不用了的数据也在被处理。因此我们这一次的更新中呢其实带来了一个比较大的改变，我们可能未来我们最近还在思考是不是还会增加一天的这个周期，而且我们是全球唯一把这个过期策略做到表上面的。
客户提问：使用观测云是否可以跳过Datakit采集器进行数据采集？
基于私有化部署观测云，后续会考虑直接接入现有的监控系统吗？就是比如我现在的环境我已经有了一整套的Zabbix，或者是Prometheus然后我现在想要部署观测云的话我还需要重新用DataKit去采集，我可以去掉DataKit这一层吗？我们直接把我现有的数据直接推到观测云进行展示吗？
蒋烁淼回答：
这个其实理论上是可以的但我们不太建议这么做，原因是什么呢？其实我刚刚也给大家介绍了很多高级的功能，比方说智能巡检包括我们后面会支持 profiling包括我们对于这个数据的一个智能分析包，刚才说到了很多查看器为什么能够实现这个功能有个前置条件。其实 DataKit最大的作用倒不是说收集这些数据，实际上这里可能今天没有在的就是另外一个客户就是他们就是其实是直接把我们来替代普罗米修斯和 ELK的，但他们数据收集是用 filebit 就没有换成这个我们的 DataKit 去收日志而是用 filebit 把日志打到DataKit 上这种方式。然后呢把Prometheus remote right 到 DataKit 。
**(使用DataKit的必要性） **
为什么要经过 DataKit 呢？这个逻辑特别简单，其实 DataKit 在整个系统里面承担了两个角色，第一个角色其实就是数据收集这部分其实跟 Zabbix和这个 Prometheus 其实没有什么差别的，但第二个部分很重要很重要，他是做了一个数据治理。大家也知道就是实际上可观测性数据无论指标、日志、链路相对业务数据它是一个相对价值比较低的数据，但是呢它又是一个非常庞大的数据，所以对于这种数据? 如果我们做后项的ETL治理做所谓的自动化，这个成本很高比方说我把 Zabbix 的数据和Prometheus的数据就是这些开源的数据全部收集起来，但是不好意思Zabbix 数据对于一台主机的定义和Prometheus对于台主机的定义或者你用 Nagios ，或者用其他开源软件。他们的数据结构包括 Telegraf其实他们对于数据的定义都不太一样。比方说刚刚我在展示的时候在这个链路数据里面就会有一个 EMV 和 Version那这两个我们是针对他来做特殊的处理来满足 mesh 的治理的，就是各种各样的 service mesh 的这种，多版本或者多环境的一个统一的治理，但是如果说你使用比方说其他的开源方案打上来的数据不经过DataKit 那就会导致他们可能定义的版本不叫version而是 ver。那意味着我们不可能识别到ver这个字段是代表版本的，更何况如果你比方说用假设不经过datakit，把 skywalking和 Jaeger 的数据都往我们中心打，这个就会导致Skywalking 的数据结构和 Jaeger的数据结构是不一致的，那最后其实两边的链路也打不通所以一样的比方说Zabbix 。
因为他原来存储的是 Mysql通常他的数据采样频率都是以分钟级我不知道你们是多少，甚至数据量大的话我看过有些用户用5分钟一个采样点，但你想想5分钟一个采样点的 cpu 和磁盘磁盘空间还有点意义cpu 5分钟采个点或者1分钟采个点有什么意义呢？你的这个波动抖动都看不见了对吧。然后Prometheus呢又有另外一个问题，就是你想Prometheus为什么我们在官网上可以看到包括社群里面看到大量的Prometheus的用户在那边吐槽，吐槽什么呢，说为什么老OOM 对吧。Out of memory Prometheus为什么Prometheus放在集群里面把整个集群都拖慢了,其实很大原因就是那些开源的采集器他完全不考虑时间线策略的,也就是意味着如果你 Prometheus的那个时间存储策略设置特别长的时候,尤其加上 Prometheus针对这个POD name 这块还会生成一个随机的uuid，所以会导致这个时间线超级炸裂，所以就会出现你自己内建的这个那个Prometheus内建的 TSDB 的内存炸掉。那如果你后像写到victory metric 类似这样的这种扩展，那你会发现实际上你在这个上面也无法做数据治理。最后其实就要不断的扩容这样的服务器。Zabbix 是做的方法就是降精度，我相信大家都知道就是因为他囤不了那么多数据，所以他会去做这个数据的一个精度下降，但精度下降其实是导致 Zabbix其实意义不大了。
我相信很多公司用 Zabbix本身只是做了一个简单的告警，那所以说在这种大背景下会导致一个什么问题呢，就是即使打给我们我们也要做数据治理。但是因为用户实际可能的这个数据内容实在太不可控了，所以中心做数据治理这件事情几乎不成形，所以我们采用 DataKit 在做数据治理也就所有数据经过。DataKit 以后本质上在收集的过程中，其实是完成了一个治理的，其实大家看我们的这个日志收集就很明显，就是我们为什么能够实现，所有的数据串联起来就是所有的数据从日志文件中的日志被读取以后，其实不管你用 filebit读，用 Fluentd读还是直接用我们 DataKit 提供的这种文件抓取的方式去读，他都会将这些日志所在的主机所在的 Pod所在的 Container呢这些信息给关联起来,所以这种关联数据治理，就是打标这些能力是很难在这个你现有的这套体系里面，我相信你那一些客户或者一些用户，用开源的方案，因为你们在建设的那一刻肯定没有思考过这个数据关联的问题的。所以这个就意义不大了，所以如果是这种方式用不是不能用，这种方式用的一个结果就是什么呢？就是其实观测云最大的这个串联能力发挥不出来。
