Dzmitry Lazerka，VictoriaMetrics 联合创始人 – 访谈系列

Dzmitry Lazerka，VictoriaMetrics 联合创始人是一位经验丰富的软件工程师和技术领袖，深耕机器学习、大规模数据系统、可观测性和基础设施。2018 年共同创立 VictoriaMetrics 之前，他在 Lyft 的 Level 5 自动驾驶部门担任机器学习工程师，帮助开发用于识别和分析真实驾驶场景的系统。此之前，他在 Spire Global 主导机器学习和数据基础设施项目，曾担任 Bellgram 的技术联合创始人，并通过 EPAM Systems 为 Duetto Research 和 Google 从事数据与分析系统工作。Lazerka 在职业生涯中构建并领导了涵盖自动驾驶、海事预测、搜索、分析、分布式数据处理以及高度可扩展后端系统的项目。

VictoriaMetrics是一家开源可观测性公司，构建用于收集、存储、查询和分析海量运营数据的工具。其技术起始于 VictoriaMetrics——一款面向可扩展性、快速查询、高效存储和低运维开销的高性能时序数据库和监控解决方案，随后扩展为覆盖指标、日志和分布式追踪的更广泛可观测性栈，产品包括 VictoriaMetrics、VictoriaLogs 和 VictoriaTraces。公司还提供企业版和全托管云部署，并具备将机器学习应用于时序数据的异常检测能力。其平台支持包括 OpenTelemetry、兼容 Prometheus 的工作流、Grafana 和 Kubernetes 等技术，为组织提供将 VictoriaMetrics 集成到现有可观测性环境中的灵活性。

在共同创立 VictoriaMetrics 之前，您曾在 Google、Spire Global、Lyft 的自动驾驶部门以及其他初创公司从事大规模数据、分析和机器学习系统的工作。是什么最终促使您创立 VictoriaMetrics？以及这些早期岗位中哪些问题让您确信监控和可观测性需要一种根本不同的方式？

我的职业生涯一直在处理海量数据。在 Google、Spire、Lyft 以及其他公司，您会很快意识到，在一种规模上运行良好的方案，在另一种规模上可能变得昂贵或难以运维。监控正面临同样的问题。

随着基础设施的增长，您会产生更多的指标。您会添加更多的服务、实例和标签，直到监控系统本身需要大量基础设施，这在我们看来毫无意义。用于监控生产环境的系统不应变得更复杂且更昂贵。

这正是我的联合创始人 Aliaksandr Valialkin 和 Roman Khavronenko 直接看到的。他们有使用 Prometheus 的经验，并遇到过内存限制。引入诸如 Thanos 的系统可以解决部分扩展问题，但也带来了更多组件和运维复杂性。而在使用 InfluxDB 时，我们看到许可变更会在团队已经投入技术后影响工程决策。

因此，VictoriaMetrics 的理念非常务实：我们能否构建一款在资源使用上显著更少且更易运维的时序数据库，完成相同的工作？

我们最初并没有计划打造一家大型可观测性公司，而是从解决一个工程问题开始。

将其开源是其中的一环。工程师可以下载 VictoriaMetrics，将真实的生产工作负载放在其上自行对比结果。我们无需告诉他们它更快或更高效，工程师可以自行测量。

这是构建基础设施软件的最佳方式。如果技术优秀，工程师应当能够自行验证。

可观测性成本往往悄然占据公司云费用的很大比例。这些成本通常在何处失控？工程团队最常犯的架构或采购决策错误是什么？

我会首先关注基数。

假设您从一个合理的指标开始，然后添加一个具有多个可能取值的标签。瞬间，一个指标会变成成千上万甚至数百万条唯一的时序数据。系统需要处理、索引、存储和查询更多的数据，从而导致 CPU、内存和存储需求增加。

困难之处在于，这并非因为某人一次错误决策导致，而是逐步累积。随着服务、K8s pod、客户和标签的增加，成本会呈指数增长。

第二个问题是以相同的分辨率和相同的时长存储所有数据。并非所有可观测性数据价值相同。用于告警或 SLO 的指标与在事故期间一次性查看的高频诊断遥测数据需求不同。

如果把所有数据一视同仁，您将为本不需要高价基础设施或 SaaS 的数据支付溢价。

这就是为何一些公司把可观测性视为采购问题，询问哪个平台最易部署。我会提出诸如“遥测数据量增加 10 倍会怎样？基数会怎样变化？我们在存储什么？存储多长时间？成本会如何？”之类的问题。

这些问题有工程层面的解决方案。例如，使用流式聚合可以在数据写入存储前进行聚合，而不是存储每条原始时序并在之后再聚合。可以将高基数工作负载与业务关键监控分离。还可以根据数据价值采用不同的保留和分辨率策略。

目标并不是尽可能少收集遥测数据，而是需要足够的信息来了解系统的运行情况。

