Elasticsearch 实战与原理解析 - 第 10 章 Elasticsearch 生态圈

Posted 2020-12-21 marlonkang

第 10 章 Elasticsearch 生态圈

天际浮云入思深

物情生态看销沉

第 9 章介绍了 Elasticsearch 的插件生态，插件生态是依托于 Elasticsearch 内部的，属于一种相对狭义、微观的生态；本章主要介绍 Elasticsearch 的宏观生态。

10.6 小结

本章主要介绍了 Elasticsearch 的生态圈，即 ELK Stack。先后介绍了 ELK Stack 的背景、ELK 的实战部署架构设计，以及 Logstash、Kibana 和 Beats。

10.1 ELK

提到 Elasticsearch 生态，很多人第一反应就是 ELK Stack。什么是 ELK Stack 呢？很简单，ELK Stack 指的就是 Elastic Stack。

10.1.1 Elastic Stack

「ELK」是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana，如图 10-1 所示。当然，这并非是 Elastic Stack 的全部，读者可以根据需要在生态中添加 Redis、Kafka、Filebeat 等软件。

当前的 Elastic Stack 其实是 ELK Stack 的更新换代产品。2015 年，ELK Stack 中加入了一系列轻量级的单一功能数据采集器，并把它们叫作 Beats。

Beats 加入 ELK 家族后，再叫 ELK 显然不太合适，那么新的家族叫什么呢？

其实，Elastic 官方当时也的确想继续沿用首字母缩写的方式，但 Elastic 又相继收购了 APM 公司 Opbeat、机器学习公司 Prelert、SaaS 服务公司 Found、搜索服务公司 Swiftype、终端安全公司 Endgame 等来扩大自己的商业版图。

对于 Elastic 扩展速度如此之快的生态而言，一直采用首字母缩写的确不是长久之计。于是，Elastic Stack 这个「一劳永逸」般的名字就诞生了。

10.1.2 Elastic Stack 版本的由来

Elasticsearch 的版本号从 2 直接升到 5 是怎么回事呢？

在最初的 Elastic Stack 生态中，Elasticsearch、Logstash、Kibana 和 Beats 有各自的版本号，如当 Elasticsearch 和 Logstash 的版本号是 V2.3.4 时，Kibana 的版本号是 V4.5.3，而 Beats 的版本号是 V1.2.3。

因此，Elastic Stack 官方将产品版本号也进行了统一，从 V5.0 开始。因为当时的 Kibana 版本号已经是 4.x 了，其下个版本只能是 5.0，所以其他产品的版本号也随之「跳级」，于是 V5.0 版本的 Elastic Stack 在 2016 年就面世了。

10.1.3 ELK 实战的背景

在实际使用过程中，什么场景适合使用 ELK 呢？

在实战中，我们既可以用 ELK 管理和分析日志，也可以用 ELK 分析索引中的数据。

在当前的软件开发过程中，业务发展节奏越来越快，服务器梳理越来越多，随之而来的就是各种访问日志、应用日志和错误日志。随着时间的流逝，日志的累积也越来越多。

此时，会出现这样的问题：运维人员无法很好地管理日志；开发人员排查业务问题时需要到服务器上查询大量日志；当运营人员需要一些业务数据时，需要到服务器上分析日志。

在上述场景中，通常意义上的「awk」和「grep」命令已经力不从心，而且效率很低。这时 ELK 就可以「隆重登场」啦！

ELK 的三个组件是如何分工协作的呢？

首先，我们使用 Logstash 进行日志的搜集、分析和过滤。一般工作方式为 C/S 架构，Client 端会被安装在需要收集日志的主机上，Server 端则负责收集的各节点的日志数据，并进行过滤、修改和分析等操作，预处理过的数据会一并发到 Elasticsearch 上。

随后将 Kibana 接入 Elasticsearch，并为 Logstash 和 Elasticsearch 提供日志分析友好的 Web 界面，帮助用户汇总、分析和搜索重要数据的日志。

10.1.4 ELK 的部署架构变迁

