【摘要】本文从组件的基本概念入手，结合企业诉求，介绍了两种常见的日志平台架构的使用场景、以及生命周期管理。同时也详细描述了我们比较头痛的分布式架构中网络带宽问题的解决思路，是一篇非常具有参考价值的文章。前篇：《Elasticsearch 运维（基础篇）》

【作者】搁浅沉默 某金融行业技术研发专员

一、引言  

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

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  

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

1.简易系统日志模块  

1.1.场景描述  

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

1.2.诉求描述  

• 系统开发整体工期短

• 系统整体规划更注重主体功能

• 客户方对于日志数据无较多合规要求

1.3.架构选型建议  

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

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

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

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

架构图如下：

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

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

表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建议以集群形式进行部署，以提高日志数据的清洗速率。

架构图如下：

图7：日志架构图

3.4.日志生命周期策略  

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

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

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

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

3.5.日志容灾备份方案  

3.5.1.Kafka侧数据同步  

容灾备份架构图如下：

图9：kafka侧数据同步架构   

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

3.5.2.消费组件侧数据同步  

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

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

3.5.3.ES集群侧数据同步  

图11：ES集群侧数据同步

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

4.日志中心  

4.1.场景描述  

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

4.2.诉求描述  

• 采集所有应用系统的大多数种类的日志数据

• 提供快速且精准的日志搜索能力

• 具备生命周期管理能力

• 具备容灾备份能力

• 具备用户管理能力或多租户管理能力

4.3.架构选型建议  

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

架构图如下：   

图12：日志架构图

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

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

图13：日志架构图

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

4.4.日志生命周期策略  

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

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

4.5.日志容灾备份策略  

四、结语  

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

欢迎点击阅读原文到社区交流探讨

觉得本文有用，请转发或点击“在看”，让更多同行看到

• 某行日志平台 Elasticsearch 运维基础篇

• 普通容器的日志，采用NAS更好还是日志分析平台直接收集更好？
  

• 如何考虑大模型与数据仓库结合过程中的数据安全和隐私保护？
  

• 数据仓库还没凉，数据湖还没搞明白，怎么又来了“湖仓一体化”？

• 大数据在银行、证券、保险、医疗等行业应用的最佳实践23篇
  

欢迎关注社区  "大数据"技术主题 ，将会不断更新优质资料、文章。地址：

http://www.talkwithtrend.com/Topic/37

*本公众号所发布内容仅代表作者观点，不代表社区立场