在今天的这个教程里，我们来针对初学者如何快速地了解Beats 是什么，并如何快速地部署Beats。如果你想了解更多关于Beats方面的知识，可以参阅我的文章。
在我们开始Beats知识的讲解之前，我们首先来了解一下Elastic公司。
Elastic 总览
在之前的一些市场活动中，我发现很多的开发者和Elastics Stack的使用者都对ELK比较熟悉，但是他们对Elastic公司并不熟悉。他们很了解ELK是一个开源的软件栈，但是不知道在这个软件栈后面还有一个商业的Elastic公司的存在。简单的一句话：
Elastic 是一个搜索公司
我们可以在https://www.elastic.co/官方地址找到更多关于Elastic公司的介绍。
Elasticsearch
Elastic公司的核心的产品是Elasticsearch。关于Elasticsearch的更多描述可以在我之前的文章“Elasticsearch简介”。简单地说：
Elasticsearch是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本，数字，地理空间，结构化和非结构化。Elasticsearch基于Apache Lucene构建，并于2010年由Elasticsearch N.V.（现称为Elastic）首次发布。
Elasticsearch以其简单的REST API，分布式性质，速度和易扩展性而闻名。Elasticsearch的搜索体验的基本原则是规模（scale），速度（speed），相关性（relevance）。 总之，这三个属性是Elastic与其他属性的区别。 这些属性贯穿我们能看到的任何一个商业的示例，并且如果剥离这些层，则通常是它们使用Elastic的真正原因。
- Scale：可扩展性是指摄取和处理PB级数据的能力。Elasticsearch集群是分布式的，所以它很容根据商业的需求来扩容。如果需要存储更多的数据，我们很容添加更多的服务器来进行满足商业的需求。
- Speed：快速获得搜索结果的能力， 即使在大规模的情况下。 在中国有一种说法：天下武功唯快不破。Elasticsearch可以在PB级数据情况下，也能获得毫秒级的搜索。即使是新数据导入到Elasticsearch中，也可以在1秒内变为可以搜索，从而实现近实时的搜索。对于有的数据库来说，搜索可能是需要数小时才能完成。
- Relevance： 关联性是一种能够以任意方式查询数据并获得相关结果的能力，而不论是查看文本，数字还是地理数据。Elasticsearch可以根据数据的匹配度来返回数据。每个搜索的结果有一个分数，它表示匹配的相关度。在返回的数据结果中，匹配度最大的结果排在返回的结果的前面。
Elastic Stack
“ELK”是三个开源项目的缩写：Elasticsearch，Logstash和Kibana。 Elasticsearch是搜索和分析引擎。Elasticsearch是整个Elastic Stack的核心组件。 Logstash是一个服务器端数据处理管道，它同时从多个源中提取数据，进行转换，然后将其发送到类似Elasticsearch的“存储”中。Beats是一些轻量级的数据摄入器的组合，用于将数据发送到Elasticsearch或发向Logstash做进一步的处理，并最后导入到Elasticsearch。 Kibana允许用户在Elasticsearch中使用图表将数据可视化。
Elastic 方案
Elastic 公司围绕Elastic Stack创建了许多的开箱即用的方案。对于很多搜索或数据库的公司来说，他们可能有很好的产品，但是运用它们开发一套实现某种方案来说，也是需要很多的精力来组合不同公司的产品来完成这些方案。围绕Elastic Stack，Elastic公司推出了3+1:
在上面，我们可以看到Elastic的三大解决方案：
上面的三大解决方案基于同一个 Elastic (ELK) Stack：Elasticsearch及Kibana。
Beats是什么？
一点点历史
在集中式日志记录中，数据管道包括三个主要阶段：聚合，处理和存储。 在ELK堆栈中，传统上，前两个阶段是堆栈工作量Logstash的职责。执行这些任务需要付出一定的代价。 由于与Logstash的设计有关的内在问题，性能问题变得经常发生，尤其是在复杂的管道需要大量处理的情况下。将Logstash的部分职责外包的想法也应运而生，尤其是将数据提取任务转移到其他工具上。 正如我在本文中所描述的，这个想法首先在Lumberjack中体现出来，然后在Logstash转发器中体现出来。 最终，在随后的几个开发周期中，引入了新的改进协议，该协议成为现在所谓的“ Beats”家族的骨干。
Beats到底是什么呢？
Beats是轻量级（资源高效，无依赖性，小型）和开放源代码日志发送程序的集合，这些日志发送程序充当安装在基础结构中不同服务器上的代理，用于收集日志或指标（metrics）。这些可以是日志文件（Filebeat），网络数据（Packetbeat），服务器指标（Metricbeat）或Elastic和社区开发的越来越多的Beats可以收集的任何其他类型的数据。 收集后，数据将直接发送到Elasticsearch或Logstash中进行其他处理。Beats建立在名为libbeat的Go框架之上，该框架用于数据转发，这意味着社区一直在开发和贡献新的Beats。
Elastic beats
Filebeat
顾名思义，Filebeat用于收集和传送日志文件，它也是最常用的Beat。 Filebeat如此高效的事实之一就是它处理背压的方式-因此，如果Logstash繁忙，Filebeat会减慢其读取速率，并在减速结束后加快节奏。
Filebeat几乎可以安装在任何操作系统上，包括作为Docker容器安装，还随附用于特定平台（例如Apache，MySQL，Docker等）的内部模块，其中包含这些平台的默认配置和Kibana对象。
在我之前的几篇文章中，我已经给出来好几个例子关于如何使用Filebeat。
Packetbeat
网络数据包分析器Packetbeat是第一个引入的beat。 Packetbeat捕获服务器之间的网络流量，因此可用于应用程序和性能监视。
Packetbeat可以安装在受监视的服务器上，也可以安装在其专用服务器上。 Packetbeat跟踪网络流量，解码协议并记录每笔交易的数据。 Packetbeat支持的协议包括：DNS，HTTP，ICMP，Redis，MySQL，MongoDB，Cassandra等。
Metricbeat
Metricbeat是一种非常受欢迎的beat，它收集并报告各种系统和平台的各种系统级度量。 Metricbeat还支持用于从特定平台收集统计信息的内部模块。您可以使用这些模块和称为指标集的metricsets来配置Metricbeat收集指标的频率以及要收集哪些特定指标。更多关于Metricbeat可参照链接。
Heartbeat
Heartbeat是用于“uptime monitoring”的。本质上，Heartbeat是探测服务以检查它们是否可访问的功能，例如，它可以用来验证服务的正常运行时间是否符合您的SLA。 您要做的就是为Heartbeat提供URL和正常运行时间指标的列表，以直接发送到Elasticsearch或Logstash以便在建立索引之前发送到您的堆栈。
Auditbeat
Auditbeat可用于审核Linux服务器上的用户和进程活动。 与其他传统的系统审核工具（systemd，auditd）类似，Auditbeat可用于识别安全漏洞-文件更改，配置更改，恶意行为等。
Winlogbeat
Winlogbeat仅会引起Windows系统管理员或工程师的兴趣，因为它是专门为收集Windows事件日志而设计的节拍。 它可用于分析安全事件，已安装的更新等。
Functionbeat
Functionbeat被定义为“serverless”的发件人，可以将其部署为收集数据并将其发送到ELK堆栈的功能。 Functionbeat专为监视云环境而设计，目前已针对Amazon设置量身定制，可以部署为Amazon Lambda函数，以从Amazon CloudWatch，Kinesis和SQS收集数据。
社区beats
开源社区一直在努力开发新的Beats。对社区Beats有疑问吗？ 您可以在Beat讨论论坛的Community Beats类别中发布问题并讨论问题。目前有超过90个Beat。如果大家有发现有用的Beat，你可以直接下载并使用。如果你坚持想自己开发属于自己的Beat，请参阅我之前的文章“如何创建一个定制的Elastic Beat”。
Beats在Elastic堆栈中是如何融入的？
到目前为止，有如下的3中方式能够把我们所感兴趣的数据导入到Elasticsearch中:
正如上面所显示的那样，我们可以通过：
- Beats：我们可以通过beats把数据导入到Elasticsearch中
- Logstash：我们可以Logstash把数据导入。Logstash的数据来源也可以是Beats
- REST API：我们可以通过Elastic所提供的丰富的API来把数据导入到Elasticsearch中。我们可以通过Java, Python, Go, Nodejs等各种Elasticsearch API来完成我们的数据导入。
那么针对Beats来说，Beats是如何和其它的Elastic Stack一起工作的呢？我们可以看如下的框图：
从上面我们可以看出来，Beats的数据可以有如下的三种方式导入到Elasticsearch中：
- Beats ==> Elasticsearch
- Beats ==> Logstash ==> Elasticsearch
- Beats ==> Kafka ==> Logstash ==> Elasticsearch
正如上面所显示的那样：
- 我们可以直接把Beats的数据传入到Elasticsearch中，甚至在现在的很多情况中，这也是一种比较受欢迎的一种方案。它甚至可以结合Elasticsearch所提供的pipeline一起完成更为强大的组合。
- 我们可以利用Logstash所提供的强大的filter组合对数据流进行处理：解析，丰富，转换，删除，添加等等。你可以参阅我之前的文章“Data转换，分析，提取，丰富及核心操作”
- 针对有些情况，如果我们的数据流具有不确定性，比如可能在某个时刻生产大量的数据，从而导致Logstash不能及时处理，我们可以通过Kafka来做一个缓存。你可以参考我的文章“使用Kafka部署Elastic Stack”。
摄入通道（ingest pipeline)
我们知道在Elasticsearch的节点中，有一类节点是ingest node。ingest pipeline运行于ingest node之上。它提供了在对文档建立索引之前对其进行预处理的功能
- 解析，转换并丰富数据
- 管道允许您配置将要使用的处理器
在上面的图中，我们可以看出来，我们可以使用在Elasticsearch集群里的ingest node来运行我们所定义的processors。这些processors定义于Elastic的官方文档Processors。
Libeat - 创建Beats的Go架构
Libbeat是一个用于数据转发的库。Beats构建在名为libbeat的Go框架之上。 它是一个开源的软件。我们可以在地址https://github.com/elastic/beats/tree/master/libbeat 找到它的源码。它可以轻松为您想要发送到Elasticsearch的任何类型的数据创建自定义Beat。
如果你想构建自己的Beat的话，你可以参阅如下的文章：
你也可以参阅我之前创建的文章“如何创建一个定制的Elastic Beat”。
对于一个beat来说，它可以分为如下的两个部分：数据收集器，数据处理器及发布器。后面的这个部分由libbeat来提供。
上面的processor可以由Define processors来了解。下面是其中的一些processor的例子：
- add_cloud_metadata
- add_locale
- decode_json_fields
- add_fields
- drop_event
- drop_fields
- include_fields
- add_kubernetes_metadata
- add_docker_metadata启动Filebeat及Metricbeat
Filebeat 总览
Filebeat是用于转发和集中日志数据的轻量级传送程序。 作为服务器上的代理安装，Filebeat监视您指定的日志文件或位置，收集日志事件，并将它们转发到Elasticsearch或Logstash以进行索引
Filebeat具有如下的一些特性：
- 正确处理日志旋转：针对每隔一个时间段生产一个新的日志的案例，Filebeat可以帮我们正确地处理新生产的日志，并重新启动对新生成日志的处理
- 背压敏感：如果日志生成的速度过快，从而导致Filebeat生产的速度超过Elasticsearch处理的速度，那么Filebeat可以自动调节处理的速度，以达到Elasticsearch可以处理的范围内
- “至少一次”保证：每个日志生成的事件至少被处理一次
- 结构化日志：可以处理结构化的日志数据数据
- 多行事件：如果一个日志有多行信息，也可以被正确处理，比如错误信息往往是多行数据
- 条件过滤：可以有条件地过滤一些事件
Filebeat的工作方式如下：启动Filebeat时，它将启动一个或多个输入，这些输入将在为日志数据指定的位置中查找。 对于Filebeat所找到的每个日志，Filebeat都会启动收集器。 每个收割机都读取一个日志以获取新内容，并将新日志数据发送到libbeat，libbeat会汇总事件，并将汇总的数据发送到为Filebeat配置的输出。
从上面有可以看出来在spooler里有一些缓存，这个可以用于重新发送以确保至少一次的事件消费，同时也可以用于背压敏感。一旦Filebeat生成的事件的速度超过Elasticsearch能够处理的极限，这个缓存可以用于存储一些事件。
Metricbeat 总览
Metricbeat是一种轻量级的托运人，您可以将其安装在服务器上，以定期从操作系统和服务器上运行的服务收集指标。 Metricbeat会收集它收集的度量标准和统计信息，并将其运送到您指定的输出，例如Elasticsearch或Logstash。
Metricbeat通过从服务器上运行的系统和服务收集指标来帮助您监视服务器，例如：
Metricbeat具有一些特性：
- 轮询服务的API以收集指标
- 有效地将指标存储在Elasticsearch中
- 通过JMX / Jolokia，Prometheus，Dropwizard，Graphite的应用程序指标
- 自动贴标：表明是从AWS, Docker， Kubernetes, GoogleCloud 或Azure采集的
Metricbeat由模块和指标集组成。 Metricbeat模块定义了从特定服务（例如Redis，MySQL等）收集数据的基本逻辑。 该模块指定有关服务的详细信息，包括如何连接，收集度量的频率以及收集哪些度量。
每个模块都有一个或多个指标集。 度量集是模块的一部分，用于获取和构建数据。 度量标准集不是将每个度量标准收集为单独的事件，而是在对远程系统的单个请求中检索多个相关度量标准的列表。 因此，例如，Redis模块提供了一个信息量度集，该信息量度集通过运行INFO命令并解析返回的结果来从Redis收集信息和统计信息。
同样，MySQL模块提供了一个状态指标集，该指标集通过运行SHOW GLOBAL STATUS SQL查询从MySQL收集数据。 通过在远程服务器返回的单个请求中将相关度量标准集组合在一起，度量标准集使您更轻松。 如果没有用户启用的度量标准集，则大多数模块都具有默认度量标准集。
Metricbeat通过根据您在配置模块时指定的周期值定期询问主机系统来检索指标。 由于多个度量标准集可以将请求发送到同一服务，因此Metricbeat尽可能重用连接。 如果Metricbeat在超时配置设置指定的时间内无法连接到主机系统，它将返回错误。 Metricbeat异步发送事件，这意味着未确认事件检索。 如果配置的输出不可用，则事件可能会丢失。
什么是Filebeat和Merticbeat模块
一个Filebeat模块通常由如下的部分组成：
Filebeat模块简化了常见日志格式的收集，解析和可视化。
- 一个典型的模块（例如，对于Nginx日志）由一个或多个文件集（对于Nginx，访问和错误）组成。 文件集包含以下内容：
- Filebeat输入配置，其中包含在其中查找日志文件的默认路径。 这些默认路径取决于操作系统。 Filebeat配置还负责在需要时将多行事件缝合在一起。
- Elasticsearch Ingest Node管道定义，用于解析日志行。
- 字段定义，用于为每个字段配置具有正确类型的Elasticsearch。 它们还包含每个字段的简短说明。
- 示例Kibana仪表板（如果有）可用于可视化日志文件。
Filebeat会根据您的环境自动调整这些配置，并将它们加载到相应的Elastic stack组件中。
针对其它的Beats模块来说，基本和Filebeat一样。目前针对Elasticsearch所提供的模块来说，有非常多的模块可以供使用：
关于这里的有些模块的使用，可以参阅我的Beats文章。
好的，我今天关于Beats的介绍就先到这来，接下来在我的下一篇文章“Beats：Beats 入门教程 （二）”中，我将重点介绍如何通过实践操作来完成我们的Beats的数据采集! 静候我的下一篇文章。
