作者来自 Elastic Brad Quarry通过 LLM 可观测性证明 AI 价值需要什么在六个月的时间里Elastic IT 团队运行的内部 AI 应用为业务节省了价值 250 万美元的运营时间。¹ 一个对话式支持助手让我们从零数字化解决率 —— 任何复杂问题都会变成一个工单 —— 提升到 30% 的支持交互无需创建工单即可完成。我们能够将这些数字呈现给财务团队是因为从第一天开始我们就在单次使用事件的层面进行衡量。对于每个使用场景我们设定了一个保守的节省时间目标并与实际执行这些工作的团队进行验证。例如一份支持案例摘要大约可以节省 5 分钟。通过一个简单的公式事件数 × 节省分钟数 × 标准人工成本现在应用的投资回报率ROI已经成为一个实时 KPI而不是仅仅因为应用使用了生成式 AI就假设它可能具有价值。这些节省下来的时间重新回到了原本需要搜索答案的支持工程师手中并被用于路线图上的工作。大多数组织目前还没有达到这种程度。在我们针对 500 名 IT 决策者开展的《可观测性现状调查》中85% 的受访者表示计划为其大语言模型LLM应用启用可观测性但只有 8% 已经这样做了。团队看到了其中的价值只是他们似乎还没有将其列为优先事项。我想你可以把这种推迟称为“度量债务”。每一个在没有埋点的情况下上线的 AI 能力都在向未来借债因为未来总会有人需要证明它值得上线。就像技术债务一样它会悄悄累积并最终随着领导层要求证明可观测性投入的合理性而带来越来越大的压力。下面这些经验来自我们自己的实践也包括我们从其他团队那里了解到的一些有用建议。经验 1MVP 应该包含 LLM 可观测性面临展示 AI 进展压力的团队不应该把遥测视为第二阶段才需要考虑的问题。等到领导层要求提供收益数据时能够回答这个问题的使用历史必须已经被记录下来。如果没有记录可能就无法重建这些数据。数据可能会过期。采样可能会丢弃那些从未被标记为重要的数据。根据 Elastic《可观测性现状报告》虽然 93% 的组织会以某种形式向领导层报告财务和业务影响但只有 19% 会将其作为既定流程的一部分定期报告。³ 其余组织只是偶尔报告或者只在被要求时才报告这意味着相关数据通常会在截止日期的压力下根据当时能够获得的信息临时整理出来。试点项目会根据预期收益获得资金支持并且需要在启动时定义成功标准因此必须有一个可以进行衡量的基准。在第一位用户到来之前就确定成功是什么样的并在同一个迭代周期中为其添加埋点。ROI 应该是一个查询结果而不是一则轶事。经验 2不要使用确定性指标监控概率系统当从 A 点到 B 点每次都产生相同结果时可用性和延迟是足够的指标。然而一个生成式应用可以完全可用、运行速度足够快却完全错误。能够发现质量问题的团队会在传统指标之外跟踪第二组信号例如token 消耗量因为它是成本计量器检索质量因为有依据的回答取决于检索到了什么以及使用场景分类因为了解人们实际提出的问题是快速纠正方向的最快方式。这些信号在上线之后最为重要。上线时的埋点可以告诉你应用运行得是否正常。但当真实用户与应用交互时他们会提出一个不同但同样重要的问题这个版本是否比上一个版本更好任何上线时的埋点都无法回答这个问题。⁴ 更换模型、重写提示词或改变检索策略后你需要一个系统来告诉你究竟是让事情变得更好还是只是变得不同。这是一种比较而比较需要记录之前发生过什么。而且测试套件也只能回答其中一部分问题也就是你事先想到并捕获的那些情况。用户实际提出的问题一直在不断变化而测试用例集也需要根据实时遥测数据持续演进。基线必须在你意识到自己需要它之前就已经存在。经验 3坚持使用成熟的遥测术语当团队手动创建 AI 应用时必须有人为它产生的每个字段命名例如 token 数量、模型、工具调用和检索步骤。之后的每一个仪表板、告警和成本报告都会依赖这些自定义名称而当发生变化时这笔债务就会到期。如果更换了 agent 框架或者增加了第二个模型提供商又或者公司进行了新的收购那么报告层就必须重新构建。OpenTelemetry 的生成式 AI 语义约定就是为了防止这种情况而存在的。它为重要的操作定义了标准名称包括模型调用、agent 调用、工具执行和检索。采用趋势正在朝着一个方向发展生产环境中的 OpenTelemetry 使用量同比增长近一倍而根据《可观测性现状报告》目前 60% 的组织使用厂商发行版高于之前的 44%。该规范中的生成式 AI span、指标或属性目前都还没有被标记为稳定而且不同版本之间已经出现了属性重命名。⁵ 不过使用一个不断演进的标准仍然胜过使用私有标准。重命名是一项迁移工作私有术语体系则意味着整个系统需要重新构建。经验 4让埋点报告它已经知道的信息总有一天会有人把你的 AI 成本报告放在服务提供商的账单旁边然后问为什么两者对不上。通常答案是应用自己计算了一套数字而没有记录服务提供商已经返回的数字。常见的情况有三种当服务提供商的响应中已经包含它将实际计费的准确数字时却使用 tokenizer 库估算 token 数量在应用代码中硬编码价格来计算成本而每次模型发布新版本后这些价格都会过时重复埋点为同一次调用生成两条记录从而悄悄将下游的所有计数翻倍估算还会以仪表板无法展示的方式失败。不同服务提供商使用不同的 tokenizer因此同一个提示词针对不同模型会得到不同的 token 数量。推理模型会针对调用方永远无法收到的中间处理过程进行计费因此从可见响应中获取的 token 数量会遗漏部分计费内容而且对于成本最高的调用遗漏的内容通常也最多。⁶在今年我们现场团队构建的一个参考环境中进行审计时我们发现并移除了上述三种情况包括与服务提供商实际数据不一致的 token 估算以及导致调用计数虚高的重复 span。修正方案并不是增加更多代码而是减少代码。让埋点报告它已经知道的信息然后在查询时根据价格表计算成本等派生值这样价格变化就只需要更新数据而不需要重新部署。经验 5不要让遥测账单成为下一个意外可观测性支出是 2026 年领导层最关注的重点之一97% 的组织已经遇到过意外成本或超额支出其中 67% 表示这种情况经常发生。AI 工作负载会让情况变得更糟因为一个过去只产生少量 span 的请求现在可能产生几十个 span。两个决策造成了大部分损失而且这两个决策都是在无人审查的较低层级做出的。使用会随着使用量增长的值来标记指标对话标识符就是典型案例。每一次新对话都会增加监控平台需要存储和索引的数据量因此可观测性账单开始跟踪的是采用情况而不是基础设施。应用取得了成功而监控成本却越来越高。账单出现后团队通常采取的补救措施对所有数据保留一个固定比例。统一采样会按照相同比例丢弃失败和成功的数据而失败数据恰恰是遥测存在的全部原因。这两个问题都不需要什么复杂的工具。模式和采样策略是需要附带预算考量的架构决策而不是从配置文件中继承的默认设置。经验 6问题很可能出在数据而不是模型根据我们的经验AI 应用中的大多数质量问题并不是模型问题而是数据和检索问题最终表现为模型问题。基于你自己的内容进行知识库增强的应用会从查询时检索到的文档中生成回答。当回答错误时唯一可见的产物就是模型输出因此这也就成了调查的对象。团队会重写提示词然后升级到更大、更昂贵的模型但回答只略有改善或者完全没有改善因为模型只能基于它获得的信息进行工作。我们在自己的测试中也看到了这一点。在同一个参考环境中一次回答没有通过质量评审因为用于支持该回答的检索文档只覆盖了问题所涉及的 6 个策略领域中的 3 个。无论更换什么模型都无法找回一个从未被检索到的文档。除非应用记录这些信息否则这一切都是不可见的。检索到了什么、排名如何以及这些内容实际支持了多少回答这些都是请求本身的属性而不是模型的属性并且它们只存在于调用发生的那一刻。记录这些信息后质量调试就会发生根本变化。你可以区分模型问题、排序问题和内容问题而只有第一种问题可以通过更换模型来解决。那条老规则依然成立 —— 垃圾进垃圾出 —— 只不过现在它会以流畅而自信的幻觉形式呈现出来。我们花了一年时间构建以知识为中心的支持流程让工程师在关闭案例时撰写知识文章。这一基础让 Support Assistant 真正发挥了价值。更好的数据提高了上限。而衡量检索效果则让我们能够观察这个上限如何不断提高。经验 7了解成本可见性并不等于质量保证完整的成本视图可以回答 AI 花费了多少钱但无法说明 AI 是否正确。这是两个不同的领域而第二个领域正是大多数组织无限期推迟的事情。机器学习工程师 Hamel Husain 为 AI 产品团队提供评估方面的咨询他认为不成功的 AI 产品几乎总是存在一个共同的根本原因“无法建立健壮的评估系统”。⁶ 对有依据性、忠实性和工具使用情况进行系统评估并不是一个季度进行一次的工作。它应该接入承载性能和支出的同一份 trace 数据中这样质量评分就能够追溯到产生该评分的运行记录。仅仅关注成本可见性也可能产生误导因为大多数仪表板展示的数字使用了错误的分母。每次调用的价格是一种单位成本而业务真正购买的是一次已完成的请求。一个较弱的模型可能会降低前一个数字却提高后一个数字因为第一次尝试失败的工作会以重试、后续问题或更长的工具调用链形式再次出现而这些操作中的每一个都会再次产生费用。节省的成本会立即出现在显眼的位置而抵消这部分节省的支出则会在之后、不同的费用项目中甚至经常出现在另一个团队的预算中。因此两种节省看起来并没有关联。解决方法是改变分母。报告每个已完成任务的成本 —— 将总支出除以实际成功完成的任务数量 —— 这样一个需要尝试 3 次才能完成任务的低价模型就不会再显得便宜。将质量判定与成本记录在同一个 trace 中这样财务评审和质量评审读取的是同一条记录。对于希望用一个数字表示这种关联的人可以使用一个简化版本任务成功率乘以准确率再除以每个已完成任务的成本。对于 Support Assistant 而言成功意味着回答了一个问题而无需创建工单。利益攸关的程度还在不断提高一个回答糟糕的助手只会浪费片刻时间。一个推理糟糕的 agent 则会在多个步骤中基于错误结果采取行动并通过工具调用产生费用而成本是按照任务而不是问题逐步累积的。从未被记录的使用历史会变成无法解释的行动历史。从未被记录的基线会变成无法观察到的判断漂移。运营层面的问题会从“模型说了什么”转变为“agent 做了什么以及为什么这样做”。本文中的一切内容都是为了提前准备好回答这个问题而准备工作只需要在下一项 AI 计划上线之前做出一个决定从第一个事件开始就让它的价值可以被衡量。一个无法衡量助手返回了什么的组织就没有依据将采取行动的权限交给 agent。深入了解领先组织如何应对 AI 模型生命周期管理中最紧迫的挑战观看我们的点播网络研讨会新的竞争优势使用可观测性监控 AI 应用。来源1Elastic 内部测量持续 6 个月。方法观察到的使用事件 × 经验证的节省时间 × 标准员工人工成本率。2Phillip Carter《使用可观测性改进生产环境中的 LLM》2023 年。3John Hodge《OpenTelemetry GenAI 语义约定的现状》2026 年。4Braintrust《如何跟踪 LLM 成本》2026 年。5OpenTelemetry《生成式 AI 系统的 OpenTelemetry 语义约定》2026 年。6Hamel Husain《你的 AI 产品需要评估》2024 年。7Mostafa Ibrahim《什么是 Agent 可观测性Trace、循环率、工具错误以及每个成功任务的成本》2026 年。本文中所描述的任何功能或特性的发布及其时间安排均由 Elastic 自行决定。目前尚未提供的任何功能或特性可能不会按时交付也可能根本不会交付。在本文中我们可能使用或引用了由其各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具对于其内容、运行或使用不承担任何责任也不对因你使用此类工具而可能产生的任何损失或损害承担责任。在使用 AI 工具处理个人、敏感或机密信息时请务必谨慎。你提交的任何数据都可能被用于 AI 训练或其他目的。无法保证你提供的信息会得到安全或保密的处理。在使用任何生成式 AI 工具之前你应该了解其隐私实践和使用条款。Elastic、Elasticsearch 及相关标识是 Elasticsearch B.V. 在美国及其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。原文7 lessons for IT leaders on using observability to monitor AI applications | Elastic Blog
IT 领导者使用可观测性监控 AI 应用的 7 条经验
作者来自 Elastic Brad Quarry通过 LLM 可观测性证明 AI 价值需要什么在六个月的时间里Elastic IT 团队运行的内部 AI 应用为业务节省了价值 250 万美元的运营时间。¹ 一个对话式支持助手让我们从零数字化解决率 —— 任何复杂问题都会变成一个工单 —— 提升到 30% 的支持交互无需创建工单即可完成。我们能够将这些数字呈现给财务团队是因为从第一天开始我们就在单次使用事件的层面进行衡量。对于每个使用场景我们设定了一个保守的节省时间目标并与实际执行这些工作的团队进行验证。例如一份支持案例摘要大约可以节省 5 分钟。通过一个简单的公式事件数 × 节省分钟数 × 标准人工成本现在应用的投资回报率ROI已经成为一个实时 KPI而不是仅仅因为应用使用了生成式 AI就假设它可能具有价值。这些节省下来的时间重新回到了原本需要搜索答案的支持工程师手中并被用于路线图上的工作。大多数组织目前还没有达到这种程度。在我们针对 500 名 IT 决策者开展的《可观测性现状调查》中85% 的受访者表示计划为其大语言模型LLM应用启用可观测性但只有 8% 已经这样做了。团队看到了其中的价值只是他们似乎还没有将其列为优先事项。我想你可以把这种推迟称为“度量债务”。每一个在没有埋点的情况下上线的 AI 能力都在向未来借债因为未来总会有人需要证明它值得上线。就像技术债务一样它会悄悄累积并最终随着领导层要求证明可观测性投入的合理性而带来越来越大的压力。下面这些经验来自我们自己的实践也包括我们从其他团队那里了解到的一些有用建议。经验 1MVP 应该包含 LLM 可观测性面临展示 AI 进展压力的团队不应该把遥测视为第二阶段才需要考虑的问题。等到领导层要求提供收益数据时能够回答这个问题的使用历史必须已经被记录下来。如果没有记录可能就无法重建这些数据。数据可能会过期。采样可能会丢弃那些从未被标记为重要的数据。根据 Elastic《可观测性现状报告》虽然 93% 的组织会以某种形式向领导层报告财务和业务影响但只有 19% 会将其作为既定流程的一部分定期报告。³ 其余组织只是偶尔报告或者只在被要求时才报告这意味着相关数据通常会在截止日期的压力下根据当时能够获得的信息临时整理出来。试点项目会根据预期收益获得资金支持并且需要在启动时定义成功标准因此必须有一个可以进行衡量的基准。在第一位用户到来之前就确定成功是什么样的并在同一个迭代周期中为其添加埋点。ROI 应该是一个查询结果而不是一则轶事。经验 2不要使用确定性指标监控概率系统当从 A 点到 B 点每次都产生相同结果时可用性和延迟是足够的指标。然而一个生成式应用可以完全可用、运行速度足够快却完全错误。能够发现质量问题的团队会在传统指标之外跟踪第二组信号例如token 消耗量因为它是成本计量器检索质量因为有依据的回答取决于检索到了什么以及使用场景分类因为了解人们实际提出的问题是快速纠正方向的最快方式。这些信号在上线之后最为重要。上线时的埋点可以告诉你应用运行得是否正常。但当真实用户与应用交互时他们会提出一个不同但同样重要的问题这个版本是否比上一个版本更好任何上线时的埋点都无法回答这个问题。⁴ 更换模型、重写提示词或改变检索策略后你需要一个系统来告诉你究竟是让事情变得更好还是只是变得不同。这是一种比较而比较需要记录之前发生过什么。而且测试套件也只能回答其中一部分问题也就是你事先想到并捕获的那些情况。用户实际提出的问题一直在不断变化而测试用例集也需要根据实时遥测数据持续演进。基线必须在你意识到自己需要它之前就已经存在。经验 3坚持使用成熟的遥测术语当团队手动创建 AI 应用时必须有人为它产生的每个字段命名例如 token 数量、模型、工具调用和检索步骤。之后的每一个仪表板、告警和成本报告都会依赖这些自定义名称而当发生变化时这笔债务就会到期。如果更换了 agent 框架或者增加了第二个模型提供商又或者公司进行了新的收购那么报告层就必须重新构建。OpenTelemetry 的生成式 AI 语义约定就是为了防止这种情况而存在的。它为重要的操作定义了标准名称包括模型调用、agent 调用、工具执行和检索。采用趋势正在朝着一个方向发展生产环境中的 OpenTelemetry 使用量同比增长近一倍而根据《可观测性现状报告》目前 60% 的组织使用厂商发行版高于之前的 44%。该规范中的生成式 AI span、指标或属性目前都还没有被标记为稳定而且不同版本之间已经出现了属性重命名。⁵ 不过使用一个不断演进的标准仍然胜过使用私有标准。重命名是一项迁移工作私有术语体系则意味着整个系统需要重新构建。经验 4让埋点报告它已经知道的信息总有一天会有人把你的 AI 成本报告放在服务提供商的账单旁边然后问为什么两者对不上。通常答案是应用自己计算了一套数字而没有记录服务提供商已经返回的数字。常见的情况有三种当服务提供商的响应中已经包含它将实际计费的准确数字时却使用 tokenizer 库估算 token 数量在应用代码中硬编码价格来计算成本而每次模型发布新版本后这些价格都会过时重复埋点为同一次调用生成两条记录从而悄悄将下游的所有计数翻倍估算还会以仪表板无法展示的方式失败。不同服务提供商使用不同的 tokenizer因此同一个提示词针对不同模型会得到不同的 token 数量。推理模型会针对调用方永远无法收到的中间处理过程进行计费因此从可见响应中获取的 token 数量会遗漏部分计费内容而且对于成本最高的调用遗漏的内容通常也最多。⁶在今年我们现场团队构建的一个参考环境中进行审计时我们发现并移除了上述三种情况包括与服务提供商实际数据不一致的 token 估算以及导致调用计数虚高的重复 span。修正方案并不是增加更多代码而是减少代码。让埋点报告它已经知道的信息然后在查询时根据价格表计算成本等派生值这样价格变化就只需要更新数据而不需要重新部署。经验 5不要让遥测账单成为下一个意外可观测性支出是 2026 年领导层最关注的重点之一97% 的组织已经遇到过意外成本或超额支出其中 67% 表示这种情况经常发生。AI 工作负载会让情况变得更糟因为一个过去只产生少量 span 的请求现在可能产生几十个 span。两个决策造成了大部分损失而且这两个决策都是在无人审查的较低层级做出的。使用会随着使用量增长的值来标记指标对话标识符就是典型案例。每一次新对话都会增加监控平台需要存储和索引的数据量因此可观测性账单开始跟踪的是采用情况而不是基础设施。应用取得了成功而监控成本却越来越高。账单出现后团队通常采取的补救措施对所有数据保留一个固定比例。统一采样会按照相同比例丢弃失败和成功的数据而失败数据恰恰是遥测存在的全部原因。这两个问题都不需要什么复杂的工具。模式和采样策略是需要附带预算考量的架构决策而不是从配置文件中继承的默认设置。经验 6问题很可能出在数据而不是模型根据我们的经验AI 应用中的大多数质量问题并不是模型问题而是数据和检索问题最终表现为模型问题。基于你自己的内容进行知识库增强的应用会从查询时检索到的文档中生成回答。当回答错误时唯一可见的产物就是模型输出因此这也就成了调查的对象。团队会重写提示词然后升级到更大、更昂贵的模型但回答只略有改善或者完全没有改善因为模型只能基于它获得的信息进行工作。我们在自己的测试中也看到了这一点。在同一个参考环境中一次回答没有通过质量评审因为用于支持该回答的检索文档只覆盖了问题所涉及的 6 个策略领域中的 3 个。无论更换什么模型都无法找回一个从未被检索到的文档。除非应用记录这些信息否则这一切都是不可见的。检索到了什么、排名如何以及这些内容实际支持了多少回答这些都是请求本身的属性而不是模型的属性并且它们只存在于调用发生的那一刻。记录这些信息后质量调试就会发生根本变化。你可以区分模型问题、排序问题和内容问题而只有第一种问题可以通过更换模型来解决。那条老规则依然成立 —— 垃圾进垃圾出 —— 只不过现在它会以流畅而自信的幻觉形式呈现出来。我们花了一年时间构建以知识为中心的支持流程让工程师在关闭案例时撰写知识文章。这一基础让 Support Assistant 真正发挥了价值。更好的数据提高了上限。而衡量检索效果则让我们能够观察这个上限如何不断提高。经验 7了解成本可见性并不等于质量保证完整的成本视图可以回答 AI 花费了多少钱但无法说明 AI 是否正确。这是两个不同的领域而第二个领域正是大多数组织无限期推迟的事情。机器学习工程师 Hamel Husain 为 AI 产品团队提供评估方面的咨询他认为不成功的 AI 产品几乎总是存在一个共同的根本原因“无法建立健壮的评估系统”。⁶ 对有依据性、忠实性和工具使用情况进行系统评估并不是一个季度进行一次的工作。它应该接入承载性能和支出的同一份 trace 数据中这样质量评分就能够追溯到产生该评分的运行记录。仅仅关注成本可见性也可能产生误导因为大多数仪表板展示的数字使用了错误的分母。每次调用的价格是一种单位成本而业务真正购买的是一次已完成的请求。一个较弱的模型可能会降低前一个数字却提高后一个数字因为第一次尝试失败的工作会以重试、后续问题或更长的工具调用链形式再次出现而这些操作中的每一个都会再次产生费用。节省的成本会立即出现在显眼的位置而抵消这部分节省的支出则会在之后、不同的费用项目中甚至经常出现在另一个团队的预算中。因此两种节省看起来并没有关联。解决方法是改变分母。报告每个已完成任务的成本 —— 将总支出除以实际成功完成的任务数量 —— 这样一个需要尝试 3 次才能完成任务的低价模型就不会再显得便宜。将质量判定与成本记录在同一个 trace 中这样财务评审和质量评审读取的是同一条记录。对于希望用一个数字表示这种关联的人可以使用一个简化版本任务成功率乘以准确率再除以每个已完成任务的成本。对于 Support Assistant 而言成功意味着回答了一个问题而无需创建工单。利益攸关的程度还在不断提高一个回答糟糕的助手只会浪费片刻时间。一个推理糟糕的 agent 则会在多个步骤中基于错误结果采取行动并通过工具调用产生费用而成本是按照任务而不是问题逐步累积的。从未被记录的使用历史会变成无法解释的行动历史。从未被记录的基线会变成无法观察到的判断漂移。运营层面的问题会从“模型说了什么”转变为“agent 做了什么以及为什么这样做”。本文中的一切内容都是为了提前准备好回答这个问题而准备工作只需要在下一项 AI 计划上线之前做出一个决定从第一个事件开始就让它的价值可以被衡量。一个无法衡量助手返回了什么的组织就没有依据将采取行动的权限交给 agent。深入了解领先组织如何应对 AI 模型生命周期管理中最紧迫的挑战观看我们的点播网络研讨会新的竞争优势使用可观测性监控 AI 应用。来源1Elastic 内部测量持续 6 个月。方法观察到的使用事件 × 经验证的节省时间 × 标准员工人工成本率。2Phillip Carter《使用可观测性改进生产环境中的 LLM》2023 年。3John Hodge《OpenTelemetry GenAI 语义约定的现状》2026 年。4Braintrust《如何跟踪 LLM 成本》2026 年。5OpenTelemetry《生成式 AI 系统的 OpenTelemetry 语义约定》2026 年。6Hamel Husain《你的 AI 产品需要评估》2024 年。7Mostafa Ibrahim《什么是 Agent 可观测性Trace、循环率、工具错误以及每个成功任务的成本》2026 年。本文中所描述的任何功能或特性的发布及其时间安排均由 Elastic 自行决定。目前尚未提供的任何功能或特性可能不会按时交付也可能根本不会交付。在本文中我们可能使用或引用了由其各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具对于其内容、运行或使用不承担任何责任也不对因你使用此类工具而可能产生的任何损失或损害承担责任。在使用 AI 工具处理个人、敏感或机密信息时请务必谨慎。你提交的任何数据都可能被用于 AI 训练或其他目的。无法保证你提供的信息会得到安全或保密的处理。在使用任何生成式 AI 工具之前你应该了解其隐私实践和使用条款。Elastic、Elasticsearch 及相关标识是 Elasticsearch B.V. 在美国及其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。原文7 lessons for IT leaders on using observability to monitor AI applications | Elastic Blog
