基于 Elastic Stack 的海量日志分析平台实践

背景

随着 58 集团业务的飞速发展，日志数量也呈现指数级增长。传统的日志处理方案，已不再适用，此时急需一套功能强大、稳定可靠的日志处理系统。

为解集团燃眉之急，DB 部门自 2018 年初着手调研解决方案，经多方论证，最终确定使用 Elastic Stack 处理海量日志数据。

通过 Elastic Stack 搭建的集中式日志系统，具有以下几个主要特点：

• 收集－能够采集多种来源的日志数据；

• 传输－能够稳定的把日志数据传输到中央系统；

• 存储－如何存储日志数据；

• 分析－可以支持 UI 分析；

• 警告－能够提供错误报告，监控机制；

Elastic Stack 在提供了一整套解决方案的同时，可与其他开源软件之间互相配合使用，完美衔接，高效的满足了很多场合的应用。

Elastic Stack 简介

Elastic Stack 包括 Beats、Elasticsearch、Logstash、Kibana、APM 等，ELK 是其核心套件。

Elasticsearch 是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放 REST 和 Java API 等结构提供高效搜索功能，可扩展的分布式系统。它构建于 Apache Lucene 搜索引擎库之上。

Logstash 是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和 JMX，它能够以多种方式输出数据，包括电子邮件、websockets 和 Elasticsearch。

Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据。它利用 Elasticsearch 的 REST 接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。

Beats 是轻量级数据采集工具，包括：

1.Packetbeat（搜集网络流量数据）；

2.Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）；

3.Filebeat（搜集文件数据）；

4.Winlogbeat（搜集 Windows 事件日志数据）

5.Metricbeat（收集系统级的 CPU 使用率、内存、文件系统、磁盘 IO 和网络 IO 统计数据）；

6.Auditbeat（采集 Linux 审计日志）； 

• 本文地址：基于 Elastic Stack 的海量日志分析平台实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

系统架构

第一种 ELK 架构，是最简单的一种 ELK 架构方式。优点是搭建简单，易于上手。缺点是 Logstash 耗资源较大，运行占用 CPU 和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议小规模集群使用。此架构首先由 Logstash 分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的 Elasticsearch 进行存储。

Elasticsearch 将数据以分片的形式压缩存储并提供多种 API 供用户查询，操作。用户亦可以更直观的通过配置 Kibana Web Portal 方便的对日志查询，并根据数据生成报表。

第二种架构，引入了消息队列机制，位于各个节点上的 Logstash Agent 先将数据/日志传递给 Kafka（或者 Redis），并将队列中消息或数据间接传递给 Logstash，Logstash 过滤、分析后将数据传递给 Elasticsearch 存储。最后由 Kibana 将日志和数据呈现给用户。因为引入了 Kafka（或者 Redis）,所以即使远端 Logstash server 因故障停止运行，数据将会先被存储下来，从而避免数据丢失。这种架构适合于较大集群的解决方案，但由于 Logstash 中心节点和 Elasticsearch 的负荷会比较重，可将他们配置为集群模式，以分担负荷，这种架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在 Logstash 占用系统资源过多的问题。

第三种架构，引入了 Logstash-forwarder。首先，Logstash-forwarder 将日志数据搜集并统一发送给主节点上的 Logstash，Logstash 分析、过滤日志数据后发送至 Elasticsearch 存储，并由 Kibana 最终将数据呈现给用户。这种架构解决了 Logstash 在各计算机点上占用系统资源较高的问题。经测试得出，相比 Logstash，Logstash-forwarder 所占用系统 CPU 和 MEM 几乎可以忽略不计。另外，Logstash-forwarder 和 Logstash 间的通信是通过 SSL 加密传输，起到了安全保障。如果是较大集群，用户亦可以如结构三那样配置 logstash 集群和 Elasticsearch 集群，引入 High Available 机制，提高数据传输和存储安全。更主要的配置多个 Elasticsearch 服务，有助于搜索和数据存储效率。但在此种架构下发现 Logstash-forwarder 和 Logstash 间通信必须由 SSL 加密传输，这样便有了一定的限制性。

第四种架构，将 Logstash-forwarder 替换为 Beats。经测试，Beats 满负荷状态所耗系统资源和 Logstash-forwarder 相当，但其扩展性和灵活性有很大提高。Beats platform 目前包含有 Packagebeat、Topbeat 和 Filebeat 三个产品，均为 Apache 2.0 License。同时用户可根据需要进行二次开发。这种架构原理基于第三种架构，但是更灵活，扩展性更强。同时可配置 Logstash 和 Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

系统架构一个例子：MySQL 日志审计系统

MySQL 日志审计系统，采用 percona audit 插件审计 MySQL 的访问情况，结果记录到指定文件中。通过 Rsyslog 将每个 MySQL 审计日志集中到 Rsyslog Server 的指定目录中，使用 filebeat 监控文件变化，上报到 kafka。使用 Logstash 消费数据，把数据过滤切割后，写入 ES 中，用户通过 kibana 查询相关数据。

系统架构图如下：

由于使用 Percona 版本的 MySQL Server，因此审计采用 Percona 的审计插件。为了避免消耗过多性能，审计日志只记录连接情况，输出到文件中。

收集到的审计日志，通过 Rsyslog 的 imfile 模块，采集审计日志，发送到 Rsyslog Server 上统一存储。

Rsyslog 上接收到的文件，通过 filebeat 上报 kafka。之后，Logstash 负责消费 kafka 的数据，过滤切割后，写入到 ES 中。

用户可以在 kibana 中查询自己所需的数据，如下图：

总结

目前，上报到公司 kafka 的日志，皆可接入数据库部门的 ES，可通过 kibana 统一查询、分析，协助排查错误、分析性能。后续通过接入更多的 beats 组件，来丰富 ES 日志平台的使用场景。

作者简介

旋凯，58 集团高级 DBA，负责大规模 MySQL 数据库集群架构设计和性能优化，新型数据库如 Elasticsearch、TiDB 等前沿技术的调研及在 58 各种业务场景下的落地和实践。