作者 | 百度智能小程序团队

导读

本文首要介绍了分布式服务下日志服务建设的应战，然后介绍了下业界ELK的通用处理计划及与天眼日志服务的差异性，接下来详细介绍了天眼日志服务渠道的全体架构，如何做收集、传输、检索、阻隔、整理等机制的，最后对日志服务与大模型进行结合，不断探究效能的提高。

全文11796字，预计阅读时刻30分钟。

01 分布式服务下日志服务应战

分布式服务体系中，每个服务有很多的服务器，而每台服务器每天都会发生很多的日志。咱们面对的首要应战有：

1、日志量巨大：在分布式服务环境中，日志分散在多个节点上，每个服务都会发生很多的日志，因而需求一种可靠的机制来收集和聚合日志数据。

2、多样化的日志格局：不同的服务或许运用不同的日志格局，例如日志输出的字段、次序和等级等，这会添加日志服务的开发和维护难度。

3、日志服务的可扩展性和可靠性：跟着分布式服务数量的添加和规模的扩展，日志服务需求能够进行横向扩展和纵向扩展，以确保其功用和可靠性。

所以咱们该如何供给分布式体系下高效、低推迟、高功用的日志服务呢？

02 业界ELK通用处理计划

2.1 Elastic Stack开展历程

2.2 Elastic Stack组件架构图

2.2.1 Ingest组件

Ingest 是获取日志数据的相关组件。

shippers 和sources是收集的原始日志组件，接受着原始日志（log文件日志、体系日志、网络日志等）收集和发送，其间 Elastic Agent、APM、Beats 收集和发送日志、目标和功用数据。

queues 和processors是原始日志数据的处理管道，运用这些组件能够定制化的对原始日志数据进行处理和转化，在存储之前能够模板化数据格局，便利elasticsearch更好的接受存储和检索功用。

Elastic Agent 是一种运用单一、共同的办法，为主机添加对日志、目标和其他类型数据的监控。它还能够维护主机免受安全要挟、从操作体系查询数据、从长途服务或硬件转发数据等等。每个署理都有一个战略，能够向其间添加新数据源、安全维护等的集成。

Fleet 能够会集办理Elastic Agent及其战略。运用 Fleet 能够监控一切 Elastic Agent 的状况、办理agent战略以及晋级 Elastic Agent 二进制文件或集成。

Elastic APM 是一个根据 Elastic Stack 构建的运用程序功用监控体系。经过收集有关传入恳求、数据库查询、缓存调用、外部 HTTP 恳求等呼应时刻的详细功用信息，实时监控软件服务和运用程序。

Beats 是在服务器上作为署理安装的数据发送器，用于将操作数据发送到 Elasticsearch。Beats 可用于许多标准的可观察性数据场景，包含审计数据、日志文件和日志、云数据、可用性、目标、网络流量和 Windows 事情日志。

Elasticsearch Ingest Pipelines 能够在将数据存储到 Elasticsearch 之前对数据履行常见的转化。将一个或多个“处理器”使命装备为按次序运转，在将文档存储到 Elasticsearch 之前对文档进行特定更改。

Logstash 是一个具有实时数据收集引擎。它能够动态地共同来自不同来源的数据，并将数据规范化到意图地。Logstash 支撑丰厚的输入、过滤器和输出插件。

2.2.2 Store组件

Store 是接受日志存储和检索组件，这里是运用的Elasticsearch接受该功用。

Elasticsearch 是 Elastic Stack 中心的分布式查找和分析引擎。它为一切类型的数据供给近乎实时的查找和分析。不管结构化或非结构化文本、数字数据仍是地舆空间数据，Elasticsearch 都能够以支撑快速查找的办法高效地存储和索引这些数据。Elasticsearch 供给了一个 REST API，使您能够在 Elasticsearch 中存储和检索数据。REST API 还供给对 Elasticsearch 的查找和分析功用的拜访。

2.2.3 Consumer组件

