一、引言

在实际搭建日志中心的过程中，对于架构选项有很多疑惑，甚至技术栈不清楚用哪些，由于本身是日志模块，属于系统的侧面，该场景下，大部分用户对于日志数据的专业性要求并不是很多，故而会一昧的使用传统的 ELK （ Elasticsearch+logstash+kibana ）的架构模式，来构建日志模块或简易的日志中心，若只是小系统还好，场景有限，传统的 ELK 架构模式影响也有限，一些系统随着规模的扩大会出现日志量激增，新增对日志数据的检索要求，此时旧有架构可能就不足以支撑当前的诉求，因此在做日志模块或日志中心搭建时，建议根据自己的实际诉求规划好整体日志模块框架。

二、日志模块常见组件介绍

1.Logstash

Logstash 是一个用于数据收集、转换和传输的开源工具，属于 Elastic Stack （以前称为 ELK Stack ）的一部分。它的设计目标是处理各种不同来源的日志和事件数据，使其能够被存储、搜索和分析。
Logstash 具有以下主要特点：

• 输入（ Input ）： Logstash 支持多种输入源，包括文件、标准输入、 TCP/UDP 、 Syslog 、 Beats 等。这使得它能够从各种来源收集日志和事件数据。
• 过滤（ Filter ）： Logstash 可以通过插件进行数据的转换和过滤，允许用户按需处理和修改输入数据。这些过滤器可以用于解析、结构化和丰富日志数据。
• 输出（ Output ）：处理完数据后， Logstash 将其发送到指定的目标，常见的目标包括 Elasticsearch 、文件、消息队列（如 Kafka ）、各种数据库等。这使得 Logstash 与其他组件无缝集成，为数据存储和分析提供了更多选择。
• 插件支持： Logstash 具有丰富的插件生态系统，用户可以选择性地使用插件以满足特定的需求。这使得 Logstash 非常灵活，能够适应不同的数据处理场景。
  Logstash 通常与 Elasticsearch 和 Kibana 一起使用，构成一个强大的日志和事件处理平台。 Elasticsearch 用于存储和索引数据， Kibana 用于可视化和分析数据，而 Logstash 则负责数据的收集、转换和传输。

2.Filebeat

Filebeat 是由 Elasticsearch 提供的一个开源日志数据收集器。它设计用于轻松收集、传输和处理日志文件或事件，然后将它们发送到 Elasticsearch 或 Logstash 等目标，以进行存储、搜索和分析。
Filebeat 主要用于监视文件变化并将其发送到指定的目标，通常与 Elastic Stack （以前称为 ELK Stack ）一起使用，该堆栈包括 Elasticsearch 、 Logstash 和 Kibana 。 Filebeat 可以用于收集各种类型的日志数据，例如应用程序日志、系统日志和安全事件等。
它支持多种输入和输出插件，可以轻松集成到不同的环境中。 Filebeat 还具有轻量级和高效的特点，使其适用于在分布式环境中运行，以实现实时日志数据的收集和分析。

3.Fluentd

Fluentd 是一个开源的日志收集器和数据传输工具，可以帮助用户实现可扩展的日志收集和数据流水线。它支持多种输入和输出插件，允许从不同的数据源收集数据，并将其发送到不同的目标。
Fluentd 具有以下特点：

• 多源多目标： Fluentd 支持从多种数据源（如日志文件、 TCP/UDP 、 HTTP 等）收集数据，并将数据发送到多个目标（如 Elasticsearch 、 MongoDB 、 Amazon S3 等）。
• 插件生态系统： Fluentd 具有丰富的插件生态系统，用户可以根据实际需求选择和配置不同的插件，以满足特定的数据收集和传输要求。
• 轻量级和高性能： Fluentd 被设计为轻量级和高性能的工具，适用于在分布式环境中运行，并能够处理大规模的数据流。
• 灵活的数据处理： Fluentd 支持对数据进行灵活的处理和转换，可以通过过滤器插件实现数据的解析、结构化和丰富。
  Fluentd 与 Elastic Stack （ ELK Stack ）和其他数据处理工具相比，提供了更多的灵活性和可定制性。在一些场景中，用户可能选择使用 Fluentd 作为日志收集器，将数据传输到 Elasticsearch 等目标，以构建自己的日志处理流水线。

