作者：来自 Elastic Ishleen Kaur
通过一个 drain 和一个 API key，就可以将 Vercel 日志、trace 和 Speed Insights 导入 Elastic Cloud，让你能够跟踪一个缓慢请求从边缘节点一直到其背后的 Lambda 函数。
Elastic 原生支持 OpenTelemetry。通过 OTLP 直接将 trace、日志和指标发送到 Elasticsearch，无需使用任何专有 agent。了解它们如何协同工作，在云端免费试用，或者在本地运行。
生产环境中出现了故障。你的 Lambda 错误率正在上升，用户纷纷离开，而你盯着 Vercel 仪表板，试图弄清楚这究竟是代码问题、冷启动问题，还是某个特定区域发生了问题。日志告诉你_发生了某些事情_。但它们无法告诉你为什么发生、从哪里开始，或者用户实际经历了什么。
这正是 Elastic 的 Vercel 集成旨在解决的缺口。不只是日志，而是完整的全貌：真实用户性能、服务器健康状况、展示完整请求路径的 trace、治理事件、流量和用户参与度。所有这些数据都可以在一个地方进行查询。
而这一点很容易被忽略：你不需要在自己的环境中部署任何东西。不需要 OpenTelemetry Collector，不需要 Elastic Agent，也不需要 agent policy。Vercel 有一个名为 Drains 的功能，可以通过 HTTP webhook 流式传输你的数据。Elastic 在 Elastic Cloud 上运行一个托管 endpoint，用于接收这些 payload 并将其写入 Elasticsearch。你只需要使用 API key 将一个 drain 指向某个 URL，数据就会开始流入。这就是整个基础设施层面的配置。
Vercel drains 向 Elastic Cloud 发送什么
该集成从 Vercel 获取五种信号 类 型，而且它们之间的互补性比乍看之下更强。
| 信号 | 携带的数据 | 需要的 SDK | 计划 | Endpoint |
|---|---|---|---|---|
| Web Analytics | 页面浏览量和自定义事件，以及流量模式和地理位置 | @vercel/analytics |
Pro 或 Enterprise | Vercel endpoint |
| Speed Insights | 真实用户 Web Vitals：LCP、INP、CLS、TTFB，并按路由、设备类型和国家进行标记 | @vercel/speed-insights |
Pro 或 Enterprise | Vercel endpoint |
| 日志 | 构建输出、静态资源请求、Lambda 函数输出、edge 函数输出 | 无 | Pro 或 Enterprise | Vercel endpoint |
| 审计日志 | 团队治理事件：环境变量更改、drain 编辑、项目转移 | 无 | Enterprise | Vercel endpoint |
| Trace | 基础设施 span 和出站 HTTP fetch 调用，以及框架和自定义 span | @vercel/otel（可选） |
Pro 或 Enterprise | 托管 OTLP endpoint，/v1/traces |
Vercel Web Analytics：流量和自定义事件
Web Analytics通过 @vercel/analytics SDK 捕获页面浏览量和自定义事件（流量模式、地理位置，以及用户实际访问的页面）。该 SDK 本身可以安装在任何 Vercel 计划上。要将这些数据转发到 Elastic，需要使用 drain，而 drain 仅适用于 Pro 和 Enterprise 计划。
Vercel Speed Insights：真实用户 Web Vitals
Speed Insights 提供真实用户 Web Vitals，包括 LCP、INP、CLS 和 TTFB 。这些指标在浏览器中测量，并标记路由、设备类型和国家。将 @vercel/speed-insights SDK 安装到你的应用中，然后在 Pro 或 Enterprise 计划上创建一个 drain，即可将 Web Vitals 发送到 Elastic。当你看到 Lambda 错误激增，并想知道用户是否真的注意到了这一点时，这些数据可以帮助回答这个问题。
Vercel 日志：构建、Lambda 和 edge 输出
日志覆盖完整的 服务端 运行时情况，包括构建输出、静态资源请求、Lambda 函数输出和 edge 函数输出。当出现故障时，这就是你开始深入排查的地方。你可以直接在 Vercel drain 设置中配置采样率，并按环境缩小范围。日志需要 Pro 或 Enterprise 计划。
Vercel 审计日志：团队治理事件
审计日志涵盖团队级别的治理事件（谁修改了环境变量、谁修改了 drain，以及谁转移了项目）。当你试图了解某个配置更改是否发生在故障事件之前时，它会非常有用。审计日志需要 Enterprise 计划。
Vercel Trace：端到端的 OpenTelemetry span
Trace 是该集成真正强大之处所在，可以帮助你进行调试。当你配置 Trace Drain 后，Vercel 会自动对基础设施 span 和出站 HTTP fetch 调用进行 instrumentation。你还可以添加 @vercel/otel 包，以获得框架和自定义 span。这些 trace 会显示在 Kibana 的 Service Inventory 中，包括 trace waterfall、服务地图，以及直接从 trace 跳转到相关日志行的功能。Trace 需要 Pro 或 Enterprise 计划。Trace 使用与其他信号不同的 endpoint；它们会发送到托管 OTLP endpoint 上的 /v1/traces。
每种信号在 Vercel 中都有自己的 drain，并最终进入 Elasticsearch 中各自的数据流。
如何将 Vercel 日志、Speed Insights、Web Analytics 和 Trace 发送到 Elastic Cloud
在 Elastic Cloud 中，进入 添加数据 → 直接连接到 endpoint（Add data → Connect directly to the endpoint）。你会看到列出的 Vercel endpoint，以及创建 API key 的选项。在前往 Vercel 之前，先获取这两项信息。
Vercel endpoint URL 和 API key 都可以在这里获取；在操作 Vercel 设置之前所需的一切信息都已准备就绪。
在 Vercel 中，打开你的团队设置，然后进入 Drains → 添加 Drain 。选择你想要收集的信号类型，点击 下一步，粘贴 Elastic endpoint URL，然后添加一个自定义 header：
go
`Authorization: ApiKey <your-key>`Lobster AIVercel 支持将 Logs、Traces、Speed Insights、Web Analytics、Audit Logs 等数据通过 drain 发送，每种信号都需要单独的 drain。Logs、Speed Insights、Web Analytics 和 Audit Logs 共用 Vercel endpoint，而 Traces 使用托管 OTLP traces URL。
只需要目标 URL 和 Authorization header，接下来的一切都由 Elastic 处理。
对每种信号类型重复上述操作。对于 Traces，请使用托管 OTLP endpoint ，并在末尾添加 /v1/traces，不要使用标准的 Vercel drain URL。
如需完整的设置流程和配置选项，请参阅Vercel（OpenTelemetry）集成文档。
Kibana 中的无服务器监控：仪表板、告警和 SLO
数据开始流入后，所有相关资源（仪表板、告警和 SLO 模板）都会自动安装。但真正的价值并不在于单独查看这些资源，而是在出现问题时，所有信息都集中在同一个地方。
仪表板
日志仪表板 是大多数调查开始的地方：请求量、错误率、HTTP 状态分布、热门路由以及区域细分。如果错误集中在某个区域或特定路由中，你可以立即发现。
Speed Insights 仪表板按 p75 展示 Core Web Vitals 随时间的变化以及各页面的指标，并使用与 Vercel 相同的"良好 / 需要改进 / 较差"阈值。当一次部署上线后，LCP 开始逐渐恶化，你会首先在这里看到。
Web Analytics 仪表板涵盖客户端流量情况：页面浏览量、地理位置、设备、热门页面和自定义事件。它本身就很有用，但当你试图了解服务端问题是否真正影响到了用户时，与日志仪表板结合起来尤其有价值。
针对 Vercel 故障模式的十条告警规则
除了仪表板之外，还有十条预构建的告警规则，覆盖 Vercel 工作负载中真正重要的故障模式：
-
5xx 激增。
-
Lambda 和 edge 函数硬崩溃（这类故障不会返回 HTTP 响应，并且会从标准错误率统计中消失）。
-
服务端和客户端流量突然下降。
-
区域性错误集中。
-
TTFB 恶化，作为 LCP 回归的早期预警。
-
WAF 拒绝请求激增。
-
来自单个操作者的可疑审计活动。
针对错误率和 Web Vitals 的五个 SLO 模板
五个 SLO 模板完善了整个方案，全部采用滚动 30 天时间窗口。服务端错误率 99% 是核心目标。其余四个涵盖 p75 的 Core Web Vitals 和 TTFB，因此真实用户性能不再只是偶尔查看的指标，而是你可以正式承诺的服务水平。
Kibana 中的 Trace Waterfall 和服务地图
对于 Trace，数据开始流入后，你就可以在 Kibana 的 Service Inventory 中获得完整的体验：端到端 Trace Waterfall、服务地图，以及与 span 直接关联的日志行。
为你的 Vercel 项目设置无服务器可观测性
如果你已经在使用 Elastic Cloud，那么距离完成设置比你想象的更近。endpoint 已经在那里，你只需要让 Vercel 指向它即可。如果你想从一个更聚焦的步骤开始，可以先使用 Web Analytics 或 Speed Insights：安装 Vercel 已经推荐的 SDK，然后在你的 Pro 或 Enterprise 团队中创建一个 drain。几分钟内，你就能在 Kibana 中看到真实用户性能数据。之后，再逐步加入日志，并在准备好后加入 trace，从而获得完整的调试能力。
该集成支持 Elastic Cloud Serverless 和 Elastic Cloud Hosted。进入 Elastic Cloud 项目中的 添加数据 → 直接连接到 endpoint，获取你的 endpoint URL，然后开始使用。
原文：Serverless observability for Vercel: five signals, no agent | Elastic Observability Labs