EP08 AI如何颠覆可观测性工具讨论会纪要

Original AI芋圆子共识粉碎机 2024-01-18

关注共识粉碎机，获取历史讨论会纪要

详细的讨论会分享背景请见我们上一篇文章《AI如何颠覆软件：你能为AI打工吗？》。我们的可观测观点，可查阅公众号历史文章。

我们尽量每周都会组织不同领域的AI讨论会，覆盖软件行业的所有细分。为了保持一个活跃的讨论环境，对参与人群会有限制。

下一期将定于本周日（8.27）上午10点，主题为《芯片厂商如何突破英伟达垄断》，详细的下一期内容和报名形式请见文末的阅读原文。

本期讨论会参与者：

蒋烁淼Samuel，观测云CEO，驻云科技CEO，初代云计算老炮，湖畔大学第一期学员。

1 可观测性工具实现原理

最早的可观测性源于

维纳

‍‍‍1948年，维纳的控制论这本书强调：要控制一个系统的前提是对其具有可观测性。
实际上，所有的Monitor软件，如工业领域的SCADA等传统Monitor软件都基于这个原则，只是Monitor的对象不断变化，包括算力能力、infra和应用等。
传统意义上的监控软件将其理解为对计算机硬件的监控，然后到操作系统级别。程序员编写代码时，会打印一些内容方便自己调试，因此产生了Log日志。Splunk是以日志起家的。New Relic等公司的出现，重点将Log转化为结构化，称为Tracing或API，这已经实现应用级别的监控。随着移动互联网的发展，不仅需要关注服务器的代码，还要追踪端侧代码，这是随着对象的增加逐步拓展的。
详细的可观测性原理可以阅读观测云团队翻译的《可观测性工程》一书。

无监控不运维

谈到可观测性，运维领域有句名言：无监控不运维，在无法观察到的情况下，无法进行运维判断。
随着技术发展和复杂度，单一观测场景的可观测性会导致需要构建大量独立的可观测性系统。例如，Infra的Monitor，包含云原生系统的监控，数据库系统监控以及Log系统，包括不同的Log，如ERP的Log、普通应用的Log、业务的Log，以及Tracing等整套系统。
大数据本质上是从业务系统或Log系统中获取数据，甚至需要观测到业务。

可观测性的要求是从一个点看到全局

可观测性指的是将分散的数据系统统一管理，从一个点看到全方位，或者从其中一个点连接到另一个点。
在某种程度上，今天讲的可观测性有点像Monitor系统的数据中台。但与传统意义上的数据中台最大的区别在于，Monitor面向确定性场景。它并非面向零散业务，而是面向整个IT系统，甚至整个IT系统所承载的所有业务和应用，并且具备实时性要求。
无论是Log、Trace还是Infra的Metrics，仍需进行监控，因此仍需具备强大的实时性。数据规模非常庞大，可能在业务上进行操作，如购买一件衣服，购买行为在业务上就是一个订单，但围绕用户行为产生的所有机器行为和机器后面的硬件所有指标或行为，是海量数据。可观测性对业务价值看起来不显性，但存储成本等各种成本就变成了可观测性需要考虑的重要因素，如果价格过高，大家可能面临用不起的风险。
在这些能力整合后，会发现很多事情发生了变化。例如，过去很多时候仅仅是为了监控，现在将所有数据连接起来，可观测性就成为理解整个系统运行状态的有效手段，在开发、研发、用户体验，甚至业务形态优化上都能发挥很大作用。
这也是为什么大家在我们讨论群里聊DataDog时，如果将其视为传统意义上的监控系统，它可能是最晚出现的公司，相对于Splunk、New Relic和Dynatrace。实际上，无论是当时的商业模式还是产品形态，它至少在整体上领先于传统APM公司。（希望加入讨论群的请私信公众号后台发送您的从业信息和擅长的AI领域）

2 可观测性运转的关键环节

第一点：要从所有地方获取数据

