Elastic Stack无服务器化实践：架构拆解、成本分析与避坑指南

自打开始帮团队做日志平台改造，我就一直被一个问题困扰：Elastic Stack 这套东西，功能是真强，但伺候起来也是真累。ES 集群要调 JVM、要盯分片数、要规划冷热节点，Logstash 的管道写不好就直接把 CPU 打满，Kibana 倒是省心，可它背后的索引模式、生命周期策略一样都不能马虎。直到后来我把整套架构往无服务器架构上迁移了一轮，才算是真正体会到了什么叫“把运维包袱卸下来”。这篇文章不聊虚的，就把我这段时间梳理的 Elastic Stack 技术栈和无服务器架构组合落地的核心思路、设计取舍、成本账目，以及那些非亲测看不出来的坑，一次性说清楚。

这篇内容适合谁？适合那种已经在用或者正准备用 ELK 做日志、指标、APM 数据处理的开发者或架构师，尤其是受够了自建集群运维折磨、想搞清楚 Serverless 化改造到底值不值的人。我会用实际的架构方案和事后的复盘数据说话，看完你至少能判断：哪些组件适合 Serverless，哪些不适合硬塞进去，以及用无服务器架构跑 Elastic 工作负载的钱到底花在了哪里。

1. 为什么要把 Elastic Stack 塞进无服务器架构：先算清这笔账

聊技术选型之前，先得说清楚动机。很多人一听“Elastic Stack 无服务器化”就觉得是没事找事：ES 本身就是分布式系统，天然要跑在常驻节点上，你非把它拆成一个个函数、一个个托管服务，图什么呢？

我最初也是这个想法，直到我看了团队里那台 ES 集群的利用率监控才改观。我们有一个内部业务日志平台，日均写入量并不夸张，大概在 200GB 到 500GB 之间波动，但波峰波谷极其悬殊：白天业务高峰期写入 TPS 能冲到每秒几千条，到了凌晨两三点，整个集群几乎处于空转状态。可空转归空转，节点的内存该占还是占，JVM 该调还是调。我算过一笔账：为了扛住白天的峰值，我们常年维持了三节点 SSD 数据盘的热节点集群，每月的 EC2 账单加上 ES 节点预留实例，折合下来差不多一千多美元。这还只是计算和存储成本，没算上每天晚上盯着分片健康度、定期做 forcemerge 的隐性人力成本。

无服务器架构的价值恰恰就体现在这种场景里。它的核心思路不是让你把所有东西都丢到 Lambda 里跑——那是不懂架构的人才会做的事——而是把 Elastic Stack 里那些适合事件驱动、按量付费、自动扩缩容的环节拆出来，用云原生的托管服务去承载，让 ES 集群本身只承担它最擅长的事情：存储和检索。

具体来说，Elastic Stack 的角色拆解可以这样做：

• 采集端（Beats/Agent/Fluentd）：天然适合用 Serverless 容器、Fargate 任务或轻量函数承载，跟着业务实例扩缩容走。
• 传输端（Kafka/Kinesis/SQS）：用云上托管队列服务代替自建 Kafka，按量付费，无需操心 broker 扩缩容。
• 解析清洗端（Logstash/Ingest Pipeline）：把 Logstash 的重量级处理逻辑换成 ES Ingest Pipeline 或 Serverless 流处理任务（比如 Lambda 事件过滤）。
• 存储检索端（Elasticsearch/OpenSearch）：用 Serverless 版本（如 OpenSearch Serverless）或托管集群，根据查询和写入压力自动调整计算资源。
• 可视化端（Kibana/Grafana）：本身无状态，部署在托管容器或直接使用 SaaS 即可。

这套组合拳打下来，最直接的效果就是：你不再为波谷期的闲置算力买单，也不再需要深夜爬起来处理集群的毛刺问题。 当然，代价也不是没有——后面我会专门讲 Serverless 化之后你失去的那些东西，比如对底层 JVM 参数的控制力。但至少从账面上看，这轮改造是值得的。

2. 核心架构链路：从数据采集到检索分析的 Serverless 化拆解

先别急着动手迁，你要先有一个完整的架构图景。我基于自己实践落地的一套参考架构来拆，这套架构我在生产环境跑了差不多半年，相对皮实，你可以直接拿去做蓝图。

2.1 全链路的逻辑拓扑：一条数据从产生到可被检索的完整旅程

