文章目录

• 一、Elastic Stack简介
• 二、elasticsearch
• 三、logstash
• 四、Beats
• 五、kibana
• 六、ELK工作流程
• 七、常见架构
• • （一）简单的ELK应用架构
  • （二）典型ELK架构
  • （三）ELK集群架构

一、Elastic Stack简介

“ELK”是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。

在 ELK Stack 这个生态圈慢慢发展过程中，加入了一个新成员 Beats（Beats是负责单一用途数据采集并推送给Logstash或Elasticsearch的轻量级产品），就更名为 Elastic Stack

Elastic Stack 是 ELK Stack 的更新换代产品。

所以，Elastic Stack技术栈的功能为，将系统、 络、应用系统日志等各种日志及相关数据进行收集、过滤、转换、然后进行集中存放并可用于实时检索、分析和展示。

二、elasticsearch

ElasticSearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。

Elasticsearch 是用 Java 开发的，并作为 Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

elasticsearch是一个采用Restful API标准的高扩展的和高可用的实时数据分析的全文搜索工具

相关概念

1. file：从文件系统上的文件读取，与UNIX命令非常相似 tail -0F
2. syslog：在已知端口上侦听syslog消息进行解析
3. redis：使用redis通道和redis列表从redis服务器读取。Redis通常用作集中式Logstash安装中的“代理”，该安装将Logstash事件从远程Logstash“托运人”排队。
4. Beats：处理 Beats发送的事件,beats包括filebeat、packetbeat、winlogbeat。

• 实时解析和转换数据
  

  尽管 Elasticsearch 是我们的首选输出方向，能够为我们的搜索和分析带来无限可能，但它并非唯一选择。Logstash 提供众多输出选择，可以将数据发送到您要指定的地方，并且能够灵活地解锁众多下游用例。

  常见的输出方向：

  1. elasticsearch：将事件数据发送给Elasticsearch。如果您计划以高效，方便且易于查询的格式保存数据… Elasticsearch是您的最佳选择
  2. file：将事件数据写入磁盘上的文件。
  3. graphite：将事件数据发送到graphite，这是一种用于存储和绘制指标的流行开源工具。
  4. statsd：将事件数据发送到statsd，这是一种“侦听统计信息，如计数器和定时器，通过UDP发送并将聚合发送到一个或多个可插入后端服务”的服务。

  Logstash工作过程

Logstash优点

• 可伸缩性
  节拍应该在一组Logstash节点之间进行负载平衡。建议至少使用两个Logstash节点以实现高可用性。每个Logstash节点只部署一个Beats输入是很常见的，但每个Logstash节点也可以部署多个Beats输入，以便为不同的数据源公开独立的端点。
• 弹性
  Logstash持久队列提供跨节点故障的保护。对于Logstash中的磁盘级弹性，确保磁盘冗余非常重要。对于内部部署，建议您配置RAID。在云或容器化环境中运行时，建议您使用具有反映数据SLA的复制策略的永久磁盘。
• 可过滤
  对事件字段执行常规转换。您可以重命名，删除，替换和修改事件中的字段。
  可扩展插件生态系统，提供超过200个插件，以及创建和贡献自己的灵活性。

Logstash缺点

Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。

四、Beats

Beats 是数据采集的得力工具。将 Beats 和您的容器一起置于服务器上，或者将 Beats 作为功能加以部署，然后便可在 Elasticsearch 中集中处理数据。Beats 能够采集符合 Elastic Common Schema (ECS) 要求的数据，如果希望拥有更加强大的处理能力，Beats 能够将数据转发至 Logstash 进行转换和解析后，Logstash再将处理后的数据发送给 Elasticsearch。

Beats是Elastic Stack技术栈中轻量级的数据采集产品，主要负责数据的转发和采集。 Beats家族包括以下几个成员:

• Filebeat： filebeat是构建于beats之上的，应用于日志收集场景的实现，用来替代 Logstash Forwarder 的下一代 Logstash 收集器，是为了更快速稳定轻量低耗地进行收集工作，它可以很方便地与 Logstash 还有直接与 Elasticsearch 进行对接。
  

• Winlogbeat：Winlogbeat 是一个轻量级的 Windows 事件日志收集工具。将 Windows 事件发送到 Elasticsearc h或者Logstash

• Heartbeat：Heartbeat 是一个心跳检测工具，主要监控服务的可用性。

  （1）不管你是测试同主机服务还是其他 络服务，Heartbeat都可以很轻松的生成正常运行时间和响应时间数据。而且修改配置不需要重启Heartbeat

  （2）Heartbeat通过ICMP,TCP,和HTTP进行ping，也支持TLS，身份验证（authentication ），和代理(proxies)。由于简单的DNS解析，你可以监控所有负载均衡的服务(原文:You can monitor all the hosts behind a load-balanced server thanks to simple DNS resolution)

• Auditbeat：轻量型审计日志采集器。收集主机审计框架的数据，监控文件完整性。Auditbeat 实时采集这些事件，然后发送到 Elastic Stack 其他部分做进一步分析。

• Functionbeat：面向云端数据的无服务器采集器。在作为一项功能部署在云服务提供商的功能即服务 (FaaS) 平台上后，Functionbeat 即能收集、传送并监测来自云服务的相关数据。

logstash 和 beats的关系

beats并不是用来替代logstash的。beats只是用来优化logstash的，因为logstash是jvm跑的，资源消耗比较大，消耗的性能比较多。如果只是单纯的为了收集日志，使用logstash就有点大材小用了，另外有点浪费资源。而beats是轻量级的用来收集日志的。

而logstash更加专注一件事，那就是数据转换，格式化，过滤、分析等处理工作。比方说，日志数据是一行一行的非格式化的数据，想要存在elasticsearch就要有一定的结构。logstash就可以做这件事。

常用的日志采集方案中，大部分的做法就是通过filebeat将所有节点的日志进行采集，然后发送到消息队列redis或kafaka中，然后logstash去获取，利用filter功能过滤分析，然后存储到elasticsearch中，最后在 kibana 上呈现。

如图：

七、常见架构

（一）简单的ELK应用架构

此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等），接着，Logstash server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。

这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。

此架构的优点在于引入了消息队列机制，均衡了 络传输，从而降低了 络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。

（三）ELK集群架构