Serverless 越省事，运维越头疼？冷启动、日志丢失、采样难题到底怎么破

作者：Echo_Wish

很多开发同学第一次接触 Serverless 时，第一反应都是：

• 不用买机器
• 不用配置环境
• 不用扩容
• 不用半夜起来处理 CPU 飙升

听起来是不是很美？

但是，当系统真正上线之后，很多运维同学会发现一个现实问题：

服务器没了，问题并没有消失，只是换了一种形式出现。

以前传统架构的问题是：

• CPU 100%怎么办？
• 内存泄漏怎么办？
• 磁盘满怎么办？
• 服务挂了怎么恢复？

而 Serverless 时代的问题变成：

• 函数为什么突然变慢？
• 为什么偶尔出现一次 5 秒延迟？
• 为什么线上错误日志找不到？
• 为什么链路追踪数据不完整？
• 为什么监控看到的指标和用户体验不一样？

这就是 Serverless 可观测性的核心挑战。

今天我们聊三个最典型的问题：冷启动、短生命周期、采样策略。

一、Serverless 最大的问题：你不知道它什么时候“出生”

传统服务是什么样？

比如一个 Spring Boot 应用：

服务器启动|加载 JVM|加载 Spring|创建 Bean|监听端口|等待请求

启动一次，运行几个月。

所以运维很好监控：

服务器状态|CPU|内存|网络|应用日志

但是 Serverless 不一样。

典型代表包括 AWS Lambda、阿里云函数计算、Azure Functions：

请求来了：

用户请求|平台创建运行环境|下载代码|初始化依赖|执行函数|返回结果

请求少的时候：

环境销毁

下一次请求：

重新创建

这就是大家经常说的：

冷启动（Cold Start）

一个简单例子

假设我们有一个 Python Serverless 函数：

import timedef handler(event, context):start = time.time()result = do_business()cost = time.time() - startprint({ "cost": cost})return resultdef do_business():time.sleep(0.5)return "success"

第一次调用：

函数初始化：2秒业务执行：0.5秒总耗时：2.5秒

第二次调用：

初始化：0秒业务执行：0.5秒总耗时：0.5秒

业务代码完全一样。

但是用户体验差了5倍。

问题来了，如果我们只看业务耗时：

业务耗时 500ms

监控显示：

“系统很健康。”

但是用户会问：

“为什么第一次打开这么慢？”

这就是 Serverless 监控的第一个坑。

二、传统监控思路，在 Serverless 时代失效了

很多企业刚开始做 Serverless，会直接套传统监控方案。

例如监控：

服务器CPU服务器内存服务器磁盘

结果发现：

全部正常。

但是业务投诉：

“接口偶尔超时。”

为什么？

因为 Serverless 没有长期运行的服务器。

你的监控对象变成了：

服务器↓函数实例↓一次请求

监控粒度越来越细。

以前：

一天一个服务指标

现在：

一次请求一个生命周期

Serverless 可观测性需要关注什么？

一个完整链路应该是：

请求进入 ↓触发函数 ↓初始化环境 ↓加载依赖 ↓执行代码 ↓调用数据库 ↓调用第三方服务 ↓返回结果

所以我们需要记录：

指标	作用
Cold Start次数	判断冷启动影响
初始化时间	定位启动慢
函数执行时间	业务性能
错误率	稳定性
调用链	定位上下游问题
资源消耗	成本优化

三、冷启动怎么监控？不要只看平均值

很多团队监控喜欢看平均响应时间。

例如：

接口平均耗时：300ms

看起来很好。

但是 Serverless 最大的问题是：平均值会骗人。

比如 1000次请求：

990次：100ms10次：5000ms

平均：

149ms

非常漂亮。

但是那10个用户：

已经骂娘了。

所以 Serverless 必须关注：

P95、P99 延迟

例如：

P50:100msP95:800msP99:5000ms

说明：