一条日志数据从业务实例里产生，到最终能呈现在 Kibana 仪表盘上，中间会经过四个关键环节，每个环节在无服务器架构下都有对应的承载方式。

第一环：采集与接入。 这一环原来用的是 Filebeat 或 Metricbeat 直接吐给 Logstash。改造后，我把采集器塞进了业务服务所在的 Fargate 任务里，作为 sidecar 容器运行。采集器不再直接连 ES，而是先把数据投递到托管的消息队列。这里有个很重要的设计点：不要用采集器直连 ES 或 OpenSearch，中间隔一层队列能帮你扛住写入峰值的毛刺，避免把后端的瓶颈问题传导到采集端。

第二环：缓冲与削峰。 我选用的是 Amazon Kinesis Data Streams，原因后面细说。这一层的核心职责是削峰填谷，保证写入 ES 的速率是平稳的，而不是跟着业务流量剧烈抖动。

第三环：清洗与转换。 这一环在无服务器架构下有两种主流做法。一种是在 Kinesis 上挂 Lambda 做实时 ETL，另一种是把加工逻辑下沉到 ES 的 Ingest Pipeline 里。我实际用的是两者混合：轻量字段整理和格式标准化交给 Ingest Pipeline，复杂的多流关联、IP 归属地富化这类计算放在 Lambda 里做。

第四环：存储与检索。 这是最终目的地。你可以用 OpenSearch Serverless，也可以用托管集群。如果数据量比较稳定，我建议用托管集群配合 Index State Management 做生命周期管理；如果数据量波动大，Serverless 版更划算。这块选择和成本强相关，我单独用一节来讲。

2.2 采集与缓冲层的避坑设计：为什么我弃用了自建 Kafka

提到缓冲层，很多 Elastic 老兵的第一反应是上 Kafka，毕竟 ELK + Kafka 是经典配方。我没有否定这个方案，事实上如果你的团队已经有成熟的 Kafka 运维能力，继续用完全没问题。但要是从零开始选型，我强烈建议你评估一下 Kinesis 或 SQS 这类托管队列，理由有两点。

第一，Kafka 的运维成本和 ES 集群是叠加的，不是替代关系。你省了 ES 的节点管理，结果又要去伺候 Kafka 的 broker 和分区均衡，等于换了个地方继续当运维，无服务器改造的意义就折半了。第二，Kinesis 这类服务天然和 Lambda、Firehose 集成，几乎不用写胶水代码就能把数据流接到下游。

实操配置上有一个数据可靠性相关的参数值得注意：Kinesis Data Streams 的 Shard 数量决定了写入吞吐上限。一个 Shard 默认支持 1MB/s 或 1000 条/s 的写入。我一开始按平均流量估了 5 个 Shard，结果高峰期直接写穿，数据被 throttling。后来改成了按峰值流量的两倍预留，并且打开了 On-Demand 模式。On-Demand 模式虽然单价略高，但省去了人工预估 Shard 数的麻烦，对流量模型不确定的业务来说，综合成本反而更低。

如果你习惯用 SQS，也可以，但要注意 SQS 的消息大小上限是 256KB，大批量日志聚合后很容易超限，还得先压缩或拆分，比较烦人。Kinesis 单条记录上限是 1MB，对日志场景宽裕得多。日志数据源多、单条体积大，选 Kinesis 更省心。

2.3 Ingest Pipeline 与 Lambda 的分工边界：清洗逻辑到底该放哪

清洗逻辑放哪里，是个架构哲学问题，也是个成本问题。

我的经验是两条腿走路，但要划清楚边界。所有能用 ES Ingest Pipeline 原生处理器完成的轻量加工，一律不要写 Lambda。 比如：

• 用 grok 做日志格式解析
• 用 date 做时间戳标准化
• 用 rename / remove 做字段清理
• 用 set 做静态字段标记
• 用 pipeline 处理器做多级管道串联

这些操作在 ES 内部做，效率极高，而且不产生额外的计算费用。你可能觉得写个 Lambda 也没多少钱，但如果每天有上亿条日志经过，每条日志触发一次 Lambda 调用，半小时的账单就够你喝一壶的了。

真正需要 Lambda 出场的场景是这样的：

• 调用外部 API 做数据富化（比如查 IP 归属地、威胁情报库）
• 需要跨多条日志做状态聚合（比如先按 traceId 分组再加工）
• 逻辑里依赖了 ES Ingest Pipeline 不支持的第三方库

