关注共识粉碎机，获取历史讨论会纪要
详细的讨论会分享背景请见我们上一篇文章
《AI如何颠覆软件：你能为AI打工吗？》
。
我们尽量每周都会组织不同领域的AI讨论会，覆盖软件行业的所有细分。为了保持一个活跃的讨论环境，对参与人群会有限制。
下一期将定于
本周日（8.27）上午10点
，主题为
《芯片厂商如何突破英伟达垄断》
，详细的下一期内容和报名形式请见
文末的阅读原文
。
本期讨论会参与者：
蒋烁淼Samuel
，观测云CEO，驻云科技CEO，初代云计算老炮，湖畔大学第一期学员。
最早的可观测性源于
维纳
-
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领域）
第一点：要从所有地方获取数据
-
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报表。当然，在进行离线大计算时，实时处理不太可能。但对于一些常见业务场景中的数据，实际上可以通过类似监控或观测手段实现。
看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，然后捣鼓出三四个仪表盘，实际用途并不大。然而，如何能够相对精准、有效地利用大模型，这也是我们目前看到的可观测性能极大提升生产效率的一个部分。
针对AI的观测重点仍然是数据
收集
能力和Know-how：
-
第一部分是数据收集能力。例如，使用一个开源系统，用户自己搭建一个开源采集器来对接所有大模型，无论是推理还是训练基础设施或应用程序。但是这种开发和制作这些功能通常需要一定的时间和经验。从厂商角度来看，提供一键式的接入能力是必要的。然而，目前看到大模型方面对数据接入能力并没有特别的要求，基本上就是对于这个接口或者新的硬件的支持。
-
另一方面，还是偏know-how的。即拥有这些数据后，如何将其与当前场景结合，构建自己的可观测性能力。当然，无论是Datadog还是其他家，还只是提供了一些标准范式。最终，如果要做得好，用户仍需根据自己的业务场景构建或修改这些标准范式来满足业务需求。因此，这一块更多的还是传统能力的体现。
-
目前我没有看到任何一个厂商，无论是开源还是非开源，在大模型观测上面有特别特殊的部分，基本上都是一样的。
大模型训练阶段对观测的需求没有推理大：