目标是避免在收集、处理和存储对业务无增值的数据上浪费资源。

可观测性本质上是一个工程系统，其成本也应当被工程化。

Grammarly 表示，其基于 VictoriaMetrics 的概念验证使 AWS 费用降低了 10 倍。当公司实现如此规模的节省时，底层到底发生了哪些变化：数据压缩、计算需求、存储架构、运维复杂性，还是这些因素的组合？

这是多方面的组合，但压缩和资源占用是主要因素。VictoriaMetrics 为时序数据使用专用压缩，使相同的指标占用的磁盘空间仅为通用数据库的一小部分。此外，在相同写入速率下，我们的 RAM 使用量比 Prometheus 低四到五倍，磁盘占用低至十倍。当 Grammarly 进行概念验证时，这直接体现在其 AWS 账单上，因为他们不仅存储的数据更少，还运行了更少且更小的实例。

运维复杂性也很重要，但影响更为间接。许多团队在评估可观测性成本时只关注存储和计算费用，却忽视了维护由五个组件组成的 Thanos 堆栈相较于单一二进制文件所消耗的工程工时。这也是实际支出，只是难以量化。

Prometheus 已成为云原生监控的基石，但一些组织最终会遇到可扩展性或运维限制。通常是什么促使公司开始考虑超越传统 Prometheus 部署的方案？以及何时 VictoriaMetrics 成为合乎逻辑的替代方案？

Prometheus 在其设计目标上表现出色：单节点抓取和告警引擎。团队通常会以两种方式遇到瓶颈：要么其基数增长超出单个 Prometheus 实例能够在内存中容纳的范围，要么他们需要长期保留以及跨多个集群的全局查询，而 Prometheus 本身从未被设计用于这些场景。此时人们会在其上叠加 Thanos 或 Cortex，这通常也是运维痛点的开始。你会从运行一个二进制文件，转变为运行包含压缩器、查询器、存储网关等众多组件的分布式系统，而这些组件可能在凌晨 3 点出现故障。

VictoriaMetrics 成为合乎逻辑的下一步，因为它是即插即用的替代方案，而不是重新架构。团队只需将现有的 Prometheus 抓取配置指向 VictoriaMetrics，并保留所有已构建的 Grafana 仪表盘、告警和记录规则。迁移仅是一次配置更改，而非项目，并且他们能够在不增加五个新组件的情况下实现规模扩展。

我们看到工程团队正在重新考虑是需要大型、全托管的可观测性平台，还是可以使用开源组件构建更高效的堆栈。您是否认为这是可观测性市场更广泛的结构性转变，以及开源对传统定价模型施加了多大压力？

这是一种结构性变化；并非对预算不佳年份的临时反应。可观测性供应商历来按摄取量或主机数量定价，而随着客户业务的增长，这种模式对客户不利。公司越成功，支付的费用越高，而定价与交付的价值并无真实关联。工程团队已经开始自行计算，意识到自托管、高效的开源堆栈会彻底改变这一等式。这是因为成本随实际运行的基础设施而伸缩，而不是随供应商控制的计量公式。

这对现有定价形成了真实的压力。当团队能够将现有的抓取配置指向开源替代方案，并在不失功能的前提下降低 60% 到 80% 的费用时，内部的讨论并不困难。仍然按主机或自定义指标收费的供应商将继续让那些不进行此类计算的客户流失。

AI 基础设施在方程中引入了一种异常昂贵的新资源：GPU。运行 AI 训练或推理的公司除了监控基本的 GPU 利用率外，还应关注哪些指标？更好的可观测性如何直接转化为降低 AI 基础设施成本？

仅凭 GPU 利用率无法提供足够信息。

你可以在仪表盘上看到 90% 的利用率并认为一切正常。但你真正想了解的是：GPU 在做什么？

你需要深入观察。正在运行哪些 CUDA 核心？GPU 内存是如何分配的？有多少时间花在移动内存而非计算上？工作负载在需要时是否使用了 Tensor Cores？GPU 真的是瓶颈，还是在等待来自其他位置的数据？

这些问题很重要，因为 GPU 价格昂贵。即使是小幅低效，若在数百甚至数千块 GPU 上重复，也会导致巨额成本。

例如，如果 GPU 因数据管道供给不足而处于等待状态，单纯增加 GPU 并不能解决问题。必须找出瓶颈。内存也是如此。如果工作负载的内存分配效率低下，更好的可视化可以帮助工程师调整批量大小或在相同硬件上运行更多工作负载。

这正是可观测性在 AI 基础设施中变得有价值的地方。它不仅仅是检测故障，还能告诉你计算资源的浪费所在。

所有这些监控还会带来可观测性问题。GPU 能产生大量详细且高基数的遥测数据。如果你收集全部并直接发送到昂贵的 SaaS 平台，虽然可以降低 GPU 成本并将部分节省用于存储监控数据，但这并不是一种好的优化方案。