ELK 架构为数据分布式存储、可视化查询和日志解析创建了一个功能强大的管理链。ELK 架构为用户建立了集中式日志收集系统，将所有节点上的日志统一收集、管理和访问。三者相互配合，取长补短，共同完成分布式大数据处理工作。

当前官方推荐的 ELK 部署架构并非一步到位，而是经过迭代演进发展而来的。下面简单介绍 ELK 架构的发展历程。

最简单的一种 ELK 部署架构方式如图 10-2 所示。

首先由分布于各个服务节点上的 Logstash 搜集相关日志和数据，经过 Logstash 的分析和过滤后发送给远端服务器上的 Elasticsearch 进行存储。Elasticsearch 将数据以分片的形式压缩存储，并提供多种 API 供用户进行查询操作。用户还可以通过配置 Kibana Web Portal 对日志进行查询，并根据数据生成报表。

该架构最显著的优点是搭建简单，易于上手。但缺点同样很突出，因为 Logstash 消耗资源较大，所以在运行时会占用很多的 CPU 和内存。并且系统中没有消息队列缓存等持久化手段，因而存在数据丢失隐患。因此，一般这种部署架构通常用于学习和小规模集群。

基于第一种 ELK 部署架构的优缺点，第二种架构引入了消息队列机制，如图 10-3 所示。

位于各个节点上的 Logstash 客户端先将数据和日志等内容传递给 Kafka，当然，也可以用其他消息机制，如各类 MQ（Message Queue）和 Redis 等。

Kafka 会将队列中的消息和数据传递给 Logstash，经过 Logstash 的过滤和分析等处理后，传递给 Elasticsearch 进行存储。最后由 Kibana 将日志和数据呈现给用户。

在该部署架构中，Kafka 的引入使得即使远端 Logstash 因故障而停止运行，数据也会被存储下来，从而避免数据丢失。

第二种部署架构解决了数据的可靠性问题，但 Logstash 的资源消耗依然较多，因而引出第三种架构。第三种架构引入了 Logstash-forwarder，如图 10-4 所示。

Logstash-forwarder 将日志数据搜集并统一后发送给主节点上的 Logstash，Logstash 在分析和过滤日志数据后，把日志数据发送至 Elasticsearch 进行存储，最后由 Kibana 将数据呈现给用户。

这种架构解决了 Logstash 在各计算机点上占用系统资源较多的问题。与 Logstash 相比，Logstash-forwarder 所占系统的 CPU 和内存几乎可以忽略不计。

而且，Logstash-forwarder 的数据安全性更好。Logstash-forwarder 和 Logstash 之间的通信是通过 SSL 加密传输的，因此安全有保障。

随着 Beats 组件引入 ELK Stack，第四种部署架构应运而生，如图 10-5 所示。

在实际使用中，Beats 平台在满负荷状态时所耗系统资源和 Logstash-forwarder 相当，但其扩展性和灵活性更好。Beats 平台目前包含 Packagebeat、Topbeat 和 Filebeat 三个产品，均为 Apache 2.0 License。同时用户可以根据需要进行二次开发。

与前面三个部署架构相比，显然第四种架构更灵活，可扩展性更强。

用户可以根据自己的需求搭建自己的 ELK。

 

10.2 Logstash

10.2.1 Logstash 简介

Logstash 由三部分组成，即输入模块（INPUTS）、过滤器模块（FILTERS）和输出模块（OUTPUTS），如图 10-6 所示。

Logstash 能够动态地采集、转换和传输数据，不受格式或复杂度的影响。利用 Grok 从非结构化数据中派生出结构，从 IP 地址解码出地理坐标，匿名化或排除敏感字段，并简化整体处理过程。

从官网下载 Logstash 安装包。下载完成后，在本地解压缩。解压缩后的根目录内容如图 10-7 所示。

根目录下有 bin、config、data、lib、logstash core 和 tools 等内容。