Datadog的CTO接受采访时也提到了这个问题。为了保证数据的实时性，需要从所有地方获取数据。
传统意义上，监控系统仅能获取到主机的CPU、内存和磁盘信息。然而，从可观测性角度来看，不能这么简单。有可能这台主机上有一个数据库，数据库内可能还连接另一个系统，它们之间存在一连串关联。
因此，许多公司开源自建的监控工具来实现可观测性，最难的部分就在这里。实际上，这个没有太大的技术背景或技术内容，但具有很强的工程和统筹价值。需要在所有的infra上、Application上都加上主机标签，并确保主机标签完全相同，例如称为host。这样才能确定这段代码是否运行在这台主机上。因为现在微服务各方面的机器实际上可能会飘动，数据库也是如此，无论是Kafka还是Mysql，都与主机相关。
今天不仅有新的东西，还有容器等，例如，这些东西与Kplus上整个应用程序和中间件产生关联关系。这是一个复杂的统筹过程，包括Metrics、Log、Trace和Applications，所有相关字段，无论采用何种方式采集，最终都需要统一。如果不统一，就无法查询。例如，在主机层可能使用IP，但在业务层可能使用主机名，这样就无法查询到关联关系。在采集侧，第一个很大的麻烦就是这个问题。
许多开源方案实际上在这方面会出现很大问题。开源工具由不同作者编写，根据自己对整个系统的理解构建了相应的tag，这些tags各自命名不同。对于使用者来说，很多时候无法治理每个开源组件，成本一般用户无法解决。但作为我们的观测云，包括Datadog，会大规模治理这件事情，这是第一个要点。

第二点：采集性能和数据量

用户侧希望能变得简单，达到One Agent，一个探针或客户端。实际上，需要从所有业务系统上收集数据，包括Infra、Log及上层平台。传统监控软件需要安装很多探针在一台服务器上，少的有五六个，多的可十几个，收集不同数据。这些探针的管理、配置、协同和性能等方面都需要投入大量力气去完成。
国内很多开源方案的用户，除了一些偏头部公司，大部分都缺乏可观测性。因为团队内部很难有人很好地利用这些开源探针。所以只能通过较原始的方式收集他们认为必要的数据，例如收集日志和指标。
此外，由于大数据的介入，许多公司实际上收集了双份Log，一份用于问题排查，另一份用于业务大数据分析。因此，采集端存在工具分散的问题，需要有能力将这些内容整合起来。Datadog、Dynatrace都已经达到统一整合的状态。

第三点：保证实时性

不像大数据系统那样，可以再第二天查看数据。可观测性虽然精度没有要求到秒级甚至毫秒级，但数据也不能Delay在一分钟或两分钟内。因为需要对数据进行监控，包括监控一些Alert，都需要相对实时的监控。所以，实时性各方面都是需要考虑的重点。
许多开源方案。将所有数据收集到中心后，仅依靠传统方法如字符串匹配查询相关数据或简单告警设置，开源软件是够的。然而，如果要进行报表分析和关联分析，真正提升研发团队效率，需要具备收集和处理所有数据的处理、分析和治理能力，并根据数据得出更多结论和推断。使用自己开源的方法很难完成任务。
Dynatrace的DavisAI和Datadog的WatchDog在实现类似能力时，对整个存储中心的数据计算能力仍需要较高要求。因此，将可观测性所用的底层存储和计算能力概括为实时数仓能力，这是构成整体可观测性的要点。在这一点上，由于数据中台仍然是大数据平台，本质上相似，简单来说就是收集和治理数据。而存储数据和分析数据仅负责收集和治理这一环节，与传统大数据最大的区别在于它们的实时性要求较高。第二个优势是可覆盖范围相对有限，可以随着技术潮流发展。
例如，Datadog刚刚发布的llm可监控框架，实际上是将新技术的数据采集制定成一个标准化范式，使用者可以直接开箱即用。背后的数据逻辑并没有发生变化，Datadog仅进行了相应的整合，并提供了Dashboard或分析的Panel，以帮助用户理解收集到的数据，并应用这些数据，在这个层面上是相似的。
在某种程度上，我们可以收集所有业务数据，采用类似可观测性方式，效果非常好，而非仅通过N+1报表。当然，在进行离线大计算时，实时处理不太可能。但对于一些常见业务场景中的数据，实际上可以通过类似监控或观测手段实现。

3 AI将如何与可观测性软件融合

看AI能有多大的帮助取决于整体观测能力：

