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