在 Logstash 启动后，会自动创建 logs 目录。随后配置 config 目录下的 logstash.conf 文件。首次配置时可参考同目录的 logstash-simple.conf 示例进行配置。配置后，执行 bin/logstash-f logstash.conf 即可启动 Logstash 服务，如下所示：

 

 

 此时，在浏览器中输入http://localhost:9600/，浏览器的页面中即可输出如下内容：

 

 

 需要指出的是，Logstash 文件夹存放的路径中不能有中文命名的文件夹，否则会给出错误提示。

10.2.2 Logstash 的输入模块

Logstash 的输入模块用于采集各种样式、大小和来源的数据。一般来说，数据往往以各种各样的形式，或分散或集中地存储于很多系统中。Logstash 支持各种输入选择，可以在同一时间从众多常用来源捕捉事件，能够以流式传输方式，轻松地从用户的日志、指标、Web 应用、数据存储及各种 AWS 服务中采集数据。

为了支持各种数据输入，Logstash 提供了很多输入插件，汇总如下。

（1）azure_event_hubs：该插件从微软 Azure 事件中心接收数据。读者可访问 GitHub 官网，搜索 logstash-input-azure_event_hubs 获取插件。

（2）beats：该插件从 Elastic Beats 框架接收数据。读者可访问 GitHub 官网，搜索 logstash-input-beats 获取插件。

（3）cloudwatch：该插件从 Amazon Web Services CloudWatch API 中提取数据。读者可访问 GitHub 官网，搜索 logstash-input-cloudwatch 获取插件。

（4）couchdb_changes：该插件从 CouchDB 更改 URI 的流式处理事件中获取数据。读者可访问 GitHub 官网，搜索 logstash-input-couchdb_changes 获取插件。

（5）dead_letter_queue：该插件从 logstash 的 dead letter 队列中读取数据。读者可访问 GitHub 官网，搜索 logstash-input-dead_letter_queue 获取插件。

（6）elasticsearch：该插件从 ElasticSearch 群集中读取查询结果。读者可访问 GitHub 官网，搜索 logstash-input-elasticsearch 获取插件。

（7）exec：该插件将 shell 命令的输出捕获为事件，并获取数据。读者可访问 GitHub 官网，搜索 logstash-input-exec 获取插件。

（8）file：该插件从文件流式处理中获取数据。读者可访问 GitHub 官网，搜索 logstash-input-file 获取插件。

（9）ganglia：该插件通过 UDP 数据包读取 ganglia 中的数据包来获取数据。读者可访问 GitHub 官网，搜索 logstash-input-ganglia 获取插件。

（10）gelf：该插件从 graylog2 中读取 gelf 格式的消息获取数据。读者可访问 GitHub 官网，搜索 logstash-input-gelf 获取插件。

（11）http:该插件通过 HTTP 或 HTTPS 接收事件获取数据。读者可访问 GitHub 官网，搜索 logstash-input-http 获取插件。

（12）jdbc：该插件通过 JDBC 接口从数据库中获取数据。读者可访问 GitHub 官网，搜索 logstash-input-jdbc 获取插件。

（13）kafka：该插件从 Kafka 主题中读取事件，从而获取数据。读者可访问 GitHub 官网，搜索 logstash-input-kafka 获取插件。

（14）log4j：该插件通过 TCP 套接字从 Log4J SocketAppender 对象中读取数据。读者可访问 GitHub 官网，搜索 logstash-input-log4j 获取插件。

（15）rabbitmq：该插件从 RabbitMQ 数据交换中提取数据。读者可访问 GitHub 官网，搜索 logstash-input-rabbitmq 获取插件。

https://github.com/logstash-plugins/logstash-input-rabbitmq

（16）redis：该插件从 redis 实例中读取数据。读者可访问 GitHub 官网，搜索 logstash-input-redis 获取插件。

10.2.3 Logstash 过滤器

Logstash 过滤器用于实时解析和转换数据。

在数据从源传输到存储库的过程中，Logstash 过滤器能够解析各个数据事件，识别已命名的字段，构建对应的数据结构，并将它们转换成通用格式，以便更轻松、更快速地进行分析，实现商业价值。

Logstash 过滤器有以下特点：

（1）利用 Grok 从非结构化数据中派生出结构。

（2）从 IP 地址破译出地理坐标。

（3）将 PII 数据匿名化，完全排除敏感字段。