4.Flume

Apache Flume 是一个开源的分布式日志收集系统，旨在简化大规模数据流的采集、聚合和移动。 Flume 最初是为了满足 Apache Hadoop 的数据导入需求而开发的，但它也可以与其他存储和处理系统集成，不仅局限于 Hadoop 生态系统。
主要功能和特点包括：

• 数据流的可靠性： Flume 支持将数据从多个源（例如日志文件、应用程序日志、网络流量等）收集到目标（例如 HDFS 、 HBase 、 Elasticsearch 等）的可靠传输。它确保数据的完整性和一致性。
• 分布式架构： Flume 是一个分布式的系统，可以横向扩展以处理大量数据。它的架构允许通过多个节点协同工作，以应对高吞吐量的需求。
• 可配置性： Flume 采用事件驱动模型，可以通过配置定义数据流的路径和处理步骤。用户可以使用配置文件轻松地定制数据流的行为，包括源、通道和目标的配置。
• 插件体系结构： Flume 支持插件体系结构，允许用户扩展其功能。用户可以编写自定义的源、通道和目标，以满足特定的需求。
• 多种内置组件： Flume 提供了一些内置的组件，例如 Avro 、 Thrift 和 HTTP 等源，以及 HDFS 、 HBase 、 Elasticsearch 等目标，这些组件使其与 Hadoop 生态系统和其他存储系统集成更加方便。
• 容错性： Flume 具有一定的容错性，能够处理节点故障、重启和数据重传等情况，以确保数据的可靠性。
  总体而言， Flume 旨在简化大规模数据流的收集和传输，特别适用于分布式环境中的日志收集任务。它可以与各种存储和处理系统集成，使得用户能够构建强大的数据流水线。

5.Kafka

Kafka 是一个分布式流式平台，用于构建实时数据管道和流式应用程序。 Kafka 设计用于处理大规模的实时数据流，提供高吞吐量、持久性、可扩展性和容错性。 Kafka 通常被用于构建大规模、高可用性的数据管道，用于数据集成、事件处理、日志聚合等场景。在日志和事件处理领域， Kafka 经常与其他组件（如 Flume 、 Beats 、 Logstash ）一起使用，构建端到端的实时数据流水线。

6.Zookeeper

Zookeeper 是一个分布式协调服务，为分布式系统提供一致性、可靠性和高性能的服务。它管理配置信息、提供命名服务、分布式同步和组服务等功能。在实际应用中， Zookeeper 和 Kafka 通常一起使用。 Zookeeper 负责 Kafka 的分布式协调和领导者选举等任务。

三、日志模块 / 中心架构选型介绍

1. 简易系统日志模块

1.1. 场景描述

早期进行系统建设时，大部分简单系统在进行功能模块设计时，并不注重日志侧功能的建设，功能设计较为简单，仅在系统中增加一个简易的日志模块，存放系统操作记录日志，完备点的会存放审计类型的日志，日志数量每天在 100-500W ，大小约 40-50G 。

1.2. 诉求描述

• 系统开发整体工期短
• 系统整体规划更注重主体功能
• 客户方对于日志数据无较多合规要求

1.3. 架构选型建议

基于此场景下，笔者有两种日志架构选型可供参考

1.3.1.ELK （ Elasticsearch+Logstash+Kibana ）日志架构

基于快速交付，日志量较小，无大量日志缓存诉求，日志无太多合规要求的场景，若系统设计中，日志存在需要进行预处理的场景，则可选择传统 ELK 架构。建议资源列表如下：

表 1 ： ELK 日志架构资源列表

架构图如下：

图 1 ： ELK 日志架构图

优点

• 当前主流架构，系统建设使用场景较多
• 网上该架构可供参考的技术解决方案及问题解决方法较多
• 可对数据进行预处理，能满足一些对数据格式有要求的场景

1.3.2.EFK （ Elasticsearch+Filebeat+Kibana ）日志架构

