3. 延迟采集挑战：冷启动、计费粒度与分布式追踪缺失

在无服务器架构中，延迟（Latency）是衡量用户体验与系统性能的核心 Golden Signal。然而，函数即服务（FaaS）的弹性扩缩、按需执行与细粒度计费模型，给延迟的准确采集带来了三个独特的挑战：冷启动导致的首次请求延迟、函数执行时间与计费粒度的差异，以及分布式追踪的缺失。本节将逐一剖析这些挑战，并提供可落地的采集策略。

3.1 冷启动导致的首次请求延迟

冷启动（Cold Start）是无服务器架构中最著名的延迟陷阱。当函数实例在空闲一段时间后被回收，或需要扩展新实例以应对流量突发时，平台必须从头初始化运行环境（下载代码、启动运行时、执行初始化逻辑），这会在首次请求的响应时间中引入显著的额外延迟，通常为数百毫秒到数秒不等。

下图展示了冷启动与热启动在请求生命周期中的延迟构成差异：

采集策略

• 分离冷/热启动指标： 在函数入口处记录 init_duration（初始化耗时），并将其与 execution_duration（业务执行耗时）分开上报。平台通常提供初始化阶段钩子（如 AWS Lambda 的 Init 阶段），可直接捕获。
• 按冷/热启动分位值聚合： 分别计算 p50、p99 延迟。冷启动 p99 通常比热启动高 5-10 倍，应设置独立的告警阈值。
• 预热与预留并发： 对于延迟敏感的关键路径，使用预留并发（Reserved Concurrency）或定时预热（Scheduled Warm-up）来减少冷启动发生频率，但这会增加成本。

3.2 函数执行时间与计费粒度的差异

无服务器平台的计费粒度通常为 1 毫秒（如 AWS Lambda）或 100 毫秒（如 Google Cloud Functions），但函数实际执行时间的测量粒度往往受限于运行时与监控 SDK 的精度。这种差异会导致以下问题：

• 计费时间 ≥ 实际执行时间： 平台向上取整到计费粒度，而用户侧采集的延迟可能更精细，造成成本归因偏差。
• 平台报告延迟 vs 客户端感知延迟： 平台日志中的 duration 通常只包含函数代码执行时间，不包含网络传输、API Gateway 处理、序列化/反序列化等端到端延迟。
• 并发与排队延迟： 当函数并发达到限制时，请求会在平台侧排队，这部分延迟不计入函数执行时间，但直接影响用户体验。

采集策略

1. 双轨采集： 在函数入口/出口处使用高精度计时（process.hrtime() 或 System.nanoTime()）记录实际执行时间，与平台日志交叉验证。
2. 标记计费舍入误差： 在指标中添加 billed_duration 与 actual_duration 两个字段，计算 overhead_ratio = billed_duration / actual_duration，用于成本优化。
3. 端到端追踪： 在 API Gateway 或负载均衡器侧注入追踪 ID，关联客户端与函数侧日志，还原完整请求链路。

3.3 分布式追踪的缺失

无服务器架构天然是分布式系统：一个用户请求可能经过 API Gateway、多个函数、队列、数据库和外部服务。然而，FaaS 平台的短暂生命周期、无状态特性和异步调用模式，使得传统的分布式追踪（如基于线程上下文的 Zipkin/Jaeger）难以直接工作。

下图展示了无服务器架构中分布式追踪的断裂点：

采集策略

• 显式上下文传播： 在事件消息（如 SQS、Kinesis）或 HTTP 头中嵌入 trace_id 和 parent_span_id，函数启动时从事件中提取并创建新的 span。
• 使用 OpenTelemetry SDK： 集成 OpenTelemetry Lambda 扩展或层（Layer），自动捕获入站/出站请求，并将 span 导出到后端（如 Jaeger、Tempo）。
• 关联平台日志： 将函数日志中的 request_id 与追踪系统中的 trace_id 建立映射，便于在日志与追踪之间切换排查。
• 采样策略： 对冷启动请求使用 100% 采样，对热启动请求使用自适应采样（如基于延迟分位值的概率采样），在控制成本的同时保留关键延迟数据。