（4）简化整体处理，不受数据源、格式或架构的影响。

为了处理各种各样的数据源，Logstash 提供了丰富多样的过滤器库，常用的过滤器插件汇总如下。

（1）aggregate：该插件用于从一个任务的多个事件中聚合信息。读者可访问 GitHub 官网，搜索 logstash-filter-aggregate 获取插件。

（2）alter：该插件对 mutate 过滤器不处理的字段执行常规处理。读者可访问 GitHub 官网，搜索 logstash-filter-alter 获取插件。

（3）bytes：该插件将以计算机存储单位表示的字符串形式，如「123MB」或「5.6GB」，解析为以字节为单位的数值。读者可访问 GitHub 官网，搜索 logstash-filter-bytes 获取插件。

（4）cidr：该插件根据网络块列表检查 IP 地址。读者可访问 GitHub 官网，搜索 logstash-filter-cidr 获取插件。

（5）cipher：该插件用于对事件应用增加或移除密钥。读者可访问 GitHub 官网，搜索 logstash-filter-cipher 获取插件。

（6）clone：该插件用于复制事件。读者可访问 GitHub 官网，搜索 logstash-filter-clone 获取插件。

（7）csv：该插件用于将逗号分隔的值数据解析为单个字段。读者可访问 GitHub 官网，搜索 logstash-filter-csv 获取插件。

（8）date：该插件用于分析字段中的日期，多用于事件日志中存储的时间戳。读者可访问 GitHub 官网，搜索 logstash-filter-date 获取插件。

（9）dns：该插件用于执行正向或反向 DNS 查找。读者可访问 GitHub 官网，搜索 logstash-filter-dns 获取插件。

（10）elasticsearch：该插件用于将 Elasticsearch 日志事件中的字段复制到当前事件中。读者可访问 GitHub 官网，搜索 logstash-filter-elasticsearch 获取插件。

（11）geoip 该插件用于添加有关 IP 地址的地理信息。读者可访问 GitHub 官网，搜索 logstash-filter-geoip 获取插件。

（12）json：该插件用于解析 JSON 事件。读者可访问 GitHub 官网，搜索 logstash-filter-json 获取插件。

（13）kv：该插件用于分析键值对。读者可访问 GitHub 官网，搜索 logstash-filter-kv 获取插件。

（14）memcached：该插件用于提供与 memcached 中数据的集成。读者可访问 GitHub 官网，搜索 logstash-filter-memcached 获取插件。

（15）split：该插件用于将多行消息拆分为不同的事件。读者可访问 GitHub 官网，搜索 logstash-filter-split 获取插件。

10.2.4 Logstash 的输出模块

Logstash 的输出模块用于将目标数据导出到用户选择的存储库。

在 Logstash 中，尽管 Elasticsearch 是 Logstash 官方首选的，但它并非唯一选择。

Logstash 提供众多输出选择，用户可以将数据发送到指定的地方，并且能够灵活地解锁众多下游用例。

（1）csv：该插件以 CVS 格式将结果数据写入磁盘。读者可访问 GitHub 官网，搜索 logstash-output-csv 获取插件。

（2）mongodb：该插件将结果数据写入 MongoDB。读者可访问 GitHub 官网，搜索 logstash-output-mongodb 获取插件。

（3）elasticsearch：该插件将结果数据写入 Elasticsearch。读者可访问 GitHub 官网，搜索 logstash-output-elasticsearch 获取插件。

（4）email：该插件将结果数据发送到指定的电子邮件。读者可访问 GitHub 官网，搜索 logstash-output-email 获取插件。

（5）kafka：该插件将结果数据写入 Kafka 的 Topic 主题。读者可访问 GitHub 官网，搜索 logstash-output-kafka 获取插件。

（6）file：该插件将结果数据写入磁盘上的文件。读者可访问 GitHub 官网，搜索 logstash-output-file 获取插件。

（7）redis：该插件使用 redis 中的 rpush 命令将结果数据发送到 redis 队列。读者可访问 GitHub 官网，搜索 logstash-output-redis 获取插件。