在实际搭建日志中心的过程中,对于架构选项有很多疑惑,甚至技术栈不清楚用哪些,由于本身是日志模块,属于系统的侧面,该场景下,大部分用户对于日志数据的专业性要求并不是很多,故而会一昧的使用传统的 ELK ( Elasticsearch+logstash+kibana )的架构模式,来构建日志模块或简易的日志中心,若只是小系统还好,场景有限,传统的 ELK 架构模式影响也有限,一些系统随着规模的扩大会出现日志量激增,新增对日志数据的检索要求,此时旧有架构可能就不足以支撑当前的诉求,因此在做日志模块或日志中心搭建时,建议根据自己的实际诉求规划好整体日志模块框架。
Logstash 是一个用于数据收集、转换和传输的开源工具,属于 Elastic Stack (以前称为 ELK Stack )的一部分。它的设计目标是处理各种不同来源的日志和事件数据,使其能够被存储、搜索和分析。
Logstash 具有以下主要特点:
Filebeat 是由 Elasticsearch 提供的一个开源日志数据收集器。它设计用于轻松收集、传输和处理日志文件或事件,然后将它们发送到 Elasticsearch 或 Logstash 等目标,以进行存储、搜索和分析。
Filebeat 主要用于监视文件变化并将其发送到指定的目标,通常与 Elastic Stack (以前称为 ELK Stack )一起使用,该堆栈包括 Elasticsearch 、 Logstash 和 Kibana 。 Filebeat 可以用于收集各种类型的日志数据,例如应用程序日志、系统日志和安全事件等。
它支持多种输入和输出插件,可以轻松集成到不同的环境中。 Filebeat 还具有轻量级和高效的特点,使其适用于在分布式环境中运行,以实现实时日志数据的收集和分析。
Fluentd 是一个开源的日志收集器和数据传输工具,可以帮助用户实现可扩展的日志收集和数据流水线。它支持多种输入和输出插件,允许从不同的数据源收集数据,并将其发送到不同的目标。
Fluentd 具有以下特点:
Apache Flume 是一个开源的分布式日志收集系统,旨在简化大规模数据流的采集、聚合和移动。 Flume 最初是为了满足 Apache Hadoop 的数据导入需求而开发的,但它也可以与其他存储和处理系统集成,不仅局限于 Hadoop 生态系统。
主要功能和特点包括:
Kafka 是一个分布式流式平台,用于构建实时数据管道和流式应用程序。 Kafka 设计用于处理大规模的实时数据流,提供高吞吐量、持久性、可扩展性和容错性。 Kafka 通常被用于构建大规模、高可用性的数据管道,用于数据集成、事件处理、日志聚合等场景。在日志和事件处理领域, Kafka 经常与其他组件(如 Flume 、 Beats 、 Logstash )一起使用,构建端到端的实时数据流水线。
Zookeeper 是一个分布式协调服务,为分布式系统提供一致性、可靠性和高性能的服务。它管理配置信息、提供命名服务、分布式同步和组服务等功能。在实际应用中, Zookeeper 和 Kafka 通常一起使用。 Zookeeper 负责 Kafka 的分布式协调和领导者选举等任务。
早期进行系统建设时,大部分简单系统在进行功能模块设计时,并不注重日志侧功能的建设,功能设计较为简单,仅在系统中增加一个简易的日志模块,存放系统操作记录日志,完备点的会存放审计类型的日志,日志数量每天在 100-500W ,大小约 40-50G 。
基于此场景下,笔者有两种日志架构选型可供参考
基于快速交付,日志量较小,无大量日志缓存诉求,日志无太多合规要求的场景,若系统设计中,日志存在需要进行预处理的场景,则可选择传统 ELK 架构。建议资源列表如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 3 | 2C | 4G | 200G |
Logstash | 1 | 2C | 4G | - |
Kibana | 1 | 1C | 2G | - |
表 1 : ELK 日志架构资源列表
优点
与 ELK 架构场景略有区别,同样是基于快速交付,但对于日志数据不需要进行预处理,该场景下则可选择 EFK 日志架构,只是将 Logstash 组件替换为了 Filebeat 组件。建议资源列表如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 3 | 2C | 4G | 200G |
Filebeat | 1 | 2C | 4G | - |
Kibana | 1 | 1C | 2G | - |
表 2:EFK 日志架构资源列表
优点
相较于第一种情况,该场景下日志模块相较来说较为完善,存储的日志种类较多,且数据量较大,需进行数据预处理,日志数量每天在 5000W 左右,大小约 400G 。
该日志架构使用 Filebeat 组件针对服务器日志文件进行采集,将采集后的日志数据发送至 Logstash 组件,对日志数据进行清洗,将清洗后的数据存入 Elasticsearch 。建议资源列表如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 3/5 | 4C | 8G | 600G |
Filebeat | 视平台服务器数量而定 | 2C | 4G | - |
Logstash | 3/5 | 2C | 4G | - |
Kibana | 1 | 1C | 2G | - |
表 3:EFLK 日志架构资源列表
优点
因为该场景下,数据量相对较大,种类相对较为丰富,该日志架构日志采集器使用 Fluentd 或 Logstash 对日志数据进行采集并清洗,再将数据传输至 Elasticsearch ,建议资源列表如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 3/5 | 4C | 8G | 600G |
Fluentd/Logstash | 视平台服务器数量而定 | 2C | 4G | - |
Kibana | 1 | 1C | 2G | - |
表 4: EFK/ELK 日志架构资源列表
优点
相较于中型平台场景,大型平台的日志模块建设已趋于完善,日志类型丰富,具备较强大的日志查询能力,且整体日志架构较为复杂,甚至需要进行日志数据的生命周期管理及容灾备份。
该架构适合不需要进行数据清洗的日志采集场景,该场景下,通过 Filebeat 组件采集日志,再将日志数据放入 Kafka 组件,最终通过消费组件将日志数据消费至 Elasticsearch ,而该场景下的 Kibana 的作用,更倾向于监控管理集群,再通过统一网关组件进行日志查询。建议资源列表如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 15-21 | 30C | 60G | 16.5T |
Filebeat | 10以上 | 2C | 4G | - |
Zookeeper | 9-18 | 2C | 4G | 450-900G |
Kafka | 9-18 | 2C | 4G | 4.5-9T |
Kibana | 1 | 1C | 2G | - |
表 5:日志架构资源列表
在此场景下,建议对 Elasticsearch 集群进行角色划分,详情如下表:
角色名称 | 角色作用 | CPU | 内存 | 硬盘总量 |
Coordinate | 协调节点,相当于集群网关 | 30C | 60G | 200G |
Master | 主节点,管理集群 | 20C | 40G | 200G |
Data | 数据节点,存储集群数据 | 30C | 60G | 16T |
Vote | 仲裁节点,协助选举 | 2C | 4G | 50G |
表 6: Elasticsearch 集群节点角色列表
该架构主要使用了 Fluentd 或同样作用的 Filebeat 与 Logstash 组件,采集日志数据,并对其进行数据清洗,将数据存放至 Kafka ,再将数据通过消费组件写入 Elasticsearch 集群。建议资源如下:
组件名称 | 实例数 | CPU | 内存 | 硬盘总量 |
Elasticsearch | 15-21 | 30C | 60G | 16.5T |
Filebeat | 10以上 | 2C | 4G | - |
Logstash | 10以上 | 4C | 8G | - |
Fluentd | 10以上 | 4C | 8G | - |
Zookeeper | 9-18 | 2C | 4G | 450-900G |
Kafka | 9-18 | 2C | 4G | 4.5-9T |
Kibana | 1 | 1C | 2G | - |
表 7:日志架构资源列表
此场景下, Elasticsearch 集群的节点角色可按照 3.3.1. 中的表 6 进行划分,此外需特别注意 Logstash 建议以集群形式进行部署,以提高日志数据的清洗速率。
### 3.4. 日志生命周期策略
日志生命周期策略图如下:
图 7:日志生命周期策略图
如图 7所示,这种平台下的日志一般会对 Elasticsearch 集群设置基础的生命周期策略,大多数场景下,一般会维持 1-7 天的热数据,此时数据读写频繁, 7-30 天时, Elasticsearch 早期索引写入数据的场景几乎消失,读数据场景较为频繁, 30 天后,读数据场景几乎消失(很少场景下会查询 30 天后的日志数据),进而变为冷数据,最终删除。
需要注意的是,该策略需要根据实际情况设置,一些场景下,数据无需由热 - 温 - 冷,而是直接由热数据变为冷数据,此时便可省去温数据的阶段,减轻 Elasticsearch 集群资源消耗。
由图8可知,可以通过 mirror-maker 工具同步两侧机房中 kafka 的日志数据,再由各自机房的消费组件将日志消费写入 Elasticsearch 集群。
由图 9可知,可通过消费组件双写日志数据至两侧机房的 Elasticsearch 集群,但该场景需尽可能的保证数据的一致性,对于数据强一致性场景来说,不太适用。
由图 10可知,可使用 Elasticsearch 集群的 CCR 功能进行日志同步操作,甚至可进行两侧集群双向同步即双活架构,但该功能需要使用企业级证书,此外,还可以使用 Elasticsearch 集群的辅助工具,如 elasticserach-dump , esm 等。
相较于之前所有的场景,日志中心的建设要复杂得多,首先所需服务器的资源量是庞大的,其次需要占用大量的带宽,此外,由于是企业级别日志中心,还需满足用户侧实际情况的定开场景,如:多租户支持,实时监控分析,可对接或集成其他运维工具,最后还要考虑容灾备份的场景。
该场景下日志架构选项参考 3.3 章节,只是相对来说,所需资源量要大很多, Elasticsearch 集群规模(节点数 100-500 ,进行特定的角色划分)此处不进行赘述,仅以机房 /AZ 视角给出建议架构,仅供参考。
如图所示,为笔者曾遇到过的日志中心的场景,各机房 /AZ 接收各自的日志数据,再通过统一网关组件进行日志查询,由于各自接收自身机房的日志数据,故而该场景下,相对来说 Elasticsearch 集群所需资源相对较小。
与之前架构不同的是,该架构所有机房 /AZ 的日志数据接写入至一套 Elasticsearch 集群,再由 Elasticsearch 集群侧进行日志数据同步,好处是不用根据机房的数量维护对应数量的 Elasticsearch 集群,但坏处是,这一套 Elasticsearch 集群所需相对来说大量的服务器资源,且日志写入压力相对较大,要承担所有机房的日志数据。
该规模的日志中心,往往可对数据做较长时间的保留,而且在一个月内对于日志的读写都很频繁,故而热数据周期一般设置为 0-1 个月,温数据周期设置为 1 年左右,将 1-3 年的数据设置为冷数据,超过三年后的数据,将做归档处理,存入磁带库中进行保存。
该场景下日志容灾备份策略技术组件层方案与第三章节 3.5 小节方案相似,此处不再赘述。
本次介绍了日志模块常使用的技术组件,以及常见日志场景下的几种技术架构选型,希望可以给大家在进行日志模块 / 中心建设规划时一个大致的参考。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论8 条评论
6天前
2024-04-03 08:09
2024-03-27 14:54
2024-03-22 10:20
2024-03-21 10:47
2024-03-20 10:36
2024-03-20 09:51
2024-03-20 09:34