可观测性中一直有AIOps的概念，在过去AIOps中模型能力不是最重要的，最重要的是观测能力。
观测平台是一个精确平台，精确的前提是提供的信息要足够完整，如果仅观测到一个报错的日志送给大模型，模型出来的是精确的废话。但如果能将报错文件叠加到上下文中，精确度自然会提高。
实际上，从问题提示角度利用大模型并不像向量数据库那样使用，它更多地是构建所有文本，而文本的构成来自于系统与系统之间的连接。只有将系统与系统之间的相关性，将当前代码错误、对应主机、部署架构以及应用其他信息一并传递给大模型，给出来的答案肯定会好很多。
当然，还需要考虑大模型本身的知识储备和知识训练情况，这样才能取得较好的结果。换句话说，传统监控系统没有整合数据，甚至最后的结论都没有统一规范，去大模型侧做提示，效果实际上会非常差。
作为一个IT系统，需要利用大模型来提高自己对系统本身运行状态的理解，前置条件是先构建一整套统一的数据体系，也就是统一的观测平台。显然现阶段很多企业在这个事情上（统一的观测平台）本身就做得很差。
尤其在中国市场，在可观测性大家都没搞清楚的情况下，想要应用就更难了。观测云在这方面一直领先，已经搭建起了统一的观测平台。

具体到已有的DavisAI和WatchDog等AIOps，也取决于额整体观测能力：

Dynatrace的DavisAI和Datadog的WatchDog都是海外领先的产品，其效果好不主要来源于优秀的算法，更取决于整体的观测能力更强。
观测云的系统与上述比较类似，以观测云的系统为例，可以清楚地了解API调用失败时，API所处服务器、调用数据库以及调用的前端客户端和最终用户是谁，自然可以通过数据挖掘和机器学习，迅速得到精准答案。
因为数据从第一天就被全面组织在一起，所以无论是DavisAI还是WatchDog，效果好的原因都在于数据的统一性。
打个比方，秦始皇能够做到天下政令通横，很大原因在于车同轨、书同文。
简而言之，利用好大模型的前提是完善的可观测性。如果可观测性数据整理得好，即使使用传统的机器学习和数据挖掘，仍然可以比人肉巡检和简单阈值监控更好，且成本不高。实际上，高成本反而体现在数据治理方面。这是我观察到的一个可以沿着历史脉络延展到大模型的路径。

新的尝试是基于LLM构建Dashboard：

例如之前看到的一个Demo，是在一个BI程序里实现了通过Prompt帮自动构建Dashboard的能力。这个功能在可观测性方面非常有用。
用户有时候并不满足官方提供的Template进行观测，但如果通过一定的Prompt提示，例如需要今天的数据与昨天的数据对比，发现相关问题并展示的方式发送给模型，将其翻译成动态Template的数据结构，最后帮助用户生成理解业务场景的Dashborad。这个场景在BI上和可观测性上都有需求。可观测性常将其称为面向工程师的BI，这也是一个大模型可以整合的部分。
目前难度在于用户可能问不出专业问题，导致最后生成的图表仪表与预期偏差较大。如何有效构建这样一个产品，不仅仅是简单地提供一些完全Freestyle的Prompt，而是如何更好地引导用户完成复杂的Prompt，这有点像Mid-journey那样。简单的Prompt实际上得出的东西并不好。如何将其转化为复杂的Prompt，同时要有良好的用户体验。因为它是一个精准系统，需要的功能不像Mid-journey那样天马行空。
虽然目前我看过一些Demo，但未能看到特别好的效果，现在都是随便输入一个Prompt，然后捣鼓出三四个仪表盘，实际用途并不大。然而，如何能够相对精准、有效地利用大模型，这也是我们目前看到的可观测性能极大提升生产效率的一个部分。

4 针对AI场景搭建观测平台

针对AI的观测重点仍然是数据收集能力和Know-how：

第一部分是数据收集能力。例如，使用一个开源系统，用户自己搭建一个开源采集器来对接所有大模型，无论是推理还是训练基础设施或应用程序。但是这种开发和制作这些功能通常需要一定的时间和经验。从厂商角度来看，提供一键式的接入能力是必要的。然而，目前看到大模型方面对数据接入能力并没有特别的要求，基本上就是对于这个接口或者新的硬件的支持。
另一方面，还是偏know-how的。即拥有这些数据后，如何将其与当前场景结合，构建自己的可观测性能力。当然，无论是Datadog还是其他家，还只是提供了一些标准范式。最终，如果要做得好，用户仍需根据自己的业务场景构建或修改这些标准范式来满足业务需求。因此，这一块更多的还是传统能力的体现。
目前我没有看到任何一个厂商，无论是开源还是非开源，在大模型观测上面有特别特殊的部分，基本上都是一样的。

大模型训练阶段对观测的需求没有推理大：

