一、ELK Stack 简介
ELK 不是一款软件，而是 Elasticsearch、Logstash 和 Kibana 三种软件产品的首字母缩写。这三者都是开源软件，一般合作运用，并且又先后归于 Elastic.co 公司名下，所以被简称为 ELK Stack。根据 Google Trend 的信息显示，ELK Stack 已经成为现在最盛行的集中式日志处理方案。
-
Elasticsearch：散布式查找和剖析引擎，具有高可伸缩、高牢靠和易管理等特色。根据 Apache Lucene 构建，能对大容量的数据进行挨近实时的存储、查找和剖析操作。一般被用作某些应用的根底查找引擎，使其具有复杂的查找功用；
-
Logstash：数据收集引擎。它支撑动态的从各种数据源收集数据，并对数据进行过滤、剖析、丰厚、统一格式等操作，然后存储到用户指定的位置；
-
Kibana：数据剖析和可视化渠道。一般与 Elasticsearch 合作运用，对其中数据进行查找、剖析和以统计图表的方式展现；
-
Filebeat：ELK 协议栈的新成员，一个轻量级开源日志文件数据收集器，根据 Logstash-Forwarder 源代码开发，是对它的替代。在需要收集日志数据的 server 上安装 Filebeat，并指定日志目录或日志文件后，Filebeat 就能读取数据，迅速发送到 Logstash 进行解析，亦或直接发送到 Elasticsearch 进行集中式存储和剖析。
二、ELK 常用架构及运用场景介绍
2.1、最简单架构
在这种架构中，只有一个 Logstash、Elasticsearch 和 Kibana 实例。Logstash 经过输入插件从多种数据源（比方日志文件、标准输入 Stdin 等）获取数据，再经过滤插件加工数据，然后经 Elasticsearch 输出插件输出到 Elasticsearch，经过 Kibana 展现。
这种架构十分简单，运用场景也有限。初学者能够建立这个架构，了解 ELK 如何作业。
2.2、Logstash 作为日志收集器
这种架构是对上面架构的扩展，把一个 Logstash 数据收集节点扩展到多个，散布于多台机器，将解析好的数据发送到 Elasticsearch server 进行存储，最终在 Kibana 查询、生成日志报表等。
这种结构因为需要在各个服务器上布置 Logstash，而它比较消耗 CPU 和内存资源，所以比较合适核算资源丰厚的服务器，否则简单形成服务器性能下降，甚至可能导致无法正常作业。
2.3、Beats 作为日志收集器
这种架构引进 Beats 作为日志收集器。现在 Beats 包括四种：
-
Packetbeat（收集网络流量数据）；
-
Topbeat（收集体系、进程和文件体系级别的 CPU 和内存运用状况等数据）；
-
Filebeat（收集文件数据）；
-
Winlogbeat（收集 Windows 事情日志数据）。
Beats 将收集到的数据发送到 Logstash，经 Logstash 解析、过滤后，将其发送到 Elasticsearch 存储，并由 Kibana 呈现给用户。
这种架构处理了 Logstash 在各服务器节点上占用体系资源高的问题。相比 Logstash，Beats 所占体系的 CPU 和内存几乎能够忽略不计。另外，Beats 和 Logstash 之间支撑 SSL/TLS 加密传输，客户端和服务器双向认证，保证了通讯安全。
因此这种架构合适对数据安全性要求较高，同时各服务器性能比较敏感的场景。
2.4、引进音讯行列机制的架构
Beats 还不支撑输出到音讯行列，所以在音讯行列前后两端只能是 Logstash 实例。这种架构运用 Logstash 从各个数据源收集数据，然后经音讯行列输出插件输出到音讯行列中。现在 Logstash 支撑 Kafka、Redis、RabbitMQ 等常见音讯行列。然后 Logstash 经过音讯行列输入插件从行列中获取数据，剖析过滤后经输出插件发送到 Elasticsearch，最终经过 Kibana 展现。
这种架构合适于日志规划比较庞大的状况。但由于 Logstash 日志解析节点和 Elasticsearch 的负荷比较重，可将他们配置为集群形式，以分担负荷。引进音讯行列，均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，但依然存在 Logstash 占用体系资源过多的问题。
说了这么多理论，对于喜爱就干的小编来说，下面我将以Beats 作为日志收集器的架构，进行详细安装介绍！
