为什么 Pydantic 要构建一个可观测性平台？

#现有工具的不足

多年来，我一直对现有的日志记录和监控工具感到沮丧。大多数这些工具都是为了满足大型企业的需求而构建的，由此产生的复杂性往往超过了它们提供的洞察力。

在许多方面，可观测性似乎停滞在了 15 年前其他基础设施所处的位置。彻底简化 Web 应用托管过程的创新浪潮，很大程度上绕过了可观测性。

最近涌现的“AI 可观测性”工具并没有好多少——是的，观察 LLM 调用很重要，甚至不成比例地重要，但这些 LLM 调用最终只是应用程序的一部分。为什么为此引入一个全新的工具，而我们不能有一个单一的平台有效地处理 AI 特定的监控和传统可观测性呢？

#以开发者为中心的可观测性

我们需要的是一个通用可观测性平台，并对 AI 提供一流的支持——但最重要的是，一个开发者真正想要使用的平台。开发者与可观测性工具的交互最多，但许多平台似乎忘记了这一点。

这就是我们构建 Pydantic 的背景发挥作用的地方。Pydantic 的成功并非因为它是最早的或最快的。它变得无处不在，是因为开发者喜欢使用它。我们将这种对开发者体验的关注带到了 Logfire 中，这在可观测性领域似乎让我们显得与众不同。

为了支持这一点，列出 Logfire 的所有功能很诱人——但这 已经存在了。相反，我想更深入地探讨我们做出的几个关键选择，因为我认为它们代表了 Logfire 与其他可观测性工具之间的差异。

#Logfire SDK

维护良好的 SDK 需要大量的时间和资源投入。大多数可观测性初创公司都转向依赖 OpenTelemetry (OTel)，它通过避免开发和维护自定义 SDK 的需要，以较低的成本支持多种语言。虽然这对业务来说是有意义的，但开发者却成了受害者，他们不得不与低级、冗长的 API 搏斗，而这些 API 通常令人不快。

因此，对于 Logfire 来说，仅仅依赖 OTel 的 Python 库从来都不是一个选择。

相反，我们构建了一个漂亮的 SDK，它封装了 OTel，但提供了更好的 API，并且包含了基本 OTel 库永远不会提供的功能。

import logfire

# this is generally all you need to set up logfire
logfire.configure()

# send a zero-duration span AKA a log
logfire.info("hello {name}", name="world")

# send a span with a duration
with logfire.span("my span"):
    do_some_work()

# instrument a FastAPI app
app = FastAPI()
logfire.instrument_fastapi(app)

为了对比原始 OTel，这里 是使用 Logfire SDK 和直接使用 OTel SDK 的相同代码的工作示例（包括 36 行 OTel 模板代码！）。

了解有关我们 SDK 的更多信息，请参阅 文档。

到目前为止，我们只有针对 Python 的 Logfire 特定 SDK，尽管您今天可以从任何 具有 OTel SDK 的语言 发送数据到 Logfire。但我们计划很快为其他语言构建 Logfire SDK，可能从我们首选的 TypeScript、Python 和 Rust 技术栈开始。

#SQL

Logfire 平台允许您编写任意 SQL 来查询您的数据；您可以使用它来查找特定跨度的属性、定义警报条件或为仪表板构建复杂的聚合。

SELECT attributes->'result'->>'name' AS name,
       EXTRACT(YEAR FROM (attributes->'result'->>'dob')::date) AS "birth year"
FROM records
WHERE attributes->'result'->>'country_code' = 'USA';

允许直接访问 SQL 会对我们能够使用的数据库施加真正的技术限制，并且会带来巨大的工程挑战，这就是为什么没有其他可观测性公司支持它的原因。但对于开发者来说，这种灵活性是无价的——我们认为这种权衡是值得的。

同样，就像维护 SDK 一样，这只是一个由每天编写代码的人组成的公司才会做出的决定。

#将追踪视为日志

Logfire 最具创新性的部分之一是我们的实时视图

数据来自 OTel 追踪，但显示方式像日志，只是更好。

此视图中“标准”OTel 数据的问题在于，跨度只有在完成时才会发送，这意味着您无法看到活动发生的时刻，并且在收到子跨度时也无法正确地将其与上下文联系起来，因为您将无法获得其父跨度。通过维护我们自己的 SDK，我们能够增强 OpenTelemetry 的工作方式，以便我们能够在跨度开始时发送有关跨度的数据——我们称之为“挂起的跨度”。这需要大量的努力，但它带来了极大地改善的开发者体验，用于交互式工作流程。现在，实时视图真正感觉像是实时的。

#我们如何看待开源与商业

太多的可观测性公司正在滥用其产品的开源标签。这些产品可以被故意设计得难以自行托管，以鼓励使用托管的替代方案。此外，“开源”版本通常缺少关键功能，迫使用户在锁定后转向封闭源代码的付费计划。

我们不一样：我们拥有真正的、真正的开源，开源，并获得了广泛的采用——Pydantic。

对于 Logfire，我们保持透明：SDK 是开源的（MIT 许可），但平台本身是闭源的。虽然我们提供了慷慨的免费套餐，但我们的目标是让您在 Logfire 中找到足够的价值，最终为它付费。这并不总是最简单的商业决策，但我们相信这种透明度是正确的方法。

#如果您还没有，请立即试用 Logfire

Logfire 仍在不断发展，它远非完美。但我相信它从根本上不同于之前的工具，并且有可能改变开发者理解其应用程序的方式。而且我相信它已经是市场上最适合其工作的工具。

请试一试，并 告诉我们哪些有效，哪些不好。

**附注：** 我们正在招聘

• 平台（DevOps）工程师
• Rust/数据库开发人员，负责基于 Apache DataFusion 的数据库开发工作

如果您认为我们正在从事的工作听起来很有趣，请与我们联系。