无服务器架构 + Elastic Stack：日志管道实战指南

做日志平台或者数据管道的人，最近几年基本绕不开两个词：Elastic Stack 和无服务器架构。前者是 ELK 那套生态，从 Elasticsearch 做存储检索、Kibana 做可视化，到 Beats/Logstash 做采集加工，已经是日志领域的事实标准；后者则是把基础设施的运维压力尽量外包，按需运行、自动伸缩，让开发者把精力放在业务逻辑上。

我见过不少团队一开始很兴奋，觉得“无服务器 + Elastic Stack”一定很爽，结果一落地就被连接超时、索引爆炸、费用失控这些问题折腾得够呛。也有团队走了很好的路子，整个日志管道跑在事件驱动架构上，平时零成本，流量高峰自动扛住，根本不用半夜爬起来加节点。差别在哪？差别在于有没有把这两个东西真正拆开想清楚：哪些是 Elastic Stack 擅长的，哪些是无服务器架构擅长的，以及它们之间的衔接点到底在哪里。

这篇文章不打算做概念科普，而是按我实际落地过的方案，从架构拆解、选型思考、代码实现到排坑记录，系统梳理一遍 Elastic Stack 与无服务器架构组合时的核心要点。不管你是刚接触这个组合，还是已经踩了不少坑，这版指南应该都能给你一些能直接拿走用的东西。

1. 为什么要把 Elastic Stack 和无服务器架构组合起来

1.1 先说清楚两个东西各自解决什么问题

Elastic Stack 表面上是一套“日志系统”，但它的核心能力其实是三个：分布式存储、全文检索、可视化分析。Elasticsearch 负责把数据倒腾进索引里，Kibana 负责把索引里的数据变成图表、告警和排查界面，Logstash 和 Beats 负责把数据从源头搬进来。这套组合强就强在“数据一旦进去，怎么查都方便”，弱也弱在“它是典型的有状态服务，节点要维护、容量要预估、峰值要预留”。

无服务器架构的核心不是“没有服务器”，而是“你不用管服务器”。代码跑在按需分配的执行环境里，平台负责伸缩、负责高可用，你只管写函数、配触发器和关注账单。常见的形态包括 FaaS（函数即服务）、事件驱动的数据处理管道、托管数据库/托管搜索服务等。

两个东西放一起，其实解决的是一对天然矛盾：Elastic Stack 需要稳定的写入和查询能力，但日志流量往往是脉冲式的；无服务器架构擅长处理脉冲式流量，但自身不擅长做有状态的数据存储和检索。所以最合理的组合方式是：用无服务器架构解决“数据怎么来、怎么预处理、怎么缓冲”，用 Elastic Stack 解决“数据放哪里、怎么查、怎么看”。这正好互补。

1.2 先别急着为了潮流硬上

我要先泼一盆冷水：无服务器架构不是银弹，有些场景真的不适合硬上。

如果你有一个 7x24 小时都在高吞吐写入的日志管道，流量曲线非常平稳，比如每天固定几百 GB 数据持续不断进来，那用一组常驻的 Filebeat + Logstash + Elasticsearch 反而是更划算、更省心的方案。因为无服务器按调用次数和运行时长计费，持续高的流量算下来费用可能比几台按年付费的 EC2 还贵，而且冷启动和平台限制反而成了瓶颈。

但反过来，如果你的日志流量有巨大的波峰波谷，比如白天业务高峰有大量写入、凌晨基本静默，或者你经常要临时接入新数据源、新格式日志，不想为这种偶发性需求维护常驻采集节点，那无服务器架构的优势就非常明显了。没有请求时零成本，有请求时自动伸缩，弹性上限几乎可以认为“无限”。

我自己的判断标准很简单：看流量曲线是否平稳，看运维人力是否充足，看是否需要快速接入新数据源。满足两个以上“不确定、波动、没人管”的条件，就值得用无服务器方案。否则，老老实实用传统部署。

2. 核心架构设计：无服务器日志管道怎么搭

2.1 整体链路：从业务日志到 Kibana 可视化

我们团队在实际项目里落地过一套比较典型的无服务器日志管道，整体链路大致是这样的：业务应用把日志写到云平台的对象存储或日志服务里，然后通过事件通知触发一个无服务器函数，函数负责读取原始日志、做格式清洗和字段裁剪，最后批量写入 Elasticsearch。Kibana 负责对外展示。

为什么要用事件通知来触发，而不是让函数轮询？因为事件驱动才是无服务器的正确使用姿势。对象存储一旦有新日志文件写入，立刻产生事件，函数被自动调用。没有新文件时函数一个都不会执行，成本直接归零。如果用轮询，哪怕没有数据也要定时运行函数，费用白交，而且处理延迟还高。

这套链路的优势在于每个环节都是独立伸缩的。日志量突然增长十倍，对象存储扛得住，函数自动并发执行，Elasticsearch 那边只要分片设计和写入限流合理，也能平滑吃下。整个过程不需要人工介入，不需要预先扩容，真正做到“流量来了才花钱”。

2.2 组件选型：日志来源、触发方式、目标端

组件选型是整个方案里最容易纠结的部分。我按实际经验把常见的选型分成了三层。

日志来源层，最常见的是对象存储文件、云日志服务（CloudWatch Logs、阿里云 SLS 这类）、消息队列。这三者的选择直接决定后续函数怎么写。对象存储适合大批量日志文件归档，触发粒度是“文件级别”；云日志服务适合实时性要求高的场景，触发粒度是“日志条目级别”，但费用通常更高；消息队列则适合你已经有一套独立消息系统的场景，灵活度最高，但需要自己处理消息消费位点和重试逻辑。

触发函数层，主流选择是 FaaS 平台自带的日志/对象存储触发器，或者消息队列消费者。这一步没有太多炫技空间，关键是要理解你用的平台的触发事件结构，因为不同的平台传进来的事件字段完全不一样，解析方式也完全不同。

目标端，即 Elasticsearch 部署形态，这个问题我单独拿出来说，因为太多人在这里踩坑。

如果让我给建议，中小团队优先考虑云厂商托管 Elasticsearch，核心是把精力放在业务和数据