导读阿里云 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 控制台体验。具体适用范围、开通方式、配置方法与操作步骤请参阅日志采集与加工服务文档。