作者 | 星巴克中国技术部日志平台团队

星巴克中国技术部日志平台团队经过近 1 年的日志集群迁移和升级，将维护支持星巴克中国的日志平台多个日志集群，数 PB 的数据，从 ES 版本从 7.8.X、7.9.X 跨大版本无缝升级至 8.X，从虚拟机架构部署模式迁移至云原生祼金属 k8s 平台部署模式。完成日志平台组件升级的过程中，也完成了日志平台的架构升级。从开始计划到执行完成，中间也遇到了很多的阻力和问题，经过团队技术攻坚，跨团队配合，新资源支持等方式解决了相关困难，完成之后我们回顾一路走来的付出和成就，确实有很多值得思考的地方，分享出来供大家参考。

2024 年 9 月开始计划，在不改变用户查询和提升用户体验的前提下，到 2025 年 6 月完成所有日志平台组件架构升级和版本迁移，在这中间的过程中，经历了 mapping 不兼容，字段类型冲突，查询上下文失效，重复消费误告警等诸多业内普遍存在的难题，最终实现了单机查询性能提升 80%，整体 cpu 下降 30%，写入 tps 提升 200%，用户也明显感觉到了查询性能提升带来的快感，本次分享从以下几个方面进行展开。

背 景

在数字化业务高速发展的当下，日志作为系统运行状态的 “全景镜像”，承载着业务监控、故障排查、安全审计、数据分析等核心场景需求，星巴克日志平台从 2017 年开始建设以来，存在一些架构设计不合理，日志查询缓慢，超时，丢日志等情况，用户体验不好。传统架构下的日志平台逐渐暴露出性能瓶颈：查询延迟超 10 秒、存储成本年增长率达 30%、跨集群数据协同效率低，难以满足业务对 “实时性”“低成本”“高可用” 的诉求。为此，技术团队启动全方位升级优化，通过架构重构、引擎升级、智能调度等手段，实现平台从 “能用” 到 “好用” 的跨越，为万亿级数据场景下的日志服务树立新标杆。

自 2024 年以来，日志平台团队开始逐步接手相关的平台建设工作，从日志采集组件（filebeat），日志接收（logstash producer）, kafka , 日志消费组件（logstash consumer）, ES 集群，数据存储模式，日志查询组件（kibana）,ES 多集群查询组件（CCS）等层面进行了逐个优化，下图为日志集群没有优化之前的架构模式图：

此架构存在以下问题：

ES 集群依赖远程网络存储，写入能力受到远程存储 io 资源限制，当时的数据量场景下，存储 io 带宽已经处于满载运行的状态，且扩容麻烦周期较长；

logstash-producer 和 logstash-consumer 单节点处理能力有限，两者占用了大量的计算资源，需进行优化或者技术演进，以提高效率和节约计算资源

远程存储容量即将达到安全线内使用上限，如果不进行优化，无法承接更多的业务日志接入，用户体验也经常收到业务反馈查询超时，日志延迟等投诉建议

各组件都是虚拟机部署，运维成本高，集群的可观测性，稳定性得不到保证。

在稳定性方面，因历史原因日志数据的数据清洗和存储方面没有最佳实践，没有合理的索引的模版结构和生命周期管理，索引分片和大小配置也没经过合理的优化，这样造成了数据查询超时，甚至部分节点内存溢出，资源使用倾斜情况等，用户体验非常不好。其次，存储使用的是远程网络存储，受远程存储性能的限制，造成 ES 集群写入和查询的资源受限，经常出现数据堆积，ES 查询队列居高不下，查询缓慢的情况；

基于以上原因，日志平台技术伙伴从技术层面和成本管理层面来考虑，经过团队对现有硬件资源情况，日志每天增量情况，早晚高峰期流量情况等方面的评估，在同等硬件资源的情况下，进行日志平台技术架构升级,，能够让日志的查询效率，日志高峰流量写入得到显著提升，可以缓解高峰时日志写入延迟，提高 ES 的写入能力方面等到优化，因此日志平台伙伴对日志平台进行了升级改造。

计划目标及面临的挑战

目标

日志平台伙伴根据实际的技术调研，跨团队配合情况，设定了详细的日志平台升级计划，保障每个关键节点实现相关里程碑成就，主要包括以下几点：