打个比方：Ingest Pipeline 是流水线上的标准机械臂，适合做重复、固定、低延迟的动作；Lambda 是旁边的老师傅，适合做需要判断、需要对外沟通、需要临时决策的活。老师傅工资高，别让他天天拧螺丝。

3. 存储计算分离：索引生命周期与 OpenSearch Serverless 的配置实战

聊完管道，终于到最核心的存储检索层。这块的决策直接影响你的账单和查询体验。

3.1 热温冷架构还是全 Serverless：数据分层策略的取舍

传统 Elastic Stack 的数据生命周期管理通常走 hot-warm-cold 三层，配合 Index Lifecycle Management（ILM）策略自动流转。数据先进入热节点提供低延迟写入和查询，几天后转到温节点，再过一段时间压缩到冷节点，最后删除或迁移到对象存储归档。

在无服务器架构下，这个分层策略需要重新设计，因为你不再直接控制底层节点的磁盘类型和规格。以 OpenSearch Serverless 为例，它有两个核心概念：Index Collection 和 OCU（OpenSearch Compute Unit）。OCU 是计费单位，也是扩缩容的最小粒度，每个 OCU 包含一定的计算和存储配比。你不需要指定实例类型，只需要设置单个 Collection 的 OCU 上下限。

但代价是，你没法像自建集群那样为热数据分配 SSD、为冷数据分配大容量 HDD。Serverless 版的底层存储是自动的，官方说数据会基于访问频次自动在存储层间迁移。这就导致一个结果：如果你有非常明确的冷热分层需求，且数据量在 TB 级以上，Serverless 版不一定比自建更省钱，因为它把分层粒度收窄了，资源的组合优化空间变小了。

我的取舍策略是这样的：

• 数据量 500GB 以下，查询频率中等，优先全 Serverless，省心第一。
• 热数据查询要求极高 QPS，冷数据量大且极少访问，采用托管集群 + 自定义冷节点 + S3 归档的组合。

实操上，如果你的数据量不大，建议给所有索引设置一个统一的 ILM 策略，20 天左右把索引关进只读状态、减少副本数，45 天删除或快照到 S3。别小看“关副本”这个动作，索引进入只读后，副本从 2 降到 0，存储成本和写入放大立刻能砍掉一大截。

3.2 在 OpenSearch Serverless 上设置 Collection 与网络策略的踩坑记录

第一次配置 OpenSearch Serverless 的时候，我差点被一个细节坑哭：它默认不开公网访问，而且 VPC 访问需要额外配置接口终端节点。 我按以前用托管 ES 的习惯，创建完 domain 就想着从 Kibana 直接连，结果控制台页面半天打不开，提示网络错误。

排查步骤分享给你：

1. 先确认 VPC 里是否创建了 OpenSearch Serverless 的接口终端节点，服务名叫 com.amazonaws.us-east-1.aoss。
2. 确认安全组是否放行了 443 端口到该终端节点。
3. 确认数据访问策略（Data Access Policy）里是否给 IAM 角色或用户授权了相应索引权限。