借助 OpenTelemetry 和 OpenLIT 等项目，我们可以对 GPU 工作负载获得更深入的可视化。随后，使用 VictoriaMetrics，我们能够聚合数据，剔除无用维度，并高效保留工程师真正需要的信息。

有价值的问题并不是，“我的 GPU 利用率是多少？”

而是，“我为之付费的 GPU 正在提供哪些有价值的工作？”

一旦能够回答这个问题，你就可以开始做出更好的工程和成本决策。

AI 代理相较于传统软件带来了截然不同的可观测性挑战，因为单个请求可能触发模型调用、工具使用、向量数据库查询、交接，甚至是长链的自主操作。随着企业应用日益具备代理特性，可观测性需要如何演进？

传统可观测性假设请求在基础设施中遵循相对可预测的路径。具备代理特性的工作负载并非如此。单个代理可能先调用模型，再调用工具，然后再调用另一个模型，并在返回结果前重试三次。每一步都需要独立的可视化。

故障模式也不同。传统服务要么正确响应，要么不响应。而代理即使成功响应，也可能错误、缓慢或成本高昂，这些都不会在为正常运行时间构建的仪表盘中表现为典型错误。

让团队措手不及的部分是基数。单个代理工作流可以生成与特定用户、提示和工具调用相关的指标，这些数量会快速累积，尤其是在规划器不断调用同一工具的递归循环中。任何用于观察代理工作负载的系统都必须在不让成本曲线垂直上升的前提下处理这种规模，这正是我们要解决的问题。指标、日志和追踪仍然是正确的构建块。需要改变的是其背后的数据量和成本模型。

VictoriaMetrics 也在将机器学习和 AI 辅助工作流应用于异常检测。您认为 AI 在当今能够真正提升监控和事件响应的哪些方面，而哪些场景仍然难以被人工判断取代？

在生成想法、指导实施和验证结果的过程中保持有人参与非常重要。换句话说，与传统工作流相比并没有实质性变化。变化在于生成解决方案的能力被放大。现在任何人都可以创建软件，但这不应降低验收标准，而应显著提升。

AI 真正发挥作用的地方在于帮助发现人在噪声中可能忽略的异常，如离群点和未触发手动阈值的趋势。在 VictoriaMetrics，我们有一条简明的内部 AI 政策：员工可以自由地以任何方式自动化工作流程，但仍需对最终结果负责。这与我们在客户生产环境中对异常检测的标准大致相同。模型可以标记异常，但仍需由人来判断其含义并决定相应措施。

VictoriaMetrics 保持开源，并采用自筹资金、客户资助的方式，而非传统的风险投资基础设施创业模式。这对你们构建产品、定价以及决定哪些技术保持开源产生了怎样的影响？

自筹资金改变了激励结构，超出人们的预期。由于没有董事会要求我们在特定季度实现 ARR 数字，我们无需做出通常伴随这种压力的权衡，例如削弱开源版本以迫使用户升级到付费层，或像 InfluxDB 或 HashiCorp 为保护云供应商收入而更改许可证。VictoriaMetrics 的开源版目前采用 Apache 2.0 许可证，且我们暂无更改计划。

我们决定哪些内容保持开源的方式很简单：核心引擎——工程师需要信任我们来处理其生产数据的关键组件——保持开源。公司在规模化运行并需要有人负责时，我们会对其所需的功能收费：多租户、企业级身份验证、合规支持、CVE SLA 以及直接联系编写代码的工程师，而不是通过支持队列。采用客户资助的模式也意味着产品路线图由实际生产环境中遇到的问题决定，而不是由融资计划书中可融资的项目决定。

随着指标、日志、追踪、AI 应用遥测、GPU 监控以及自动异常检测日益融合，您认为未来几年可观测性栈会是什么样子，工程团队对希望保持相关性的平台会有什么期待？

该栈在运营层面先于作为单一产品的融合，这一点很重要。大多数团队并不想要一个将所有功能锁在同一 UI 的单体平台。他们希望指标、日志和追踪能够在同一运营模型、同一供应商和同一授权体系下运行，同时在需要时仍能独立使用各自的信号。这正是 VictoriaMetrics 正在构建的方向。我们并不是要把所有功能硬塞进一个二进制文件，而是确保这三类信号共享同一引擎和相同的效率特性，这样添加第二或第三类信号并不会带来第二或第三个运维难题。

能够在同一模型中吸收 AI 遥测和 GPU 监控且不导致成本曲线失控的平台才会保持竞争力。AI 工作负载产生的遥测量级远超传统按指标或按主机计费的模型所能承受。团队要么停止收集所需数据，要么其可观测性费用增长速度超过 AI 投资本身。工程团队将期望平台能够像对待任何基础设施一样处理这种大流量，而无需在工作负载增长时每次都重新架构或重新谈判。

感谢精彩的访谈，想了解更多的读者请访问 VictoriaMetrics。