所有日志涉及的环境组件统一都迁移至云原生祼金属 k8s 平台引擎之上，即：日志平台涉及到的所有组件都需要容器化部署。

统一日志平台各组件的运行版本和交付标准, 实现日志数据采集、日志规则解析，数据入库等流程化体系建设。

资源分配合理化使用，对不同索引根据流量大小，高峰流量情况，业务活动情况，从采集，接入，解析，存储进行资源的精细化控制。

提升日志平台的接入能力，保证业务高峰期及活动保障期间不会有数据堆积和丢失情况。

提升用户数据查询服务体验，目标是 p99 查询

日志平台改造架构图如下：

与此前架构设计相比，本架构所具有的优势为：

所有组件都是容器化部署，运维相对简单，由之前在虚拟机上部署组件变为 operator 快速制备 pod, 组件交付效率提升 90% 以上；

producer 和 consumer 的组件由之前的 logstash 替换为 vector, 同等硬件资源下数据处理能力提升 2 倍以上；

ES 集群采用冷热角色部署，热节点使用本地磁盘，提高查询和存储速率，冷盘使用远程网络存储，可以最大程度使用已有资源，节约存储采购成本；

计算资源可以集中化管理和调度，提升资源利用率的同步，也使用资源可以快速的支持需要重保的组件；

挑战

如何保障用户体验？

在实际的集群升级过程中是不允许有数据丢失情况的，包括历史数据及新接入数据，用户查询界面也不能更换，即要在一个界面上进行新旧集群的日志查询，不能出现新集群数据在新界面查询，旧集群数据在旧界面查询的情况，另外，当时日志查询经常超时，用户经常反馈日志平台查询不到数据，查询缓慢，平台难用的情况，如何优化用户体验成为了日志平台伙伴面临的一个非常棘手的挑战。

如何解决数据积压问题？

远程网络存储 io 带宽已经达到写入瓶颈，io 带宽资源支持最高 4Gb/s, 但是高峰期已经超过这个流量，直接制约了 ES 集群的写入能力，这也是造成日志经常堆积，日志数据延迟的主要原因。

如何提升单个消费节点的写入能力？

消费组件 logstash-consumer 的规则解析比较多，单个节点的平均写入大约 1w/s 左右，而且单个节点占用资源为 32c 64g 的配置，涉及到大量的规则解析，所以性能受到严重影响，流量高峰期间需要启动大量消费节点进行数据写入，是日志集群除 ES 节点外最大的资源消耗组件，如何提升单个节点的写入能力，降低资源消耗成为技术伙伴攻关的主要挑战。

如何提升集群的存储能力？

集群硬件存储资源总共数 PB 左右，但是当时日志增量为每天百 TB 左右，日志保留时长一般为 30 天，有些业务日志由于业务原因需要保留 60 天或者 90 天，所以存储资源当时已经处于饱和的状态，总共数据量达到万亿级别，所以如何在不增加存储容量的情况下进行存储资源的优化，也是技术伙伴面临的重大挑战。

如何解决业务日志接入流程长的问题？

之前业务日志接入是按照业务组件名称，要从采集侧开始配置，再手动配置生产者，kafka 的 topic, 消费者及写入的索引名称，分片数量，查询别名及索引生命周期管理等，这一套流程手动操作下来要 2 小时左右，这也是在伙伴对流程比较熟练的情况下，但是我们接收到的新的日志接入每天大概 3-4 个，消耗在日志接入方面的人力成本非常多，如何优化日志接入流程成为了平台伙伴需要面临的挑战。

以上为主要面临的挑战，还有一些比如：业务组件如何对应索引名称和管理？人力资源有限的情况下，如何进行多集群的高效运维和管理？面对组件容器化之后，针对 ES 节点，kafka 节点等有状态节点出现故障之后如何快速恢复？集群各组件的可观测能力，告警能力，故障自动恢复能力等等，都是在集群升级过程中要面临的问题和挑战。

执行步骤

在开始实施前，我们按照以上问题的优先级进行了执行步骤的制定，对每个步骤的实施方案，期望达到的效果及预计的完成时间进行了详细的技术讨论，拆分如下：

迁移过程中如何保障用户体验

实施方案：