Consumer 是消费store存储数据的组件，这里组要有可视化的kibana和Elasticsearch Client。

Kibana 是利用 Elasticsearch 数据和办理 Elastic Stack 的工具。运用它能够分析和可视化存储在 Elasticsearch 中的数据。

Elasticsearch Client 供给了一种便利的机制来办理来自语言（如 Java、Ruby、Go、Python 等）的 Elasticsearch 的 API 恳求和呼应。

2.3 天眼比照ELK差异

1、接入快捷性

ELK：计划依靠完好流程布置准备，操作装备杂乱，接入跑通耗时长。

天眼：只需简略三步装备，页面请求产品线接入、页面获取产品线appkey、依靠办理中添加天眼SDK依靠并装备appkey到体系装备中。

2、资源定制化

ELK：资源修正、装备每次都需求重启才干收效，不支撑多资源装备化挑选。

天眼：产品线接入时能够挑选运用事务本身传输、存储资源或自动运用体系默许资源，资源切换只需页面简略装备并即时自动收效。

3、扩容本钱与功率

ELK：计划仅支撑单个事务产品线，其他事务产线接入需重新布置一套，资源无法同享，扩容需手动添加相应实例等。

天眼：资源会集办理，产品线动态接入，资源动态装备即时收效，大部分资源自动同享一起又支撑资源独享装备；扩容直接经过渠道页面化操作，简略快捷。

4、日志动态整理

ELK：依靠人工发现、手动整理和处理资源占用。

天眼：自动化监测ES集群概略，自动核算资源占用状况，当达到监控阈值时自动履行时刻最早的索引资源整理。

5、自适应存储

ELK：传统计划受限于存储资源空间和本钱，存储本钱高、可保存的数据量有限。

天眼：完结了日志转存文件及从文件自动化康复，日志存储本钱低，存储周期长。

天眼经过自建分布式日志渠道，有用的处理ELK日志计划下存在的缺点问题；当时天眼日志量级：日均10TB日志量，并发QPS：10w+，接入产品线数：1000+。

GEEK TALK

03 天眼

3.1 天眼体系架构

上图为完好的天眼中心体系架构，概述如下：

1、天眼日志收集支撑SDK及监听日志文件两种办法，其间SDK首要经过完结日志插件接口取得完好日志结构信息，并传输至天眼日志传输管道；取得的日志信息LogEvent结构完好，一起根据LogEvent添加了产品线标识等字段，为日志阻隔和检索供给中心根据；监听日志文件办法完结事务方0开发本钱接入，仅需简略装备即可完结日志接入，支撑产品线字段标识的一起，日志音讯体解析也完结了正则匹配规矩自动化匹配。

2、天眼日志传输选用高并发功用行列Disruptor，而且二次选用高功用行列Bigpipe完结日志传输异步解耦，处理了传统行列因加锁和伪同享等问题带来的功用缺点；一起在传输进程中供给日志过滤和日志告警规矩装备化自动化履行。

3、天眼日志存储经过轮询消费Bigpipe日志音讯，终究写入ES的BulkProcessor，由ES自动调度并发写入ES进行存储；在日志传输和存储进程中完结了日志传输资源与存储资源阻隔，根据产品线装备自动化挑选传输与存储资源。

4、天眼自动化整理完结在存储资源有限的状况下自适应存储，自动化转存与康复完结了在ES资源有限状况下低本钱长时刻存储处理计划。

3.2 天眼日志收集

日志渠道中心意图是收集分布式场景下的事务日志进行会集处理和存储，收集办法首要包含如下：

1、凭借常见日志结构供给的插件接口，在生成日志事情的一起履行其他自界说处理逻辑，例如log4j2供给的Appender等。

2、经过各种阻拦器插件在固定位置阻拦并自动生成和打印事务日志，将这类日志信息自动发送至日志音讯传输行列中供消费运用，常见的如http、rpc调用链恳求与回来信息打印，以及mybatis履行进程SQL明细打印等。