无论对于推理和训练，对可观测性的需求都是自然发生的。已经在用Datadog的客户，在推理和训练环节，将整个过程中的可观测性相关数据全部整合到这里，而不需要再构建一套基础设施。使用其他新的工具，可能并不熟练。
实际上，是否大模型，可观测性没有什么区别。从事大模型训练，自然会使用这个工具监测GPU卡等训练过程。如果主要关注推理，自然也会用这个工具观测整个推理过程。可观测性工具实际上就像数据库，有时候把Splunk、Datadog等公司的工具都归为实时数仓。实际上有些客户在观测桥梁稳定性时，也在使用这样的工具进行工作。反过来看，那些单独制作大模型的可观测性的公司，其生命周期可能不会太长。他们的结局可能是被大的公司收购。
训练，数据量少，对于可观测性厂商其实赚不了什么钱（用户自己用Grafana+普罗米修斯也基本上就能解决问题），或者公有云也有自己的观测工具。
但是推理侧，尤其是应用侧情况更加复杂。例如，无论是自己运行的卡还是自己制作的模型，最后都需要分析用户如何使用这些系统，如何进行prompt和调用，以及如何应用模型。从应用视角来看，反而是普罗米修斯、Grafana、公有云做不到的。

5 可观测性产品的底层趋势

底层会走向存算分离和高性价比：

存储层非常重要，，而所有价格都反映在存储计算引擎上。从软件厂商的价格成本角度来看，例如Grafana推出了一个名为Loki的产品，它的成本很低，但所有选择都有Trade-off。Loki的问题是所有存储的日志型数据的分析模式被固定，难以进行高级分析，但它确实是一个简单的低成本方案。
如果像原来Elastic的方案，采用倒排索引方式，整个存储和计算成本会较高。现在无论是Doris还是Snowflake，也有人基于Snowflake进行可观测性。因此，最终存储方案会走向存算分离，包括列式存储。既要保证低成本，又要保证能够进行更高维度的分析计算。所以成本当然是存储考虑的一个重要因素。
同时，计算的能力和成本也是面向可观测性的一个非常重要的考量因素。厂商会一直寻找低成本、高效率的存算引擎。
最高情况下，这种寻优的成本优化可以做到原来的1/4-1/5。

实时数仓可能成为主流方案：

性价确实需要满足最基本的要求。例如，1亿条数据，查询并返回，一个更快的引擎是0.5秒返回，慢的是1.5秒，但是更快的引擎的费用是慢的的5倍。所以还是会选那个慢的，虽然速度慢，但成本是可控的。
速度并非首要因素。实时写入、稳定性、综合成本是最高优先级。此外，还有功能性方面，若有功能不满足需求，也无法解决
各个方案都有trade-off。另外，成本控制，如存算分离等。例如，数据是否能够通过对象存储持久化，而非通过SSD。因为云厂商的SSD价格非常夸张，基本上是100倍的物理卡价格。因此，如何减少SSD的使用，增加对象存储费用在整体存储中的占比，就像snowflake一样，这也是一个重要方向。
所以会发现，实际上所有的数仓，如OLAP都会找可观测性厂商来聊，原因很简单，可观测性是数仓非常重要的应用产品，且是标准化的。

6 Datadog是最好的产品，但非常贵

Datadog贵在颗粒度不够Consumption+过度消费：

Datadog贵首先来源于中美定价的不同，美国客户愿意付出溢价。例如非常多的美国公司就是标配MAC电脑，成为吸引程序员的卖点。
在Infra监控场景时，Datadog针对高峰的服务器数量收费，但企业在运行的时候高峰期不长，在大多数时候用不到这么多Server，这也使得相比创业公司，Datadog的定价颗粒度不够细，也不够Consumption Model。
在APM和Log场景时，针对Metric的选择上，多选择项目就可能出现成倍的账单增加，客户也缺乏对优化Metric的方法论。同时，例如死循环也会使得Log不断输出，Datadog后来做出了一些针对死循环的优化，但仍然解决不了全部问题。
对于Datadog的商业模式，规模越大边际成本越低，但是边际成本的变化没有传递给客户的成本节约。现在更多是通过大客户Discount来变相降低价格。
同时因为过度消费等问题，目前FinOps的不少创业公司也开始进入Datadog生态，旨在帮助客户节约账单。Datadog账单中的付费项目超过100项，绝大多数客户无法理解其中的每个项目怎么具体收费的。

相比其他商业观测公司，Datadog也不都贵：