通过 ES 集群中的 ccs（Cross-Cluster-Search）的角色，可以实现 kibana 跨 ES 集群日志查询，由于资源的限制，新的中转集群开始只有 9 台物理节点，需要通过腾挪的方式，把旧集群的物理机逐步释放，再添加到新集群的方式完成硬件资源的迁移，由于初始的集群资源较少，所以迁移只能按照索引级别逐个迁移，涉及 200 多个索引，所以迁移周期比较长, ccs 支持多 ES 集群查询流程如下图：

但是新集群仍然面临写入远程带宽受限的问题，所以团队经过技术评估，决定新的 ES 集群使用本地盘 + 远程存储的方式，即在新集群中 hot 节点数据使用本地盘，数据保留时间为 7 天，cold 节点使用远程存储的方式，数据为 7 天之后 hot 节点迁移过来的数量，继续保存 23 天，以解决远程存储带宽受限及 ES 写入性能不足的问题, 新集群的所有组件均在 k8s 平台基于容器化部署的方式交付，本地盘通过 local storage 的方式挂载给到 ES 的 pod 使用。

预期效果：

用户在原有 kibana 平台可以通过索引别名的方式查询新旧集群的数据，新集群的 hot 节点数据查询明显变快，因为新集群的 hot 节点使用的是本地 nvme 存储，写入和查询的速率较快。

新集群的 ES 单个节点的写入性能明显提升，7 天内的数据查询 p99

使用本地磁盘代替远程网络存储的收益如下：

在单节点的性能优化中，我们主要优化了以下几个方面：

磁盘调度器根据硬盘硬件能力使用 noop 调度器或者 mq- deadline 调度器；

磁盘队列深度扩大数倍，以很好利用超大内存 JVM；

磁盘脏页比例和回写比例优化，减少频繁 IO 次数，提升吞吐量；

下图是单个物理机在 20w/eps 时的 iostat 性能图

从上图可以看出，使用本地磁盘存储代替远程存储，磁盘 io 性能得到了指数级提升。

如何解决数据积压问题

实施方案：

经过团队内部仔细梳理，发现在业务高峰期导致日志积压的因素有多种，具体归纳如下：

个别组件日志量瞬间太大，最高单个 topic 可达 15w/s，导致其它的索引写入和查询变慢

生产者发送 kafka 单条业务日志太大，占用较多的带宽资源

kafka 对应 topic 的 partition 的数量设置不合理，没有根据实际的数据量评估单个 partition 可以承载的流量

logstash-consumer 消费线程数量设置不合理，造成有些线程空轮询，有些线程繁忙的情况，表现总体消费能力持续的忽高忽低，消费能力很不稳定

索引的 shards 的数量设置不合理，建议单个 shards 的存储容量最高在 20-40GB 之间，但实际的情况是单个 shards 的数量达到 TB 级别，并且部分索引没有滚动策略，造成 shards 存储越来越大，直接影响了数据的查询和故障时索引的恢复时间

ES 写入线程数据及资源分配也不合理，对于部分集群冷热节点的资源没有合理规划，造成热节点在写入高峰期 cpu 资源不足，经常出现 cpu 打满，ES 写入队列居高不下的情况，影响 ES 的写入性能。

针对以上发现的问题，团队在进行集群迁移升级的过程，对集群的吞吐能力从不同组件的纬度进行了优化，具体实施步骤如下：

对采集侧发送到 logstash-procuder 的大流量业务日志数据进行采样策略，即按照百分比丢弃，这个可以 logstash-producer 逻辑里面实现，和业务沟通高峰流量日志会有单条日志被放大 7-10 倍的情况，即一条数据在同一个组件内部或者跨组件过程中，由于不同的逻辑处理被多次打印的情况，所以部分日志进行采样收集不影响业务排查问题。

对于单条日志过大的情况（单条业务日志大于 10MB）， 在 logstash-producer 中进行过滤拦截，并通知业务整改，这种单条数据量过大的日志收集没有实际的意义，因为 kibana 也查询不出来，浪费集群的计算和存储资源。

对于 kafka 中相关 topic 的 partiton 数量设置不合理，logstash-consumer 的线程数设置不合理，ES 的写入线程设置不合理，索引的 shards 数量设置不合理的情况，在实际的操作过程中通过压测找到合适的参数匹配关系，合理的利用集群的计算资源，比如针对大流量业务组件，如果 topic 的 partition 数量设置为 80， 如果单个 consumer 的 worker 线程数量设置为 10，那么最多只需要启动 8 个消费者节点就可以，因为单个 partiton 同一时间只能有一个消费者线程消费，诸如此类的细节的优化措施在实施过程中对集群的吞吐能力提升很大, 相关组件的参数调整及说明如下：