3、监听日志文件写入，从文件体系上的一个文件进行读取，作业原理有些相似UNIX的tail -0F指令，当日志写入本地文件时捕获写入行内容并进行其他自界说处理，例如将日志行信息发送至音讯行列供下游运用。

4、syslog：监听来自514端口的syslog音讯，并将其转化为RFC3164格局。

更多可用的日志收集完结办法，能够参阅：Input Plugins

下面以天眼日志收集为例详细介绍日志收集完结进程：

天眼渠道供支撑两类日志收集完结办法，一类是SDK、一类是minos（百度自研的新一代的流式日志传输体系）。

3.2.1 天眼SDK日志收集

天眼SDK日志收集办法为经过Java SDK办法向事务方供给日志收集组件完结，达到自动收集事务日志并自动传输的意图；中心分为message日志流和trace日志流两大块：

1、message日志流首要经过日志结构供给的Appender接口完结，共支撑log4j、logback、log4j2等干流日志结构。

以logback为例，经过继承并完结AppenderBase笼统类供给的append办法，在logback日志结构生成LogEvent后获取日志事情目标并提交给LogbackTask履行使命处理，在LogbackTask中能够对日志事情内容进行进一步包装完善，并履行一些日志过滤战略等，终究得到的日志事情信息将直接发送至日志传输行列进行传输处理；

public class LogClientAppender<E> extends AppenderBase<E> {
    private static final Logger LOGGER = LoggerFactory.getLogger(LogClientAppender.class);
    @Override
    protected void append(E eventObject) {
        ILoggingEvent event = filter(eventObject);
        if (event != null) {
            MessageLogSender.getExecutor().submit(new LogbackTask(event, LogNodeFactory.getLogNodeSyncDto()));
        }
    }
}

2、trace日志流首要经过各类阻拦器阻拦事务恳求调用链及事务履行链路，经过获取调用链详细信息自动生成调用链日志事情，并发送至日志传输行列进行消费运用，常见的调用链日志包含http与rpc恳求及呼应日志、mybatis组件SQL履行日志等；

下图为trace日志流完结类图，描述了trace日志流笼统完结进程：

以mybatis为例，trace日志流中心阻拦器完结类为IlogMybatisPlugin，完结ibatis Interceptor接口

中心代码：

TraceFactory.getSqltracer().end(returnObj, className, methodName, realParams, dbType, sqlType, sql, sqlUrl)

在end办法中将SQL履行进程中发生的各类信息经过参数传入，并组装成SqlLogNode（继承至通用日志节点LogNode）发布到行列。

运用时需求事务方手动将插件注册到SqlSessionFactory，以收效插件：

sqlSessionFactory.getConfiguration().addInterceptor(new IlogMybatisPlugin());

3.2.2 天眼minos日志收集

minos日志收集首要是凭借百度自研的minos数据传输渠道，完结机器实例上的日志文件信息实时传输至意图地，常见传输意图地有Bigpipe、HDFS、AFS等；现在天眼首要是经过将minos收集到的日志发送到Bigpipe完结，并由后续的Bigpipe顾客共同消费和处理；一起针对日志来源为minos的日志在消费进程中添加了日志解析与转化战略，确保收集到的日志格局和SDK办法生成的日志格局根本共同；

在日志收集进程中，天眼如何处理渠道化标识：

1、在产品线接入天眼时，天眼给对应产品线生成产品线仅有标识；

2、SDK接入办法下，产品线服务端经过体系变量装备产品线标识，SDK在运转进程中会自动读取该变量值并设置到LogNode属性中；

3、LogNode作为日志完好信息目标，在传输进程中终究存储到ES，一起ES在建索引时为产品线仅有标识分配字段属性；

4、产品线仅有标识贯穿整个分布式日志链路并和日志内容强绑定。

3.3 高并发数据传输和存储

