搁浅沉默
作者搁浅沉默·2024-03-18 16:57
研发工程师·某股份银行

某行日志平台Elasticsearch运维架构选型篇

字数 7476阅读 1254评论 7赞 4

一、引言

在实际搭建日志中心的过程中,对于架构选项有很多疑惑,甚至技术栈不清楚用哪些,由于本身是日志模块,属于系统的侧面,该场景下,大部分用户对于日志数据的专业性要求并不是很多,故而会一昧的使用传统的 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 架构。建议资源列表如下:

组件名称实例数CPU内存硬盘总量
Elasticsearch32C4G200G
Logstash12C4G-
Kibana11C2G-

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

架构图如下:

图 1 : ELK 日志架构图

优点

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

1.3.2.EFK ( Elasticsearch+Filebeat+Kibana )日志架构

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

组件名称实例数CPU内存硬盘总量
Elasticsearch32C4G200G
Filebeat12C4G-
Kibana11C2G-

表 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 。建议资源列表如下:

组件名称实例数CPU内存硬盘总量
Elasticsearch3/54C8G600G
Filebeat视平台服务器数量而定2C4G-
Logstash3/52C4G-
Kibana11C2G-

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

架构图如下:

图 3: EFLK 日志架构图

优点

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

2.3.2.EFK/ELK ( Elasticsearch+Fluentd/Logstash+Kibana )日志架构

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

组件名称实例数CPU内存硬盘总量
Elasticsearch3/54C8G600G
Fluentd/Logstash视平台服务器数量而定2C4G-
Kibana11C2G-

表 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 的作用,更倾向于监控管理集群,再通过统一网关组件进行日志查询。建议资源列表如下:

组件名称实例数CPU内存硬盘总量
Elasticsearch15-2130C60G16.5T
Filebeat10以上2C4G-
Zookeeper9-182C4G450-900G
Kafka9-182C4G4.5-9T
Kibana11C2G-

表 5:日志架构资源列表

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

角色名称角色作用CPU内存硬盘总量
Coordinate协调节点,相当于集群网关30C60G200G
Master主节点,管理集群20C40G200G
Data数据节点,存储集群数据30C60G16T
Vote仲裁节点,协助选举2C4G50G

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

架构图如下:

图 5:日志架构图

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

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

组件名称实例数CPU内存硬盘总量
Elasticsearch15-2130C60G16.5T
Filebeat10以上2C4G-
Logstash10以上4C8G-
Fluentd10以上4C8G-
Zookeeper9-182C4G450-900G
Kafka9-182C4G4.5-9T
Kibana11C2G-

表 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 小节方案相似,此处不再赘述。

四、结语

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

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

4

添加新评论7 条评论

jillmejillme课题专家组CIO某大型银行
2024-04-03 08:09
金融策略的加强,服务微泛化,对日志保留、检索、使用的愈发迫切,本文章详细介绍了日志中心的组件和详细构建过程,并综合多方面因素阐述了选型的依据基础和容灾建设,是一批难得的技术好文。 参考性强。
bysonbyson存储研发工程师平安科技(深圳)有限公司
2024-03-27 14:54
日志中心是系统必不可少的一个模块,根据场景选择最合适的模块组合才能有效发挥日志中心的作用,为更快速准确的发现和定位问题提供帮助。文章先对日志中心常用组件进行介绍,然后根据不同的场景给出了不同架构的选择,甚至对用到的资源都给出了建议,内容详实,图文并茂,可阅读性比较强,具有很好的参考意义。
wangzk0206wangzk0206数据库管理员scrcu
2024-03-22 10:20
这篇文章从组件的基本概念入手,结合大家的诉求,概述了两种常见的日志平台架构的使用场景、以及生命周期管理。同时也详细的描述了我们比较头痛的分布式架构中网络带宽问题的解决思路。是一篇十分具有参考价值的文章。
朱向东朱向东课题专家组高级工程师某银行
2024-03-21 10:47
这篇文章是一篇高质量的技术文章,覆盖了从简易系统到大型企业级日志中心的多种场景,为读者提供了全面的架构设计参考。不仅讨论了日志收集和存储的技术组件,还涉及了数据处理、传输和可视化的工具。对于需要在日志管理领域做出决策的IT专业人员来说,提供了宝贵的信息和实用的建议。
NetSecNetSec信息安全某银行
2024-03-20 10:36
elk不管是作为企业级监控还是个人小工具,都是很灵活的,本文详细介绍了各个组建,有助于各位运维小伙伴搭建自己的监控平台,值得推荐
Senko leeSenko lee课题专家组系统架构师江西裕民银行
2024-03-20 09:51
作者从不同场景、不同规模、不同架构等多方面对日志平台ELK/EFK架构进行了技术分享,对读者所属不同规模企业都有很强的借鉴意义,图表丰富,非常有意义的文章。
menglunyangmenglunyang课题专家组系统工程师中国银行
2024-03-20 09:34
文章提供了关于日志平台Elasticsearch运维架构选型的全面介绍,包括常见的日志组件和不同规模系统的架构建议。详细解释了每个组件的功能和它们如何集成在一起,以及如何根据不同的业务需求选择合适的架构。还涉及了日志数据的生命周期管理和容灾备份策略,这对于确保数据的持久性和可靠性至关重要。文章内容丰富,结构清晰,对于理解和规划日志系统的架构非常有帮助。特别是对于那些需要处理大量日志数据的企业来说,这些信息可以帮助他们做出更明智的技术决策。此外,文章中提到的资源列表和架构图提供了直观的参考,使得复杂的信息更易于理解。
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广