关于分布式:如何设计一个高效的分布式日志服务平台

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

导读 

本文首先介绍了分布式服务下日志服务建设的挑战，而后介绍了下业内 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 参数来定义查问语句时对其中词条执行的剖析过程
• Keyword Analyzer – 不分词，间接将输出当做输入

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 在短语前面示意溢出量

官网应用文档：https://www.elastic.co/guide/en/elasticsearch/reference/6.8/q…

应用示例解释：

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 语言篇