与 ELK 架构场景略有区别，同样是基于快速交付，但对于日志数据不需要进行预处理，该场景下则可选择 EFK 日志架构，只是将 Logstash 组件替换为了 Filebeat 组件。建议资源列表如下：

表 2：EFK 日志架构资源列表

架构图如下：

图 2：EFK 日志架构图

优点

• Filebeat 组件相较于 Logstash 组件轻量，专注日志文件采集

2. 中型平台日志模块

2.1. 场景描述

相较于第一种情况，该场景下日志模块相较来说较为完善，存储的日志种类较多，且数据量较大，需进行数据预处理，日志数量每天在 5000W 左右，大小约 400G 。

2.2. 诉求描述

• 日志种类较多
• 存在日志查询场景要求
• 需对数据进行预处理

2.3. 架构选型建议

2.3.1.EFLK （ Elasticsearch+Filebeat+Logstash+Kibana ）日志架构

该日志架构使用 Filebeat 组件针对服务器日志文件进行采集，将采集后的日志数据发送至 Logstash 组件，对日志数据进行清洗，将清洗后的数据存入 Elasticsearch 。建议资源列表如下：

表 3：EFLK 日志架构资源列表

架构图如下：

图 3： EFLK 日志架构图

优点

• 技术组件为 Elastic 生态链组件，配置简单易上手，不存在版本冲突或不适配
• 社区成熟，解决方案及建议较多，遇到问题好排查
• 组件功能分工明确，各司其职，资源使用压力较小

2.3.2.EFK/ELK （ Elasticsearch+Fluentd/Logstash+Kibana ）日志架构

因为该场景下，数据量相对较大，种类相对较为丰富，该日志架构日志采集器使用 Fluentd 或 Logstash 对日志数据进行采集并清洗，再将数据传输至 Elasticsearch ，建议资源列表如下：

表 4： EFK/ELK 日志架构资源列表

架构图如下：

图 4： EFK/ELK 日志架构图

优点

• 省去 Filebeat 组件环节，日志架构整体链路缩短
• Fluentd/Logstash 组件插件丰富，适配更灵活

3. 大型平台日志模块

3.1. 场景描述

相较于中型平台场景，大型平台的日志模块建设已趋于完善，日志类型丰富，具备较强大的日志查询能力，且整体日志架构较为复杂，甚至需要进行日志数据的生命周期管理及容灾备份。

3.2. 诉求描述

• 具备承接多种类型日志能力
• 具备较高的日志读写性能
• 具备基础生命周期管理能力
• 具备基础容灾备份能力

3.3. 架构选型建议

3.3.1.Elasticsearch+Filebeat+Zookeeper+Kafka+Kibana 日志架构

该架构适合不需要进行数据清洗的日志采集场景，该场景下，通过 Filebeat 组件采集日志，再将日志数据放入 Kafka 组件，最终通过消费组件将日志数据消费至 Elasticsearch ，而该场景下的 Kibana 的作用，更倾向于监控管理集群，再通过统一网关组件进行日志查询。建议资源列表如下：

表 5：日志架构资源列表

在此场景下，建议对 Elasticsearch 集群进行角色划分，详情如下表：

表 6： Elasticsearch 集群节点角色列表

架构图如下：

图 5：日志架构图

3.3.2.Elasticsearch+Fluentd/(Filebeat+Logstash)+Zookeeper+Kafka+Kibana 日志架构

该架构主要使用了 Fluentd 或同样作用的 Filebeat 与 Logstash 组件，采集日志数据，并对其进行数据清洗，将数据存放至 Kafka ，再将数据通过消费组件写入 Elasticsearch 集群。建议资源如下：

表 7：日志架构资源列表

此场景下， Elasticsearch 集群的节点角色可按照 3.3.1. 中的表 6 进行划分，此外需特别注意 Logstash 建议以集群形式进行部署，以提高日志数据的清洗速率。

架构图如下：

图 6：日志架构图

### 3.4. 日志生命周期策略
日志生命周期策略图如下：

图 7：日志生命周期策略图