kafka 集群设置：

topic 分区设置规则：针对业务应用日志量大的 topic 分区：设置 45 个 (9 个 kakfa 节点，保证是 9 的倍数)，日志 topic 默认分区设置：9 个

kafka 参数主要参考批次大小，参数过大，导致 cpu，内存异常告警，设置过小导致 filebeat 事件活跃数高，日志写入延迟。

fetch.max.bytes: 30000000max.request.size: 31457280message.max.bytes: 41943040

vector 写入 ES 参数设置：

主要针对日志量大的业务，减少日志写入提交频次，降低 ES 写入队列：

batch:

max_events: 2000max_bytes: 20971520timeout_secs: 5compression: "zstd"

ES 索引模版参数优化设置：

"refresh_interval": "73s","mode": "logsdb","codec": "best_compression","routing": { "total_shards_per_node": "1" }

对于索引 shards 中存储数据比较大的情况，给索引设置合理的 shards 数量，shards 数量过多会占用更多的 ES 内存资源，过少会导致存储过大和写入性能问题，所以在实施过程中对每个索引进行了 shards 数量的优化，段合并优化，合理规划 shards 数量，制定索引的生产周期管理策略，在 shards 存储到达一定的水位之后自动滚动生成新索引，保证数据写入速率的同时，控制索引的存储容量。

预期效果：

通过限流的手段保障即使在流量高峰，也不会因为单个业务的日志量大拖垮集群的情况，从而缓解了流量高峰期日志查询缓慢，用户体验差的情况，通过对单条日志过大的治理，释放了集群的带宽和计算资源，为集群可以承载更多的流量提供了资源条件

通过对 kafka, logstash-consumer,es 等相关参数的优化，提升了 ES 的集群的数据吞吐能力，降低了日志在流量高峰期间出现频繁积压和延迟的情况，提升了集群的稳定性

通过对索引 shards 数量和存储容量的优化，提升了 ES 集群的写入能力，缩短了集群出现故障或者节点维护需要重启 ES 节点时的索引分片恢复的时间，进而保障了集群的可用性能力

如何提升单个消费节点的写入能力

实施方案：

在 ELK 的架构体系中，logstash 组件扮演着数据管道的角色，把数据从 filebeat 写入 kafka, 再把数据从 kafka 经过解析或者清洗写入 ES, 这种组件集群的方式在业界使用非常广泛，但是 logstash 是 java 实现，在进行大数据量处理时经常需要占用更多的 cpu 和内存资源，日志平台总资源只有数十台物理机，平台提供给 logstash 的计算资源达到 10 台，一半以上的计算资源被锁在 logstash-producer 及 logstash-consumer 上，其实也没有存在资源浪费的情况，只是数据处理的性能低下，1 个 32c64g 的生产者可以每秒发送 3-4w 条数据到 kafka, 而消费者的处理和写入能力也只有 1w/s, 因为要处理大量的日志数据字段解析，所以性能比不上生产者 结合以上情况，团队伙伴决定做技术演进，在技术调研的过程中，新兴组件 vector 进入了我们的视野，据官方压测数据，其性能是 logstash 的数倍以上，所以我们决定引入 vector 取代 logstash 组件作为集群中的管道组件，具体实施步骤如下：

把 logstash-consumer 先替换为 vector, 此过程要解决的问题就是解析规则的迁移和兼容性测试，消费者需要处理的解析规则大概有 3000 多条，都是根据实际的业务需求作的日志数据字段解析，方便业务伙伴检索从而快速排查和定位生产问题，由于规则解析的多样性，迁移过程中还要保障解析规则的正确性，团队伙伴在规则验证方面投入了很多精力，也沉淀了一些规则迁移和验证的工具，保证了规则迁移的完整性和数据正确性。

根据业务重要性及日志数据的大小对对所有消费的 topic 进行了分组消费，示意图如下：

从上图可以看出，在每一组内如果消费堆积，不会影响其它组的消费，只需要解决堆积的那个组的问题就可以，也可以对重点保障的业务所在的组投入更多的消费资源，做到了消费资源的精细化控制，也可以在活动期间对活动涉及到的业务组进行重点保障工作。