在ELK计划中，生成的日志信息直接发送给logstash进行传输，并写入到es，整个进程根本为同步操作，并发功用彻底依靠logstash服务端及ES服务端功用；

天眼则是经过异步办法解耦日志传输进程，以及在日志入口处引进Disruptor高功用行列，并发功用直奔千万等级；一起在Disruptor本地行列之后再规划Bigpipe离线行列，用来长效存储和传输日志音讯；以及引进兜底文件行列BigQueue处理计划，处理在极少数反常状况下写本地行列或离线行列失利时的兜底保证，如下图所示：

Disruptor 是一个高功用的用于线程间音讯处理的开源结构。Disruptor内部运用了RingBuffer，它是Disruptor的中心的数据结构。

Disruptor行列规划特性：

固定大小数组：由于数组占用一块连续的内存空间，能够利用CPU的缓存战略，预先读取数组元素附近的元素；

数组预填充：避免了垃圾回收代来的体系开销；

缓存行填充：处理伪同享问题；

位操作：加速体系的核算速度；

运用数组+系列号的这种办法最大极限的提高了速度。因为假如运用传统的行列的话，在多线程环境下对行列头和行列尾的锁竞赛是一种很大的体系开销。

Bigpipe是一个分布式中间件体系，支撑Topic和Queue模型，不只能够完结传统音讯行列能够完结的诸如音讯、指令的实时传输，也能够用于日志数据的实时传输。Bigpipe能够协助模块间的通讯完结解耦，并能确保音讯的不丢不重；

BigQueue是根据内存映射文件的大型、快速和耐久行列；

1、快: 挨近直接内存拜访的速度，enqueue和dequeue都挨近于O(1)内存拜访。

2、大：行列的总大小仅受可用磁盘空间的约束。

3、耐久：行列中的一切数据都耐久保存在磁盘上，而且是抗崩溃的。

4、可靠：即使您的进程崩溃，操作体系也将负责保留生成的音讯。

5、实时：出产者线程发生的音讯将当即对顾客线程可见。

6、内存高效：自动分页和交流算法，只要最近拜访的数据保留在内存中。

7、线程安全：多个线程能够一起入队和出队而不会损坏数据。

8、简略轻量：现在源文件个数12个，库jar不到30K。

在收集到日志事情后，进入传输进程中，天眼SDK中支撑日志过滤规矩战略匹配，针对命中战略的日志进行过滤，完结进程如下图所示：

未命中过滤规矩的日志音讯事情将继续发送至Bigpipe，至此日志出产阶段即完结，后续经过天眼顾客模块订阅Bigpipe消费并批量推送至ES。

3.4 天眼日志检索

根据天眼链路终究存储到ES的日志数据，天眼渠道供给了可视化日志检索页面，能够根据产品线仅有标识（日志源ID）指定事务规模进行检索，一起支撑各种检索条件，效果如下图所示：

3.4.1 检索条件详解

日志源id列表：获取日志源对应的日志

检索时刻规模：日志的时刻规模

排序类型：日志的存入时刻/日志存入的算分

查询数量：查询出多少数量的日志

日志等级：查询什么等级的日志，如：DEBUG / INFO / WARN / ERROR

算分条件：支撑五种算分查询，文本查询、等值查询、短语查询、前缀查询、逻辑查询；五选一

过滤条件：只显示符合过滤条件信息的日志

3.4.2 算分条件检索详细阐明

支撑五种算分查询：文本查询、等值查询、短语查询、前缀查询、逻辑查询。五选一

查找内容字段：message、exception

"message": {
  "type": "text",
  "fields": {
    "raw": {
      "type": "keyword",
      "ignore_above": 15000
    }
  },
  "analyzer": "my_ik_max_word",
  "search_analyzer": "my_ik_smart"
},
"exception": {
  "type": "text",
  "analyzer": "my_ik_max_word",
  "search_analyzer": "my_ik_smart"
}

阐明：

• “analyzer”: “my_ik_max_word”：底层运用ik_max_word，message和exception信息在存储是会以最细粒度拆词进行存储；