如图 7所示，这种平台下的日志一般会对 Elasticsearch 集群设置基础的生命周期策略，大多数场景下，一般会维持 1-7 天的热数据，此时数据读写频繁， 7-30 天时， Elasticsearch 早期索引写入数据的场景几乎消失，读数据场景较为频繁， 30 天后，读数据场景几乎消失（很少场景下会查询 30 天后的日志数据），进而变为冷数据，最终删除。

需要注意的是，该策略需要根据实际情况设置，一些场景下，数据无需由热 - 温 - 冷，而是直接由热数据变为冷数据，此时便可省去温数据的阶段，减轻 Elasticsearch 集群资源消耗。

3.5. 日志容灾备份方案

3.5.1.Kafka 侧数据同步

容灾备份架构图如下：

图 8：kafka 侧数据同步架构

由图8可知，可以通过 mirror-maker 工具同步两侧机房中 kafka 的日志数据，再由各自机房的消费组件将日志消费写入 Elasticsearch 集群。

3.5.2. 消费组件侧数据同步

消费组件架构图如下：

图 9：消费组件侧双写架构

由图 9可知，可通过消费组件双写日志数据至两侧机房的 Elasticsearch 集群，但该场景需尽可能的保证数据的一致性，对于数据强一致性场景来说，不太适用。

3.5.3.ES 集群侧数据同步

图 10：ES 集群侧数据同步

由图 10可知，可使用 Elasticsearch 集群的 CCR 功能进行日志同步操作，甚至可进行两侧集群双向同步即双活架构，但该功能需要使用企业级证书，此外，还可以使用 Elasticsearch 集群的辅助工具，如 elasticserach-dump ， esm 等。

4. 日志中心

4.1. 场景描述

相较于之前所有的场景，日志中心的建设要复杂得多，首先所需服务器的资源量是庞大的，其次需要占用大量的带宽，此外，由于是企业级别日志中心，还需满足用户侧实际情况的定开场景，如：多租户支持，实时监控分析，可对接或集成其他运维工具，最后还要考虑容灾备份的场景。

4.2. 诉求描述

• 采集所有应用系统的大多数种类的日志数据
• 提供快速且精准的日志搜索能力
• 具备生命周期管理能力
• 具备容灾备份能力
• 具备用户管理能力或多租户管理能力

4.3. 架构选型建议

该场景下日志架构选项参考 3.3 章节，只是相对来说，所需资源量要大很多， Elasticsearch 集群规模（节点数 100-500 ，进行特定的角色划分）此处不进行赘述，仅以机房 /AZ 视角给出建议架构，仅供参考。

架构图如下：

图 11：日志架构图

如图所示，为笔者曾遇到过的日志中心的场景，各机房 /AZ 接收各自的日志数据，再通过统一网关组件进行日志查询，由于各自接收自身机房的日志数据，故而该场景下，相对来说 Elasticsearch 集群所需资源相对较小。

此外，还存在如下架构图的场景：

图 12：日志架构图

与之前架构不同的是，该架构所有机房 /AZ 的日志数据接写入至一套 Elasticsearch 集群，再由 Elasticsearch 集群侧进行日志数据同步，好处是不用根据机房的数量维护对应数量的 Elasticsearch 集群，但坏处是，这一套 Elasticsearch 集群所需相对来说大量的服务器资源，且日志写入压力相对较大，要承担所有机房的日志数据。

4.4. 日志生命周期策略

图 13：日志生命周期策略图

该规模的日志中心，往往可对数据做较长时间的保留，而且在一个月内对于日志的读写都很频繁，故而热数据周期一般设置为 0-1 个月，温数据周期设置为 1 年左右，将 1-3 年的数据设置为冷数据，超过三年后的数据，将做归档处理，存入磁带库中进行保存。

4.5. 日志容灾备份策略

该场景下日志容灾备份策略技术组件层方案与第三章节 3.5 小节方案相似，此处不再赘述。

四、结语

本次介绍了日志模块常使用的技术组件，以及常见日志场景下的几种技术架构选型，希望可以给大家在进行日志模块 / 中心建设规划时一个大致的参考。