导读：阿里云 Elasticsearch 新版本推出日志采集与加工服务，将多源接入、流量缓冲、数据加工和可靠投递整合为云上托管能力，并与已有的写入优化、低成本存储和高性能查询能力形成完整链路，让海量日志处理变得更简单、更完整。
我们只是想查日志，为什么要维护这么多组件？
大促前一周，研发负责人小王把日志平台架构图投到会议室大屏上。应用日志先由采集器读取，进入 Kafka 削峰，再由 Logstash 解析、清洗和转储，最后写入 Elasticsearch。为了让这条链路稳定运行，团队还要持续维护 Topic、Partition、Consumer Group、加工 Pipeline、积压监控、扩缩容脚本和版本兼容清单。
CTO 看着满屏组件问：“我们的目标不是让日志可以被检索和分析吗？为什么数据还没进入 Elasticsearch，就已经需要维护一套这么复杂的系统？”
小王没有立刻回答。因为他知道，Kafka、Logstash 等组件并非多余：流量高峰需要缓冲，网络抖动需要重试，原始日志需要解析加工，目标集群也可能短时限流。真正的问题在于，这些必要能力长期以来只能由团队自行拼装、扩容和排障。团队想要的从来不是更多组件，而是一条能够稳定接住日志、处理日志并可靠送达 Elasticsearch 的托管链路。
现在，这条链路有了新的选择。
阿里云 Elasticsearch 日志采集与加工服务：为日志采集链路做减法
阿里云 Elasticsearch 新版本新增日志采集与加工服务，它不是单一采集器，而是一套从数据接入、流量缓冲、内容加工到可靠写入的托管系统。用户创建日志写入任务并指定目标 Elasticsearch 实例后，服务生成专属 Endpoint；现有 OTel Collector、Beats 或 Logstash 只需将输出端指向该 Endpoint，即可接入托管链路。
数据进入云端后，服务先通过托管消息队列承接流量，再由 Processor 执行多行合并、字段解析、内容过滤、格式转换和上下文补齐，最后通过可靠投递机制写入目标集群。接入、缓冲、加工和投递能力可在服务侧统一扩展，用户无需再为每个环节分别准备 Kafka 集群、Logstash 资源和运维工具。
这套服务做的是采集端和 Elasticsearch 之间的链路托管，不会改变用户已有的采集拓扑和查询习惯。业务侧继续选择适合自己的采集组件，查询侧继续使用 Elasticsearch DSL、Kibana Discover 和 Dashboard；真正由云服务承接的，是中间链路中最繁重的容量规划、流量缓冲、加工资源管理、失败重试和故障恢复工作。
1. 多源接入：让 OTel、Beats 和 Logstash 进入同一托管入口
企业的日志采集环境往往由多代技术栈共同组成：云原生应用开始采用 OTel Collector，主机和容器中仍运行着 Filebeat 等 Beats 组件，部分复杂链路则已经沉淀了 Logstash Pipeline。阿里云 Elasticsearch 日志采集与加工服务同时支持 OTel Collector、Beats 和 Logstash 接入，让新应用与存量系统可以继续选择适合自身的采集方式，不必为了使用托管服务先统一替换采集端。
统一入口也不会抹平不同采集方式已经携带的上下文。OTel 日志中的service.name、trace_id、资源属性和时间戳，以及 Beats、Logstash 已经采集或解析出的字段，都可以随日志进入后续加工流程。迁移存量链路时，用户主要调整发送端的输出目标即可；新旧采集方式可以并行接入同一服务，业务无需重写日志生成逻辑，也不必一次性改造全部采集配置。
2. 托管消息队列：把削峰填谷做成服务能力
我们在专属 Endpoint 和目标 Elasticsearch 之间引入托管消息队列，将采集速度与下游写入速度解耦。大促、故障、应用发布和批处理任务带来的突发日志先进入云端缓冲，再按照下游承载能力平滑投递，避免瞬时洪峰直接冲击目标集群，也降低发送端因短时限流或网络抖动产生大规模积压的风险。
传统方案为获得同类能力，通常需要搭建 Kafka，再由 Logstash 消费、解析并转储到 Elasticsearch。虽然能够实现持久化缓冲，却同时引入 Broker、Topic、Partition、Consumer Group、容量水位、积压告警和 Pipeline 版本等长期运维对象。
日志采集与加工服务将缓冲削峰、数据加工和可靠投递统一纳入托管链路，将用户需要关注和维护的范围收敛至采集配置与目标 Elasticsearch 集群。用户无需自建 Kafka、部署 Logstash，也无需持续承担中间层的容量规划、积压处理和故障恢复，削峰填谷由此从一套需要独立建设和运维的系统，转化为随采集任务直接获得的服务能力。
3. 基于 AI Agent 的配置生成：让 Agent 帮你完成采集与加工配置
多种采集方式解决了不同采集端的兼容问题，却没有自动消除配置门槛。不同运行环境需要选择不同 Receiver，不同日志样例需要配置多行规则、字段解析和属性补齐，Exporter 还要正确匹配任务 Endpoint 与鉴权信息。以往这些工作依赖工程师在文档、组件仓库和历史模板之间反复拼装。
我们将日志采集与加工领域知识沉淀为 Agent Skill。用户提供运行环境、日志路径或样例、格式特征、采集方式和目标实例后，Skill 可以生成与专属 Endpoint 匹配的 OTel 或 Beats 配置，并针对多行异常栈、字段提取、过滤规则和上下文补齐给出相应的 Processor 配置建议。
用户无需从空白配置起步，通过与 Agent 交互生成推荐配置，经过必要的校验、调整及测试环境验证，即可发布至生产环境。接入过程由反复查阅文档、拼装模板，简化为“描述环境与日志、生成配置、校验并上线”；后续新增字段或调整采集环境时，也可在现有配置基础上持续迭代。
Agent Skill 的价值不止于生成配置，更在于将日志采集与加工的产品知识和工程经验沉淀为 Agent 可调用的领域能力。Agent 可以结合运行环境与日志样例解释配置依据、辅助调整处理规则并支撑后续迭代，使专业能力更直接地服务于日志接入和持续维护。
与自建日志采集链路的对比
日志采集与加工服务带来的变化，并不只是少部署几个中间组件，更重要的是将接入、缓冲和加工等链路能力交由云端托管，同时简化配置与排障，使各环节的责任边界更加清晰。
在典型日志链路中，这套服务可使日志采集综合成本降低30%+。这里的成本既包括 Kafka、Logstash 等中转资源，也包括规则维护、字段加工、扩缩容、积压排查和版本兼容带来的长期人力投入。
CTO 看完五个维度的对比后说：“不错，接入、缓冲、加工和运维的责任边界清晰了，采集链路也明显简化了。但一套完整的日志平台，还要继续面对高峰写入、长期存储和并发查询等挑战，这些环节如何兼顾性能与成本？”
采集与加工解决的是日志进入 Elasticsearch 之前的链路问题。围绕后续的写入、存储和查询，阿里云 Elasticsearch 已形成系统化解决方案，并与上游采集能力共同构成完整的日志链路。
阿里云 Elasticsearch 日志全链路解决方案
日志经过托管链路加工后，由可靠投递机制送入目标 Elasticsearch 的写入入口。当用户按业务场景启用相应能力时，Indexing Service 负责承接高并发写入与索引构建，OpenStore 负责海量日志的低成本长期留存，Analytic Search 则优化日志浏览、并发检索和聚合分析。采集、写入、存储和查询由此形成前后衔接的完整链路。
写入高峰来了，查询不必一起变慢
日志写入天然存在峰值波动。大促流量、故障风暴、应用发布和批处理任务都可能在短时间内产生大量 Bulk 请求。在传统 Elasticsearch 集群中，写入、refresh、segment merge 与查询共享数据节点的 CPU、内存和磁盘 IO；写入越繁忙，Kibana 查询和 Dashboard 刷新越容易受到影响。单纯扩容数据节点虽然能够缓解压力，却会把写入与查询两类资源需求继续绑定在一起。
阿里云 Elasticsearch Indexing Service 将高并发写入和索引构建交给云端写入托管服务。日志 Bulk 请求先进入用户集群协调节点，再转发到写入托管服务；服务内部通过定向路由、不存主键、原文压缩等优化构建 segment，用户集群随后通过物理复制机制拉取数据。查询仍在用户自己的 Elasticsearch 集群中执行，原有查询入口和使用方式不变。
Indexing Service 让写入和查询各司其职：索引构建、合并等写入相关任务交给写入托管服务，用户集群可以把更多 CPU、内存和磁盘 IO 留给检索分析，避免“写得越多，查得越慢”。写入托管服务还针对日志写入进行了多项性能优化，让更少的资源承载更高吞吐。同时，写入托管采用按量计费，无需按照峰值吞吐长期维持大规格集群。经实测，使用 Indexing Service 后，写入计算资源成本平均可降低60%（官方文档）。
日志留得更久，成本不必同步增长
日志的访问频率通常随时间快速下降：最近几小时的数据经常用于告警确认和故障排查，几个月前的数据访问频率已经很低，却可能因为审计、合规、安全调查或客户投诉而必须长期保留。若所有数据始终放在高性能云盘上，留存周期越长，成本增长越明显；若将数据转为离线归档，真正需要追溯时又要经历恢复、重建和再次导入。
OpenStore 通过存算分离、多级缓存和对象存储承接这类冷热分明的日志数据。高频访问数据可以获得本地缓存加速，低频历史数据则沉淀到更具成本优势的对象存储中，对上层仍然保持统一的 Elasticsearch 查询入口。用户不必在“高成本在线保存”和“归档后无法直接查询”之间二选一，也无需额外维护复杂的冷热迁移和恢复链路。
OpenStore 在兼顾查询性能的前提下，显著降低了日志长期留存成本。相比 ESSD 云盘，其存储成本可降低40%+（官方文档）。对于需要将日志留存周期从 7 天延长至 30 天、180 天甚至更久的团队，这意味着不必再在留存周期与存储预算之间反复取舍，长期在线留存也可以成为日志平台的常态能力。
数据越多，查询入口越要保持稳定
日志查询并不只是搜索一个关键词。工程师可能先在 Discover 中浏览原文，再按服务、接口、租户和状态码过滤；也可能使用date_histogram观察异常趋势，继续进行 doc values 读取、分组统计和多层聚合。线上问题定位时，多个团队往往同时提交重查询，查询稳定性比平时更加重要。
Analytic Search 针对这些路径提供并发查询、Discover 查询加速、聚合执行优化和慢查询隔离等能力。并发查询可以将查询任务拆分为多个范围并行召回，再汇总完成聚合分析；Discover 查询加速可减少高频日志浏览的等待时间；聚合执行优化降低复杂分析中的热点开销；慢查询隔离则避免少量异常请求持续占用资源，影响其他用户的正常排障。
典型日志场景测试显示，并发查询可使召回阶段平均耗时降低50%（官方文档）。面对更复杂的业务查询，阿里云 Elasticsearch 还可以结合索引结构、字段类型、查询 DSL、聚合路径、数据分布和资源状态提供专家级支持。优化目标不只是缩短某一次查询的耗时，更是在高写入、长留存和复杂聚合同时存在时，持续保障稳定的查询体验。
让每一条日志，采得稳、写得快、存得省、查得准
以上能力共同构成阿里云 Elasticsearch 面向日志场景的全链路解决方案，覆盖日志采集与加工、写入、存储、查询分析等关键环节。在典型日志场景下，各环节的能力与收益具体体现在以下几个方面。
采集：日志采集与加工服务通过多源统一接入、托管消息队列、云端加工与可靠投递简化上游链路，日志采集综合成本可降低30%+。
写入：Indexing Service 通过读写分离将索引构建及合并交由写入托管服务，并结合多项写入优化与按量计费，写入计算资源成本平均可降低60%。
存储：OpenStore 通过存算分离与对象存储支撑海量日志长期在线留存，在兼顾查询性能的同时，存储成本可降低40%+。
查询：Analytic Search 以并发查询、Discover 查询加速、聚合执行优化和慢查询隔离提升检索分析效率，并发查询召回阶段平均耗时可降低50%。
各项能力既可按需启用，也可协同工作，让日志平台在数据规模、留存周期和分析复杂度持续增长时，仍能兼顾稳定性、性能与成本效率。
拥抱 AI，让 Agent 能力逐步走向日志全链路
AI 时代，用户与日志平台的交互正在从围绕组件和参数进行操作，逐步转向描述目标并获得可执行建议。阿里云 Elasticsearch 日志服务也在朝这一方向演进：将 Agent 的理解、生成与分析能力融入现有产品，把产品知识、最佳实践和专家经验转化为可调用、可审核的智能能力，帮助用户更高效地接入日志、使用产品和分析问题。
目前，日志采集与加工 Agent Skill 已率先落地。用户只需描述运行环境、日志样例、采集方式和目标实例，Agent 即可生成 OTel 或 Beats 接入配置及 Processor 加工建议，并提示路径、权限、正则表达式和资源参数等需要校验的关键项，帮助用户更快完成日志接入。这标志着阿里云 Elasticsearch 不仅提供日志产品能力，也开始通过 Agent 帮助用户更好地使用这些能力。
以此为起点，Agent 能力还将逐步向写入、存储和查询等环节延伸：写入侧，辅助完成 Indexing Service 选型、索引与分片规划以及写入问题分析；存储侧，结合留存周期、访问热度和成本目标提供 OpenStore 策略建议；查询侧，将分析意图转化为可审核的 Elasticsearch DSL，并辅助识别慢查询、执行瓶颈和关键日志线索。相关能力将在可解释、可审核和权限受控的前提下持续演进，让 Agent 逐步成为用户建设、治理和使用日志平台的智能助手。
让日志链路少一串组件，多一份稳定
阿里云 Elasticsearch 日志全链路解决方案已在日志写入、存储、查询等方面进行了多项深度优化。新版本发布的日志采集与加工服务又补齐了关键一环，使从日志接入、加工、写入到长期留存和检索分析的全链路更加完整。当下一次大促到来，或线上问题需要紧急定位时，小王可以把更多精力放在业务运行状态和日志线索本身。让日志链路少一串需要维护的组件，多一份可以依赖的稳定性，正是这项新能力带来的价值。
目前，阿里云 Elasticsearch 7.10 和 8.17.0 版本已支持日志采集与加工服务，9.4.0 版本也即将开放支持。其中，OpenTelemetry Collector 当前仅支持 8.17.0 版本，并将在 9.4.0 版本开放后同步支持。欢迎前往阿里云 Elasticsearch 控制台体验。具体适用范围、开通方式、配置方法与操作步骤，请参阅日志采集与加工服务文档。