• “search_analyzer”: “my_ik_smart”：底层运用ik_smart，在查询内容是，会将查询内容以最粗粒度拆分进行查询。

3.4.2.1 文本查询

底层完结原理

{
  "query": {
    "bool": {
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "best_fields"
        }
      }]
    }
  }
}

天眼办理端对应图

运用阐明：

• multi_match中的best_fields会将任何与查询匹配的文档作为成果回来，可是只运用最佳字段的 _score 评分作为评分成果回来

3.4.2.2 等值查询

底层完结原理

{
  "query": {
    "bool": {
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "best_fields",
          "analyzer": "keyword"
        }
      }]
    }
  }
}

天眼办理端对应图

运用阐明：

• multi_match中的best_fields会将任何与查询匹配的文档作为成果回来，可是只运用最佳字段的 _score 评分作为评分成果回来

• 设置 analyzer 参数来界说查询句子时对其间词条履行的分析进程

• KeywordAnalyzer – 不分词，直接将输入作为输出

3.4.2.3 短语查询

底层完结原理

{
    "query": {
        "bool": {
            // 短语查询
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "phrase",
          "slop": 2
        }
      }]
        }
    }
}

天眼办理端对应图

运用阐明：

• phrase在fields中的每个字段上均履行match_phrase查询，并将最佳字段的 _score 作为成果回来

• 默许运用match_phrase时会准确匹配查询的短语，需求悉数单词和次序要彻底一样，标点符号在外

• slop指查询词条相隔多远时仍然能将文档视为匹配 什么是相隔多远？意思是说为了让查询和文档匹配你需求移动词条多少次？以 “I like swimming and riding!” 的文档为例，想匹配 “I like riding”，只需求将 “riding” 词条向前移动两次，因而设置 slop 参数值为 2， 就能够匹配到。

3.4.2.4 前缀查询

底层完结原理

{
  "size": 50,
  "query": {
    "bool": {
      // 前缀查询
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "phrase_prefix",
          "max_expansions": 2
        }
      }]
    }
  }
}

天眼办理端对应图

运用阐明：

• phrase_prefix在fields中的字段上均履行match_phrase_prefix查询，并将每个字段的分数进行合并

• match_phrase_prefix 和 match_phrase 用法是一样的，差异就在于它答应对最后一个词条前缀匹配，例如：查询 I like sw 就能匹配到I like swimming and riding。

• max_expansions 说的是参数 max_expansions 操控着能够与前缀匹配的词的数量，默许值是 50。以 I like swi 查询为例，它会先查找第一个与前缀 swi 匹配的词，然后顺次查找收集与之匹配的词（按字母次序），直到没有更多可匹配的词或当数量超越 max_expansions 时结束。

• match_phrase_prefix 用起来非常便利，能够完结输入即查找的效果，可是也会出现问题。假如说查询 I like s 而且想要匹配 I like swimming ，成果是默许状况下它会查找出前 50 个组合，假如前 50 个没有 swimming ，那就不会显示出成果。只能是用户继续输入后边的字母才或许匹配出成果。

3.4.2.5 逻辑查询

底层完结原理

{
  "query": {
    "bool": {
      // 逻辑查询
      "must": [{
        "simple_query_string": {
          "query": "searchValue",
          "fields": ["message", "exception"]
        }
      }]
    }
  }
}

天眼办理端对应图：

simple_query_string查询支撑以下操作符（默许是OR），用于解说查询字符串中的文本:

• +AND

• |OR

• -非

• “包装许多符号以表明要查找的短语

• *在术语的末尾表明前缀查询

• (and)表明优先级

• ~N在一个单词之后表明编辑间隔(模糊)

• ~N在短语后边表明溢出量

官方运用文档：www.elastic.co/guide/en/el…

运用示例解说：