对于Dynatrace，Dynatrace在很多传统公司上提供了更多的技术支持，价格也会更贵。
对于New Relic，主要是定价模式的不同。New Relic的定价模型过去根据数据量和安装的探针数量来收取费用，现在变成按坐席和数据量。但实际上我们计算过，New Relic并不一定比原来便宜，而且这导致了一个错误的引导。我们公司只需要两个人使用New Relic这个产品，就付两个人的钱。虽然这种方式在流量上定价比较DDOG便宜，但打破了一个规则，即这个平台并非让公司所有人使用，而是变成一个运维工具。New Relic的功能偏向于运维，而非产品研发团队获得。Datadog完全按照数据量，按客户数据规模收费。
所以会出现一个现象：当业务较小时，New Relic与比Datadog相比较便宜，情况是公司人少，但是数据量超级大，New Relic按人头收费就花费比较少。但是如果一般公司，人头比较多，但是数据量大，那使用New Relic就非常贵。各家公司都有不同的计费模式，但无论哪种模式，可能对于一类客户来说，都算贵的。

DDOG未来不会降价，会采用折扣+扩品类：

Datadog不会对整个市场降价，而是对超大型客户提供特殊折扣。对于中腰部客户来说，这是他们的绝对收入和利润来源，这块价格变化不会很大。
头部客户迁移成本非常高，一般很难迁移。因此，Datadog可能会通过打折来留住这些客户。（迁移成本主要是用户习惯的迁移）
Datadog正在扩展自己的品类，特别是在安全领域，希望从Splunk那里夺回更多客户。
Datadog除了扩展品类之外，还需关注Markplace。Marketplace中已经出现了针对业务的咨询，如何帮助用户将很多业务数据标记在观测性数据上，增加了很多业务方面的维度标签。

7 开源与新产品如何与Datadog竞争

Grafana开源产品需要考虑TCO和数据整合：

Grafana具有特殊性，因为它与ELK实际上是相同的。Grafana对大家更多的理解，它实际上是一个BI。
Grafana是Kibana 3.0的Fork。Grafana最早的原型是从Elastic里面分叉出来的，大家发现它比Kibana更好用。Grafana早期更多地是一个开源工具，但现阶段开始推出LGTM Stack（Loki-Grafana-Tempo-Mimir），将Log、Trace，Metrics等全部商业化。主要推行Grafana Cloud（SaaS版本）和Enterprise（OP版本）。Grafana最近还收购了做profiling团队叫Pyroscope。它是要产品线上的1:1对标Datadog。
Grafana的问题在于原来是基于开源产品，数据整合并没有做好，仍然是一系列独立的系统，比较割裂。虽然大家都带上了Grafana的系统，如Loki、Metrics使用的普罗米修斯等，这些都是收购或合并过来的。可能会陷入一个尴尬的境地，大家可能都会支持Grafana这个产品作为一个BI或insights的工具去使用。但是，是否要用Grafana这一整套的东西，存在疑问。例如，西门子在使用Grafana时，并不是用Grafana的可观测性的东西，西门子是Datadog的大客户。但在工业制造和IT的数据会汇合到Grafana上去展示，西门子也付费给Grafana。
同时客户在搭建Grafana时候也要考虑人力成本带来的TCO问题。自建可观测系统至少需要一年，而且需要持续维护、扩容和升级。可观测性平台是地查询频率、高写入频率场景，控制算力也可能带来不稳定。同时可能牺牲前台体验。
因此，从目前的整体可观测性角度来看，Grafana目前吆喝大于实质，尤其是其Cloud版本，由于其价格不比Datadog便宜，所以会出现如果要使用Grafana的全家桶，为什么不用Datadog？但如果想省钱，可以考虑将Grafana的全部私有化自建，这对Grafana没有什么好处。
但是Grafana的影响力很大，国内有很多可观测性公司都是基于Grafana的。Grafana Cloud的目标市场还是开源Grafana的用户。

Honeycombo、Chronosphere等创业公司都有自己的竞争方法：

Honeycombo切入点是从研发测，不考虑运维测。相比Datadog，Honeycombo在云原生和Consumption Model上更加彻底，不按照Agent的数量收费，可以解决之前DDOG在Infra监控场景会出现浪费的情景。更加从定价模式上与Datadog竞争。
Chronosphere主打产品更便宜，其基于开源时序数据库M3DB。
市面上还有其他的创业公司，例如基于Snowflake的Observe。

云厂商的产品适合小项目：