logstash-producer 替换为 vector, 因为生产者不涉及规则解析，只承担了数据转发和限流的功能，所以此部分的替换工作相对简单，但是 vector 本身的一些参数设置会影响其投递到 kafka 的速率，实际的替换过程中团队伙伴也是沉淀一些参数配置的最佳实践。

预期效果：

通过 vector 组件的引入及日志数据解析规则的迁移，在同等 cpu 和内存资源配置下，单个生产者的写入速率最高可达 10w/s, 比 logstash-producer 提升 3-4 倍，资源节约近 50%，同时生产者的限流能力也得到了平滑的迁移， 单个消费者消费和写入 ES 能力提升到 3-5w/s, 比 logstash-consumer 提升 2-3 倍，资源节约 60% 左右，为集群支持日志数量增长提供了资源支持

分组消费的优化也把堆积影响范围进一步缩小，使问题影响面变得更加可控和可快速定位及处理，方便了活动日的集群稳定性保障，由于每个组内的消费者节点数量都可以单独控制，极大方便了计算资源的动态调度，保障了集群的稳定。

如何提升集群的存储能力

实施方案：

日志集群的总存储资源在团队接手管理时存储容量已经使用 85% 以上，而且每天不断有新增的业务组件需要接入日志集群，在存储硬件资源受限的情况，在业务日志保存时长不受影响的情况下，如何对现有的存储逻辑进行优化，释放更多的存储空间，进而承接更多的业务日志接入也成为了团队需要亟待解决的问题，经过团队伙伴的共同努力，发现可以进行存储优化的点有两处：

kafka 存储优化，kafka 的存储数据没有进行压缩设置，单个集群内有 9 个 kafka 节点，同时 kafka 对数据有副本机制保障高可用，所以在保证磁盘使用率控制在 80% 以下的情况下，kafka 可以保存的时长只有 4 个小时，这个时间要求团队伙伴如果在集群出现问题时，处理和恢复时间不能超过 4 个小时，否则数据丢失风险很大。

ES 集群对索引存储没有开启压缩算法，据了解，这里主要原因是开启压缩会占用更多的 cpu 资源，集群本来资源就非常有限，处理数据写入已经占用了大量的资源，经常会有写入堆积，还开启压缩功能就会适得其反，影响集群吞吐，ES7.9.x 版本开启 gzip 压缩可以压缩 30% 左右，但是新版本的 ES8.x 支持 zstd 压缩，压缩比可达 40% 左右，但是，想要开启 ES 数据压缩能力，就必需提升 ES 的吞吐保证不会积压的同步，提供更多的计算资源给到 ES 集群，针对以上两点，团队伙伴进行了如下的实施方案：

对 kafka 进行存储优化，首先，对不再使用的 topic 进行清理，对流量小的 topic 进行合并。其次，对 kafka 数据落盘进行压缩，减少磁盘空间的占用，对日志的存储时长进行延长，保证在集群出现问题时有足够和时间处理，不会出现因集群故障，kafka 日志过期导致数据丢失的情况。

对 ES 集群进行压缩算法开启，在上面的 logstash -> vector 的组件演进过程中已经提升了 ES 集群的吞吐量，释放了足够的硬件资源，可以支持 ES 集群开启压缩能力，至此，集群资源利用出现了正向循环，首先对旧的 7.9.x 的版本直接开启 gzip 压缩，对新集群开启 zstd 压缩。

预期效果：

通过对 kafka 集群的治理和优化，kafka 集群在存储容量不变的情况下，数据保留时间由之前的 4 小时延长到了 8 小时，数据压缩效率明显，数据存储容量下降 50%，为集群的故障处理争取到了更多的处理时间，但实际情况是故障恢复也没有出现处理过长时间的情况，但是承接了更多的业务日志接入，在没有增加硬件资源的情况下，kafka 层面解决了日志增长对存储压力的问题。

通过对新旧 ES 集群开启压缩算法，旧集群存储容量减少了 30%， 新集群的容量减少了近 50%，整体存储容量下降了 40%， 在不断的新增业务日志接入的情况下，取得了预期存储治理的目的，为后面可以承接更多的新境日志接入腾出了足够的存储空间，节约了公司存储资源采购的成本。

下表是使用不同 ES 版本索引同一份数据的存储空间测试对比：

