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

分布式服务系统中，每个服务有大量的服务器，而每台服务器每天都会产生大量的日志。我们面临的主要挑战有：

所以我们该如何提供分布式系统下高效、低延迟、高性能的日志服务呢？

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 之前对文档进行特定更改。

2.2.2 Store组件

2.2.3 Consumer组件

Elasticsearch Client 提供了一种方便的机制来管理来自语言（如 Java、Ruby、Go、Python 等）的 Elasticsearch 的 API 请求和响应。

天眼通过自建分布式日志平台，有效的解决ELK日志方案下存在的缺陷问题；当前天眼日志量级：日均10TB日志量，并发QPS：10w+，接入产品线数：1000+。

上图为完整的天眼核心系统架构，概述如下：

日志平台核心目的是采集分布式场景下的业务日志进行集中处理和存储，采集方式主要包含如下：

更多可用的日志采集实现方式，可以参考：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方式生成的日志格式基本一致；

在日志采集过程中，天眼如何解决平台化标识：

在ELK方案中，生成的日志信息直接发送给logstash进行传输，并写入到es，整个过程基本为同步操作，并发性能完全依赖logstash服务端及ES服务端性能；

天眼则是通过异步方式解耦日志传输过程，以及在日志入口处引入Disruptor高性能队列，并发性能直奔千万级别；同时在Disruptor本地队列之后再设计Bigpipe离线队列，用来长效存储和传输日志消息；以及引入兜底文件队列BigQueue解决方案，处理在极少数异常情况下写本地队列或离线队列失败时的兜底保障，如下图所示：

未命中过滤规则的日志消息事件将继续发送至Bigpipe，至此日志生产阶段即完成，后续通过天眼消费者模块订阅Bigpipe消费并批量推送至ES。

基于天眼链路最终存储到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"}

说明：

3.4.2.1 文本查询

底层实现原理

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

天眼管理端对应图

使用说明：

3.4.2.2 等值查询

底层实现原理

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

天眼管理端对应图

使用说明：

3.4.2.3 短语查询

底层实现原理

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

天眼管理端对应图

使用说明：

3.4.2.4 前缀查询

底层实现原理

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

天眼管理端对应图

使用说明：

3.4.2.5 逻辑查询

底层实现原理

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

天眼管理端对应图：

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

官方使用文档：https://www.elastic.co/guide/en/elasticsearch/reference/6.8/query-dsl-simple-query-string-query.html

使用示例解释：

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

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

在庞大的企业级软件生产环境下，业务系统会产生海量日志数据。一方面，随着业务方的不断增加，日志系统有限的资源会被耗尽，导致服务不稳定甚至宕机。另一方面，不同业务的日志量级、QPS 存在差异，极端情况下不同业务方会对共享资源进行竞争，导致部分业务的日志查询延时变高。这对日志系统的资源管理带来了挑战。

天眼平台采用资源隔离的方式解决此问题，来为业务提供实时、高效、安全的存储与查询服务。

资源隔离主要围绕着日志的传输资源与日志的存储资源进行。业务方在接入天眼系统时，可以根据业务需要在平台交互界面，进行传输资源与存储资源的隔离配置，这种隔离资源的配置方式避免了共享资源竞争导致的日志延迟增加与潜在的日志丢失问题。

具体的隔离实现方案如图 3.5.1 所示，主要包括以下步骤：

△3.5.1 天眼-资源隔离方案

可见在复杂的多应用场景下，隔离资源机制是一种高效管理日志系统资源的方式。天眼日志系统提供了灵活的资源配置来避免资源浪费，提供了共享资源的隔离来降低业务方日志查询的延迟、提升日志查询的安全性，进而推动业务的增长和运营效率。

随着业务的长期运行与发展，日志量级也在不断增加。一方面，针对近期产生的日志，业务方有迫切的查询需求。针对产生较久的日志，迫于监管与审计要求也有低频率访问的诉求。如何在成本可控并且保证平台稳定的前提下，维护这些海量日志并提供查询服务对日志系统而言也是一个挑战。

天眼平台通过资源清理机制和日志存储降级机制来解决这个问题。

资源清理机制主要用作 ES 集群的索引清理。随着日志量的增加，集群的资源占用率也在增加，在极端情况下，过高的磁盘与内存占用率会导致 ES 服务的性能下降，甚至服务的宕机。资源清理机制会定期查询 ES 集群的资源占用情况，一旦集群的磁盘资源超过业务方设定的阈值，会优先清理最旧的日志，直到资源占用率恢复正常水平。

存储降级机制主要用作 ES 集群的索引备份与恢复。将日志长期存储在昂贵的 ES 集群中是一种资源浪费，也为日志系统增加了额外的开销。存储降级机制会定期对 ES 集群进行快照，然后将快照转存到更低开销的大对象存储服务（BOS）中，转存之后的快照有 180 天的有效期以应对审查与监管。当业务方需要查询降级存储后的日志时，只需要从大对象存储服务中拉取快照，再恢复到 ES 集群以提供查询能力。

具体的资源清理机制与存储降级机制如图 3.6.1 所示，主要包括以下步骤：

△3.6.1天眼-日志动态清理与存储降级方案

可见在面对海量日志的存储与查询，通过资源清理机制可以防止集群资源过载同时提升日志检索效率，通过存储降级机制可以提升资源利用率同时确保审计的合规性，从而在业务高速增长使用的同时保证日志系统的健壮性。

基于前面提到的天眼平台设计思想，结合其中部分能力展开介绍天眼在运维管理方面的实践。

3.7.1 天眼平台化实践

天眼通过抽象产品线概念，针对不同的接入方提供产品线接入流程，为业务生成产品线唯一标识并与业务日志绑定；产品线相关流程如下：

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

支持产品线选择日志采集方式包含SDK、Minos两种方式，选择minos接入时，bns与日志存储路径必选，方便系统根据配置自动执行日志采集。

同时在Bigpipe资源与ES资源方面，平台支持多种资源隔离独立使用，不同的产品线可以配置各自独有的传输和存储资源，保障数据安全性和稳定性。

2、日志源申请后，需要管理员审核后才能进行使用（申请后无需操作，仅需等待管理员通过审核后，进行SDK接入）

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

3.7.2 日志过滤实践

产品线接口人可以基于自身产品线新增日志过滤规则配置，配置的规则将自动生效于日志采集传输流程中：

选择消息日志后将弹出详细过滤规则配置菜单，当前系统共支持三种过滤规则，分别是按日志内容、按日志名称、按日志内容和日志名称组合三种方式：

过滤规则配置完成后可以在列表管理每条规则：

随着分布式业务系统的日益复杂，为业务方提供高效、低延迟、高性能的日志服务系统显得尤为重要。本文介绍了天眼平台是如何进行日志采集、传输并支持检索的，此外还通过支持日志的资源隔离，解耦各业务方的日志通路和存储，从而实现业务日志的高效查询和业务问题的高效定位。此外通过对日志进行监控可以主动发现系统问题，并通过告警日志的trace_id快速定位问题，从而提升问题发现导解决的效率。

随着大模型技术的不断发展，我们也通过大模型进行一些业务迭代，进而提升业务检索和排查效率。例如：我们可以直接询问，今天有几笔异常核销订单；订单7539661906核销异常原因是什么等等。通过与大模型的结合，我们缩短了业务方问题排查定位的路径，提升了业务运维效率和交互体验。后续我们也将不断与大模型进行深入打磨和持续深耕，持续沉淀和输出相关的通用方案。