尤其要注意第 3 点，Serverless 版的数据访问控制是独立于网络策略的，必须在 Data Access Policy 里显式授权。我有一次已经能在 VPC 内连通 API 了，但一执行 _search 就报 load failed，查了半天才发现是 Data Access Policy 里的 resource 写错了，把 index/* 写成了 collection/*。不同版本对 resource 的格式要求不一样，这里一定要照着官方文档核对。

还有一点，Kibana 在 OpenSearch Serverless 里不叫 Kibana，叫 OpenSearch Dashboards，如果你要在公网访问它，得在控制台里单独启用，并且强烈建议前面加一层身份验证（比如 ALB + Cognito 或用 SAML 集成），别裸奔在公网上。

4. 实战中的数据链路保障：从 Kinesis 到 OpenSearch 的完整配置示例

理论说得再多，不如跑通一头。我把实际用的核心配置和代码贴出来，给你一个可以直接复制修改的模板。

4.1 Kinesis Data Streams 与 Firehose 的配合方式

我用 Kinesis Data Streams 作为实时缓冲层，再用 Kinesis Data Firehose 把数据从 Streams 投递到 OpenSearch Serverless。这里有一个比较容易绕晕的问题：为什么不用 Lambda 直接消费 Streams 再写入 OpenSearch？

直接答案是：Lambda 消费 Kinesis 默认是按批拉取的，一批最多 10000 条或 10MB，如果你直接把整批数据转发给 OpenSearch 的 Bulk API，单次请求体超过 OpenSearch 限制，会频繁报 413 错误。 但 Firehose 不一样，它内置了将缓冲数据按大小或时间窗口批量打包的能力，默认按 64MB 或 300 秒打包一次，对 OpenSearch 更友好。

Firehose 的 OpenSearch 目标配置大概是这样的（我简化成 JSON 配置片段说明，不同云厂商控制台操作路径不同，但参数语义类似）：

json复制{
  "deliveryStreamName": "log-stream-to-os",
  "s3DestinationConfiguration": {
    "bucketARN": "arn:aws:s3:::your-backup-bucket",
    "bufferingHints": {
      "intervalInSeconds": 300,
      "sizeInMBs": 64
    }
  },
  "elasticsearchDestinationConfiguration": {
    "domainARN": "arn:aws:es:us-east-1:123456789012:domain/log-collection",
    "indexName": "app-log-{now/d}",
    "indexRotationPeriod": "NoRotation",
    "bufferingHints": {
      "intervalInSeconds": 300,
      "sizeInMBs": 64
    },
    "retryOptions": {
      "durationInSeconds": 300
    },
    "s3BackupMode": "AllDocuments"
  }
}

两个重要的坑你得注意。

坑一：索引名和时区问题。 配置里 app-log-{now/d} 这个格式中的 {now/d} 是按 UTC 时间计算日期的。如果你在中国时区（UTC+8），凌晨零点到八点产生的日志会被归到前一天的索引里。解决方式是在 CDK 或控制台里指定 "timeZone" 参数为 "Asia/Shanghai"，或者在数据写入前由 Lambda 在文档里加一个 @timestamp 字段，并告诉 Firehose 用这个字段做索引分区，而不是用默认的 ingestion time。

坑二：字段类型冲突。 日志数据从 JSON 到 OpenSearch 动态映射阶段，如果同名字段在不同日志里类型不一致（比如一个地方是字符串 "200"，另一个地方是整数 200），映射一旦建立就不会自动更新，后续类型不符合的文档直接写入失败。我的解法是：在 Firehose 的 ProcessingConfiguration 里加一个 Lambda 处理器，统一对所有文档做类型清洗，把常见的业务字段强制转换成目标类型，避免脏数据把索引映射污染了。

4.2 从 OpenSearch 读取数据的查询性能调参经验

数据进去了，查询慢、聚合超时也是常见问题。无服务器版因为 OCU 在你的查询负载上来时才会扩容，冷启动的过程偶尔会有几秒延迟。如果你在 Kibana 里打开一个 Dashboard 觉得首次加载特别慢，不一定是查询写得烂，而可能是该 Collection 的 OCU 从低水位往上拉的时候加了计算资源。

但更多情况下，慢查询还是因为索引映射和查询写法不对劲。几个我常用且有效的优化措施：

• 为高基数聚合字段建 keyword 子字段：比如 api_path 这类字段默认会被映射成 text，直接做 terms 聚合会非常慢，应为它显式增加一个 .keyword 子字段，聚合走子字段。
• 控制聚合返回桶数：默认 terms 聚合返回 10 个桶，如果你业务上想看 Top 50，别把 size 设成 100000，那会拖垮整个查询。应该用 composite 聚合做分页式桶遍历，或者精确设定 size 为合理值。
• 优先使用 filter 而不是 must：filter 不参与分数计算，ES 会缓存 filter 的结果，在日志检索这种不需要相关度排序的场景里能省不少 CPU。
• 打开慢查询日志：在 OpenSearch 控制台或通过 API 设置 index.search.slowlog.threshold.query.info 为 2s，能把超过 2 秒的查询打出来，让你按图索骥定位慢查询源头。

4.3 批处理链路：S3 数据湖与定时任务结合

实时链路跑通之后，你还会遇到一类需求：把历史数据做批量重算，或者把 S3 里的冷数据导回 OpenSearch 做补录。这类批量任务不需要实时响应，用 Serverless 定时触发就行。

我的方案是：用一个 EventBridge 定时规则（比如每天凌晨两点触发），调起一个 Step Functions 状态机，先从 S3 拿到昨天的数据清单，再把清单切分成多个并行分片，每个分片由一个 Lambda 或 Fargate Task 负责读取、清洗、批量写入到 OpenSearch Serverless。写入端用 Bulk API，一批 1000 条，配合 _bulk 接口批量提交。

这里有个我踩过的性能瓶颈要提醒你：Bulk 写入 OpenSearch Serverless 时，OCU 的扩容速度跟不上突发写入，容易出现 429 限流错误。 自建集群的解法通常是调大 thread_pool.bulk.queue_size 或增加副本，Serverless 版没有这些旋钮给你拧。我的应对策略是在 Lambda 里做两层退避重试：

• 第一次收到 429，等 5 秒重试；
• 第二次还不行，把当前批次拆成两半，各等 8 秒再试；
• 超过三次，把数据转存到一个专门的 S3 死信桶，等第二天批次任务统一补写。

虽然听起来有点笨，但在无法调参的 Serverless 环境里，这反而是最稳妥、最能避免数据丢失的兜底逻辑。

5. 成本精细化管理：无服务器架构下的真实账单分析与优化

成本是 Serverless 改造里最容易被低估、也最容易翻车的一环。我见过太多人觉得无服务器就等于省钱，结果账单出来之后傻眼。事实上，Serverless 架构下的成本模型发生了根本变化：你不再为“算力”付费，而是为“调用次数 + 执行时长 + 数据传输量”付费。 每一步都要精打细算。

5.1 成本构成拆解：你以为省了，其实可能更贵

我以一个日均写入 300GB 日志、保留 30 天的业务为例，给你拆一个 OpenSearch Serverless 方案的成本构成。

可以看到，Serverless 不是帮你省了计算的钱，而是帮你省了“为了峰值而预留资源”的钱。 如果你的业务流量相对恒定、7x24 小时都有中等以上负载，自建托管集群反而更可控；如果你的流量潮汐效应明显、波谷时间窗很长，Serverless 的按量付费就显得划算得多。

量化判断方式很简单：以日为粒度，统计 OpenSearch 集群的 CPU 利用率曲线。如果一天中超过 50% 的时间 CPU 利用率在 20% 以下，那自建集群大概率在浪费钱；如果高峰期和低峰期的利用率差距小于 2 倍，说明工作负载非常恒定，Serverless 的优势就不明显。

5.2 让账单再降一个档位的几个优化手段

这几个优化点是我在账单出来后，一点点挤牙膏挤出来的，效果很实在：

手段一：按索引冷热启用不同 OCU 上限。 OpenSearch Serverless 允许为不同的 Collection 设置不同的 OCU 上限。实时写入的热数据 Collection 给足上限，应对突发；归档类的 Collection 把上限调低到 2-4 个 OCU，只保证偶尔的查询需求即可。

手段二：数据进入 OpenSearch 前先做压缩和裁剪。 很多日志的完整 JSON 里有一堆无用字段，进了 ES 就会占存储、拖慢索引速度。我在 Firehose 处理层就干掉了 env、version 这类低价值字段，日志体量直接减了 30% 以上。数据量下降，存储费和 OCU 费同步下降。

手段三：生命周期管理一定要配快照，而不是只配删除。 虽然在 Serverless 里不能直接挂快照仓库到自建 S3 再恢复——这块的权限链路比较绕——但把超过 30 天的索引自动迁移到低成本的冷存储归档，大概率能比全量热存省下 50% 以上的存储成本。原始数据本身就可以从 S3 备份桶里读取，无需在 ES 里长期保存全量历史。

6. 真实踩坑复盘：无服务器化 Elastic Stack 最容易翻车的五个环节

最后这部分，我把这半年在无服务器架构上部署 Elastic Stack 踩过的坑集中梳理一遍。每一个都有代表性，你大概率也会遇到。

6.1 冷启动造成的数据写入延迟与“伪丢失”恐慌

用 OpenSearch Serverless 之后，最直观的感受是——如果你的 Collection 闲置了一段时间，第一次写入时大概率会卡几秒，甚至十几秒，这就是冷启动。生产环境没有“闲置期”的概念还好，但测试环境常常整晚没有流量，第二天早上自动化脚本往里面灌数据时，就会超时、报错，你一看告警以为数据丢了。

排查后发现，其实数据只是没写进去，不是丢了。我的应对措施是在写入客户端设了更长的超时时间（至少 30 秒），并配合重试机制。真实生产建议：给你的数据链路加一层“保底批处理任务”，每小时跑一次，从 S3 备份桶对比数据量，发现差量就补写。

6.2 多租户隔离策略：Collection 越多，成本越失控

无服务器版天然适合做多业务线隔离，因为每个 Collection 有独立的计算资源。但你架不住接入方多，每个团队都申请一个 Collection，十几二十个 Collection 建下来，每个都有最低 OCU 消耗（通常最低是 2 个 OCU），光闲置成本就吓死人。

我后来强制推行了“业务线共享 Collection + 索引级权限隔离”的策略。也就是让多个业务写入同一个 Collection，用不同前缀的索引区分，再通过 Data Access Policy 限制各自只能访问自己的前缀。查询隔离效果不如独立 Collection，但成本能砍掉一半以上。对小团队来说，省钱比隔离更重要。

6.3 索引 Mapping 被锁死之后，只能重建索引

Serverless 和自建集群一样，索引 mapping 一旦创建就不能随意改字段类型，只能重建索引。自建集群可以直接原地 reindex，甚至改 mapping 后用 _update_by_query 刷一遍；Serverless 版我遇到的情况是 reindex 要占用 OCU 资源，数据量大时很容易把 Collection 打满，其他查询全部变慢。

所以，mapping 设计在进 Serverless 之前就要慎之又慎。尤其是日志里那些类型不确定的字段，宁可先统一用 keyword 存，也别让 ES 自动推断。等数据量大了再改，代价极高。

6.4 VPC 内访问的 DNS 解析延迟

如果你通过 VPC 终端节点访问 OpenSearch Serverless，DNS 解析偶尔会走公共 DNS 再绕回来，导致每次请求多出几十毫秒延迟。这个延迟对一次简单查询影响不大，但对高频的 Dashboard 刷新、告警查询就很不友好。

我后来启用了 VPC 内的 Private DNS，让终端节点的域名直接在 VPC 内解析，延迟降了一个数量级。控制台里启用 Private DNS 之后，原来的终端节点域名可以直接在 VPC 内访问，不需要额外改代码。

6.5 “看似更省”的 Lambda 直写方案，最后被高并发打脸

我知道有人为了省掉 Firehose 的费用，直接用 Lambda 消费 Kinesis 后调用 Bulk API 写 OpenSearch。在数据量小的时候，这套方案确实省钱、灵活。但当写入量涨到每秒几千条后，Lambda 的并发数会猛增，如果 ES 侧的写入能力跟不上，触发反压，Lambda 会一直重试，重试本身又占 Kinesis 的读取配额，恶性循环之下，数据堆积越来越严重。

这个方案的灵魂拷问是：你不是在省 Firehose 的钱，你是在拿自己的代码重写一遍 Firehose 的功能，还要自己处理背压、重试、死信、批量组装这些脏活累活。 除非量级小到可以忽视，否则别折腾。

最后分享一点个人体会

回到开头那句话，把 Elastic Stack 跑在无服务器架构上，本质不是技术上的炫技，而是运维策略上的重新分配。它把“管理服务器”这件事从你的工作清单里删掉了一部分，但同时也剥夺了一部分“掌控感”。你不能再去 SSH 到节点上看线程池状态了，也没法手动强制分片分配了，你要学会用平台提供的观测工具来指挥系统，而不是亲自动手拧螺丝。

以我这几轮实践下来的感受，如果你每天的数据写入量不超过 1TB，业务流量有明显的波峰波谷，团队里又没有专职的 ES 运维，无服务器架构这条路是值得走的，省下来的精力足以让你写好管道、调好查询、设计好权限，这些才是最终影响业务体验的东西。反过来，如果你已经在自建集群上沉淀了大量调优经验和自动化脚本，数据量又非常稳定，那继续用托管集群完全没问题，不必为了“无服务器”而“无服务器”。

最后分享一个比较隐蔽的小技巧：如果决定用 Firehose 投递 OpenSearch Serverless，记得要在 S3 备份桶的目录结构里把“年/月/日/小时”按业务时区分好。Firehose 默认按 UTC 做时间目录归集。我因为没有及时改配置，导致排查生产问题时，从 S3 里捞备份数据全部对不上本地时间，白白折腾了一个多小时。有些细节，只有在真实数据流里滚过一遍，才会知道它的分量。