• 大部分正常
• 但是极端情况严重

代码里面也应该增加冷启动标记：

import timeis_cold_start = Truedef handler(event, context):global is_cold_startstart = time.time()if is_cold_start:print({ "cold_start": True})is_cold_start = Falseresult = process(event)print({ "duration":time.time()-start})return result

这样日志里面：

{ cold_start:true, duration:2.8}

你马上知道：

这次慢，是因为冷启动。

四、短生命周期：日志还没上传，函数已经没了

这是 Serverless 第二个坑。

传统应用：

服务运行一年日志保存一年

但是 Serverless：

请求来了执行3秒结束销毁

生命周期可能只有几百毫秒。

如果日志同步上传，可能出现：

函数结束↓日志还没发送↓数据丢失

所以 Serverless 日志设计必须：

异步化

例如，错误日志：

import jsonimport tracebackdef handler(event, context):try:do_work()except Exception:log = { "error":traceback.format_exc()}send_async(log)raise

不要：

业务代码↓等待日志系统返回↓结束

否则：

日志影响业务。

很多大厂现在采用：

函数↓本地缓冲↓消息队列↓日志平台

例如：

Lambda↓Kafka↓ElasticSearch↓Kibana

或者：

函数↓OpenTelemetry Collector↓Trace系统

五、采样策略：数据太多也是一种灾难

Serverless 最大特点：

调用量巨大。

假设每天有 10亿请求。

如果每一次都做完整Trace：

请求参数↓函数↓数据库↓Redis↓第三方API

全部保存，成本直接爆炸。

所以必须采样。

最简单的是固定采样。

例如，只记录10%。

代码：

import randomdef should_sample():return random.random() < 0.1if should_sample():collect_trace()

效果：

100万个请求↓保存10万个

成本下降90%。

但是问题来了：

如果错误只出现0.01%，可能一次都采不到。

怎么办？

答案：

智能采样

规则：

• 正常请求：采1%
• 慢请求：100%采集
• 错误请求：100%采集

例如：

def sample_request(response):if response.status >= 500:return Trueif response.time > 3000:return Truereturn random.random()<0.01

这才符合实际运维需求。

六、OpenTelemetry 是 Serverless 时代的重要答案

现在越来越多团队使用：

OpenTelemetry

原因很简单。

以前：

应用 |监控平台A

换平台：

重新改代码

很痛苦。

现在：

应用↓OpenTelemetry↓任意监控平台

比如：

PrometheusJaegerGrafanaElastic

都可以接。

简单示例：

from opentelemetry import tracetracer = trace.get_tracer(__name__)def handler(event, context):with tracer.start_as_current_span("serverless-request"):result = business()return result

自动生成：

TraceID:abc123Span:serverless-requestDuration:300ms

排查问题效率提升非常明显。

七、Serverless不是没有运维，而是运维方式变了

以前运维关注：

机器↓服务↓进程

Serverless之后，关注的是：

请求↓函数↓调用链↓业务结果

运维从：

“服务器管理员”

变成：

“系统可观测性工程师”。

我的理解：

Serverless 最大价值不是“不需要运维”。

而是将重复性高、价值较低的服务器维护工作交由平台处理，把有限的运维资源从日常托管中抽离出来，转向系统稳定性治理与业务体验优化。

但是前提是：

你必须建立新的可观测体系。

否则：

服务器没了，黑盒来了。

写在最后

Serverless 让开发效率提升了一大截。

但是它也给运维提出了新的挑战：

• 冷启动导致偶发延迟
• 短生命周期导致数据丢失
• 高并发导致监控成本爆炸
• 分布式调用导致问题定位困难

未来的 Serverless 运维，不再是谁会重启服务器。

而是谁能够回答：

这才是真正属于 Serverless 时代的可观测性能力。

服务器可以消失，但系统的问题永远存在。

区别只是：

• 以前我们盯机器
• 现在我们盯每一次请求