从表中数据可以看出，开启压缩前后在不同的 ES 版本中存储容量均有明显下降。

如何解决业务日志接入流程长的问题

实施方案：

日志接入从应用到 ES 需要经过多个组件，涉及到业务应用跟 topic 映射配置，topic 跟日志索引映射配置，针对不同的应用日志需要设置单独的索引生命周期，分片数，索引模版以及查询模版。整个日志接入流程下来，需要大概花费耗时 2 小时。原来整体日志接入流程如下：

在经过日志索引规范治理后，团队对日志接入流程进行了分析以及流程优化，基本能实现日志流程接入自动化。实施步骤如下：

业务应用上线提交工单申请，在工单提供集群，应用分区，应用名称，日志保存时长等信息。工单审批通过后订阅 ELK 系统接口，将参数传到 ELK 平台。

ELK 平台接收到应用上线信息，通过应用分区，应用名称自动生成 topic 名称，topic 生成规则：prod-container_ 应用分区。将生成的配置更新业务应用 topic 映射表，vector 生产端定时更新配置写入 topic。

vector 消费端，脚本读取业务应用 topic 映射表，判断是否有新生成的 topic，有的话将生成的 topic 跟索引配置更新到 vector 消费配置里面，且调用 ES 接口创建新索引模版，初始化新索引。vector 消费端定时更新配置写入 ES 集群。

调用 ES 接口，判断是否有新初始化的索引，如果有，调用 kibana 接口创建查询索引。

预期效果：

人工操作时间：单个应用服务从 2 小时 → 5 分钟（无人值守）

接入应用量：单批次支持多个应用同时接入, 减少人工一个个应用接入。

配置一致性：避免人工错误。

成果与体会

成果总结：

经过 3 个月的升级与验证，日志平台的性能、成本、可用性均实现显著突破，核心指标如下：

用户查询 P99

集群吞吐能力得到的增强，由之前的 45w/s 提升到 90w/s, 吞吐能力提升近 3 倍，满足当前日志平台高峰期流量写入，很少再出现日志积压和消费延迟的情况；

存储压缩能力提升了 50%，容量降低了 50% 左右，较大的节省了硬件资源成本。

集群稳定性得到极大提升，之前只要是早晚业务高峰，集群就会有问题，积压问题，存储问题等等，由于可观测和告警能力的建设完成，稳定性的问题也很少出现，给业务伙伴排障提供了很好的支持。

体会与感悟：

日志系统升级初期面临诸多问题，业务所有告警策略全部都是通过查询日志索引，稍有考虑不到地方就可能会引起大量误告警，给日志升级方案设计带来了很大的挑战，同时还要兼顾业务诉求，平台使用无感，数据不能丢失等，需要考虑诸多因素，团队伙伴在保障日志平台平滑升级过程中付出了诸多努力。

因为星巴克的业务场景原因，日志平台所有的升级动作都必须要在晚上 10：00 以后进行，不能影响正常白天业务日志的查询，为此，团队伙伴经常作业到凌晨以后，现在回头再看，正是团队伙伴兢兢业业的奉献，才能使日志平台升级工作顺利完成，正是团队伙伴熬过的每一个夜晚，才换来了业务伙伴对日志平台体验提升的一次次肯定。

日志平台是一个多组件构成的复杂系统，升级优化需要考虑每个组件在流程中的贡献和作用，以及可能的优化空间，各组件的参数使用需要上下游连动，全流程优化也需要考虑整个系统的木板效应，过程复杂且具有挑战性，只有坚实的做好每一项的优化，才能得到整个系统的性能提升。

未来发展规划

架构优化降本增效：依托全自动化日志接入流程的技术，推动采集层架构升级，实现 filebeat 采集器结合 CMDB 自动路由写入 Kafka 消息队列的闭环链路，精简现有架构中 logstash 与 vector 生产者的中转环节，显著降低计算资源占用率，进一步优化平台整体运营成本。

生态化整合：打通日志平台与 APM、监控平台的数据壁垒，构建 “日志 - 监控 - 告警” 一体化运维体系，实现从 “被动排查” 到 “主动预防” 的转型。

智能搜索深化：引入大语言模型（LLM），支持自然语言查询日志（如 “查询今日 dpfm 接口错误日志”），降低业务人员使用门槛。

今日好文推荐