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


本文地址:http://www.6aiq.com/article/1569492584196
知乎专栏 点击关注
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出

背景

随着 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 审计日志); 



系统架构

第一种 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 各种业务场景下的落地和实践。


本文地址:http://www.6aiq.com/article/1569492584196
知乎专栏 点击关注
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出