GET/_search
{
  "query": {
    "simple_query_string": {
      "fields": [ "content" ],
      "query": "foo bar -baz"
    }
}

这个查找的意图是只回来包含foo或bar但不包含baz的文档。然而，由于运用了OR的default_operator，这个查找实际上回来了包含foo或bar的文档以及不包含baz的文档。要按预期回来文档，将查询字符串更改为foo bar +-baz。

3.5 日志资源阻隔

在巨大的企业级软件出产环境下，事务体系会发生海量日志数据。一方面，跟着事务方的不断添加，日志体系有限的资源会被耗尽，导致服务不稳定乃至宕机。另一方面，不同事务的日志量级、QPS 存在差异，极端状况下不同事务方会对同享资源进行竞赛，导致部分事务的日志查询延时变高。这对日志体系的资源办理带来了应战。

天眼渠道选用资源阻隔的办法处理此问题，来为事务供给实时、高效、安全的存储与查询服务。

资源阻隔首要围绕着日志的传输资源与日志的存储资源进行。事务方在接入天眼体系时，能够根据事务需求在渠道交互界面，进行传输资源与存储资源的阻隔装备，这种阻隔资源的装备办法避免了同享资源竞赛导致的日志推迟添加与潜在的日志丢掉问题。

详细的阻隔完结计划如图 3.5.1 所示，首要包含以下过程：

1、事务方出产日志：如 3.2 介绍到的，事务方运转时发生的日志能够经过 SDK 或 minos 的办法将日志传输至分布式行列 BP 中；

2、天眼渠道订阅日志：在事务方经过天眼渠道进行 ES、BP 资源的装备之后，装备监听器会监测到改变内容，再根据装备的改变类型办理日志订阅器、分发器的生命周期，包含ES 客户端、BP 客户端的创建与销毁；

3、渠道内部日志处理：日志订阅器经过 BP 客户端收到事务方的日志后，首要会选用 3.3 中说到的事务方过滤规矩进行过滤阻拦，再将日志转化为事情放入绑定的内存通道中；

4、天眼渠道分发日志：日志分发器会不断从绑定的内存通道中拉取日志事情，并经过 ES 客户端对日志进行存储，假如存储失利则会触发相应 backoff 战略，例如反常行为记载；

5、事务方日志查询：日志存储至 ES 集群之后，事务方能够经过渠道界面快捷地进行日志查询。

△3.5.1 天眼-资源阻隔计划

可见在杂乱的多运用场景下，阻隔资源机制是一种高效办理日志体系资源的办法。天眼日志体系供给了灵敏的资源装备来避免资源浪费，供给了同享资源的阻隔来降低事务方日志查询的推迟、提高日志查询的安全性，然后推动事务的添加和运营功率。

3.6 日志动态整理与存储降级

跟着事务的长时间运转与开展，日志量级也在不断添加。一方面，针对近期发生的日志，事务方有火急的查询需求。针对发生较久的日志，迫于监管与审计要求也有低频率拜访的诉求。如安在本钱可控而且确保渠道稳定的前提下，维护这些海量日志并供给查询服务对日志体系而言也是一个应战。

天眼渠道经过资源整理机制和日志存储降级机制来处理这个问题。

资源整理机制首要用作 ES 集群的索引整理。跟着日志量的添加，集群的资源占用率也在添加，在极端状况下，过高的磁盘与内存占用率会导致 ES 服务的功用下降，乃至服务的宕机。资源整理机制会定时查询 ES 集群的资源占用状况，一旦集群的磁盘资源超越事务方设定的阈值，会优先整理最旧的日志，直到资源占用率康复正常水平。

存储降级机制首要用作 ES 集群的索引备份与康复。将日志长时间存储在贵重的 ES 集群中是一种资源浪费，也为日志体系添加了额外的开销。存储降级机制会定时对 ES 集群进行快照，然后将快照转存到更低开销的大目标存储服务（BOS）中，转存之后的快照有 180 天的有用期以应对检查与监管。当事务方需求查询降级存储后的日志时，只需求从大目标存储服务中拉取快照，再康复到 ES 集群以供给查询才干。

详细的资源整理机制与存储降级机制如图 3.6.1 所示，首要包含以下过程：

1、集群状况查询：资源整理使命经过定时查询集群信息的办法监测资源占用率，当资源占用率超越事务方设定的阈值时会触发资源整理；

2、集群索引整理：经过查询索引信息并进行资源占用状况核算，再根据时刻倒序删去顺次最旧的索引，直到满足设定的阈值；

3、集群索引备份：存储降级使命会定时对集群进行快照恳求，然后将快照文件转存到低开销的大文件存储服务中完结存储的降级；

4、集群索引康复：在事务方需求查询降级存储后的日志时，服务会将快照文件从大文件存储服务中拉取目标快照，再经过快照康复恳求对快照进行康复，以供给事务方查询。

△3.6.1天眼-日志动态整理与存储降级计划

可见在面对海量日志的存储与查询，经过资源整理机制能够避免集群资源过载一起提高日志检索功率，经过存储降级机制能够提高资源利用率一起确保审计的合规性，然后在事务高速添加运用的一起确保日志体系的健壮性。

3.7最佳实践

根据前面说到的天眼渠道规划思想，结合其间部分才干展开介绍天眼在运维办理方面的实践。

3.7.1 天眼渠道化实践

天眼经过笼统产品线概念，针对不同的接入方供给产品线接入流程，为事务生成产品线仅有标识并与事务日志绑定；产品线相关流程如下：

1、产品线日志源请求流程

支撑产品线挑选日志收集办法包含SDK、Minos两种办法，挑选minos接入时，bns与日志存储途径必选，便利体系根据装备自动履行日志收集。

一起在Bigpipe资源与ES资源方面，渠道支撑多种资源阻隔独立运用，不同的产品线能够装备各自独有的传输和存储资源，保证数据安全性和稳定性。

2、日志源请求后，需求办理员审阅后才干进行运用（请求后无需操作，仅需等候办理员经过审阅后，进行SDK接入）

access_key的值检查权限：仅日志源绑定产品线的司理及接口人可查，access_key将作为产品线接入天眼鉴权的关键根据。

3.7.2 日志过滤实践

产品线接口人能够根据本身产品线新增日志过滤规矩装备，装备的规矩将自动收效于日志收集传输流程中：

挑选音讯日志后将弹出详细过滤规矩装备菜单，当时体系共支撑三种过滤规矩，分别是按日志内容、按日志称号、按日志内容和日志称号组合三种办法：

过滤规矩装备完结后能够在列表办理每条规矩：

04 思考与总结

跟着分布式事务体系的日益杂乱，为事务方供给高效、低推迟、高功用的日志服务体系显得尤为重要。本文介绍了天眼渠道是如何进行日志收集、传输并支撑检索的，此外还经过支撑日志的资源阻隔，解耦各事务方的日志通路和存储，然后完结事务日志的高效查询和事务问题的高效定位。此外经过对日志进行监控能够自动发现体系问题，并经过告警日志的trace_id快速定位问题，然后提高问题发现导处理的功率。

跟着大模型技能的不断开展，咱们也经过大模型进行一些事务迭代，然后提高事务检索和排查功率。例如：咱们能够直接问询，今天有几笔反常核销订单；订单7539661906核销反常原因是什么等等。经过与大模型的结合，咱们缩短了事务方问题排查定位的途径，提高了事务运维功率和交互体验。后续咱们也将不断与大模型进行深化打磨和继续深耕，继续沉淀和输出相关的通用计划。

——END——

引荐阅读：

视频与图片检索中的多模态语义匹配模型：原理、启示、运用与展望

百度离线资源治理

百度APP iOS端包体积50M优化实践(三) 资源优化

代码级质量技能之根本结构介绍

根据openfaas保管脚本的实践

百度工程师移动开发避坑指南——Swift语言篇