ELK学习

---

Elasticsearch

---

Elastic Stack优点

1. 处理方式灵活。Elasticsearch 是实时全文索引；
2. 配置简易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 设计，都是目前业界最通用的配置语法设计；
3. 检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
4. 集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的；
5. 前端操作炫丽。Kibana 界面上，只需要点击鼠标，就可以完成搜索、聚合功能，生成炫丽的仪表板。

基本原理

  写入的数据是如何变成 Elasticsearch 里可以被检索和聚合的索引内容的？
  关键在于『倒排索引』，新收到的数据会被写入到内存的 buffer 中，然后在一定的时间间隔后刷到磁盘中，成为一个新的 segment（段），然后另外使用一个 commit 文件来记录所有的 segment，数据只有在成为 segment 之后才能被检索。默认的从 buffer 到 segment 的时间间隔是 1 秒，基本已经是『实时』了，如果需要更改，也可以调用 /_refresh 接口。不过很多时候我们不需要这么『实时』，所以可以加大这个时间间隔，以获得更快的写入性能。导入历史数据时甚至可以关闭，导入完成再重新开启。
  为了保证数据从 buffer 到 segment 的一致性，Elasticsearch 还会有一个名为 Translog 的记录，至于 Translog 的一致性则是通过定期保存到磁盘中来实现的。
   Lucene 会不断开新文件，这样磁盘上就会有一堆小文件，所以 ES 会在后台把这些零散的 segment 做数据归并，归并完成后就可以把小的 segment 删掉，也就减少了 segment 的数量了。为了不影响 IO 和 CPU，会对归并线程做一定的限制，我们可以根据硬件的不同来调整 indices.store.throttle.max_bytes_per_sec 来提高性能。与此同时，我们也有不同的归并策略，不过总体来说就是让我们加大 flush 的间隔，尽量让每次新生成的 segment 本身就比较大。

增删改查

   ES 虽然不是数据库，不过其特性决定了，ES就是一个很好的 NoSQL 数据库。因为 ELK stack 的缘故，写入由 Logstash 负责，查询由 Kibana 负责，不过修改和删除就有些无能为力了（毕竟为什么要简单修改和删除日志？），可是修改和删除是数据库必须的功能，好在 ES 提供了 RESTful 接口来处理 JSON 请求，最简单的用 curl 就可以完成各类操作。这里推荐一个 Chrome 的插件 Postman，可以很方便进行各类测试。具体如何发送请求请参考文档，这里不赘述了。
增删改查操作实例

搜索（重点）

   在 ES 环境中，更多的是搜索和聚合请求。在 5.0 之前版本中，数据获取和数据搜索甚至有极大的区别：刚写入的数据，可以通过 translog 立刻获取；但是却要等到 refresh 成为一个 segment 后，才能被搜索到。从 5.0 版本开始，Elasticsearch 稍作了改动，不再维护 doc-id 到 translog offset 的映射关系，一旦 GET 请求到这个还不能搜到的数据，就强制 refresh 出来 segment，这样就可以搜索了。这个改动降低了数据获取的性能，但是节省了不少内存，减少了 young GC 次数，对写入性能的提升是很有好处的。
ES搜索功能详细介绍
ES搜索语法分为：

• 全文搜索

  1. queryString 语法，kibana中使用，也是我们最常用的

  2. 完整语法

     ES 支持各种类型的检索请求，除了可以用 querystring 语法表达的以外，还有很多其他类型，具体列表和示例可参见：https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-queries.html。

• 聚合请求

  1. 堆叠聚合示例
  2. 管道聚合示例

queryString语法
这部分内容会在 Kibana 上经常使用，这里详细解析一下语法：

• 全文检索：直接写搜索的单词，如上例中的 first；
• 单字段的全文检索：在搜索单词之前加上字段名和冒号，比如如果知道单词 first 肯定出现在 mesg 字段，可以写作 mesg:first；
• 单字段的精确检索：在搜索单词前后加双引号，比如 user:“chenlin7”；
• 多个检索条件的组合：可以使用 NOT, AND 和 OR 来组合检索，注意必须是大写。比如 user:(“chenlin7” OR “chenlin”) AND NOT mesg:first；
• 字段是否存在：exists:user 表示要求 user 字段存在，missing:user 表示要求 user 字段不存在；
• 通配符：用 ? 表示单字母，* 表示任意个字母。比如 fir?t mess*；
• 正则：需要比通配符更复杂一点的表达式，可以使用正则。比如 mesg:/mes{2}ages?/。注意 ES 中正则性能很差，而且支持的功能也不是特别强大，尽量不要使用。ES 支持的正则语法
• 近似搜索：用 ~ 表示搜索单词可能有一两个字母写的不对，请 ES 按照相似度返回结果。比如 frist~；
• 范围搜索：对数值和时间，ES 都可以使用范围搜索，比如：rtt:>300，date:[“now-6h” TO “now”} 等。其中，[] 表示端点数值包含在范围内，{} 表示端点数值不包含在范围内；

主要概念

• 接近实时（NRT）
  elasticsearch是一个接近实时的搜索平台，这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。

• 集群（cluster）
  一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。其中一个节点为主节点，这个主节点是可以通过选举产生的，并提供跨节点的联合索引和搜索的功能。集群有一个唯一性标示的名字，默认是elasticsearch，集群名字很重要，每个节点是基于集群名字加入到其集群中的。因此，确保在不同环境中使用不同的集群名字。一个集群可以只有一个节点。强烈建议在配置elasticsearch时，配置成集群模式。

• 节点（node）
  节点就是一台单一的服务器，是集群的一部分，存储数据并参与集群的索引和搜索功能。像集群一样，节点也是通过名字来标识，默认是在节点启动时随机分配的字符名。当然，你可以自己定义。该名字也很重要，在集群中用于识别服务器对应的节点。
  节点可以通过指定集群名字来加入到集群中。默认情况，每个节点被设置成加入到elasticsearch集群。如果启动了多个节点，假设能自动发现对方，他们将会自动组建一个名为elasticsearch的集群。

• 索引（index）
  一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，如果你想，可以定义任意多的索引。
  索引相对于关系型数据库的库。

• 分片和副本（shards & replicas）
  在实际情况下，索引存储的数据可能超过单个节点的硬件限制。如一个10亿文档需1TB空间可能不适合存储在单个节点的磁盘上，或者从单个节点搜索请求太慢了。为了解决这个问题，elasticsearch提供将索引分成多个分片的功能。当在创建索引时，可以定义想要分片的数量。每一个分片就是一个全功能的独立的索引，可以位于集群中任何节点上。
  分片的两个最主要原因：

  1. 水平分割扩展，增大存储量
  2. 分布式并行跨分片操作，提高性能和吞吐量

  分布式分片的机制和搜索请求的文档如何汇总完全是由elasticsearch控制的，这些对用户而言是透明的。
  网络问题等等其它问题可以在任何时候不期而至，为了健壮性，强烈建议要有一个故障切换机制，无论何种故障以防止分片或者节点不可用。 为此，elasticsearch让我们将索引分片复制一份或多份，称之为分片副本或副本。
  副本也有两个最主要原因：

  1. 高可用性，以应对分片或者节点故障。出于这个原因，分片副本要在不同的节点上。
  2. ×××能，增大吞吐量，搜索可以并行在所有副本上执行。

  总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和副本的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变副本的数量，但是你事后不能改变分片的数量。

  默认情况下，Elasticsearch中的每个索引被分片5个主分片和1个副本，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个副本分片（1个完全拷贝），这样的话每个索引总共就有10个分片。

---

Logstash

---

   Logstash的独立性很强，它的用途就是一个内容的转存系统，通过灵活的插件可以做到很多种类数据的读取和很多种类数据的写入。
   Logstash事件处理管道有三个阶段：输入→过滤器（非必要）→输出，输入生成事件，过滤器修改它们，然后输出将它们发送到其他地方。输入和输出支持编解码器，使你能够在数据进入或离开管道时对其进行编码或解码，而无需使用单独的过滤器。

工作流程：

  Logstash的数据处理过程主要包括：Inputs, Filters, Outputs 三部分， 另外在Inputs和Outputs中可以使用Codecs对数据格式进行处理。这四个部分均以插件形式存在，用户通过定义pipeline配置文件，设置需要使用的input，filter，output, codec插件，以实现特定的数据采集，数据处理，数据输出等功能 。
（1）Inputs：用于从数据源获取数据，常见的插件如file, syslog, redis, beats 等
（2）Filters：用于处理数据如格式转换，数据派生等，常见的插件如grok, mutate, drop, clone, geoip等[详细参考]
（3）Outputs：用于数据输出，常见的插件如elastcisearch，file, graphite, statsd等
（4）Codecs：Codecs不是一个单独的流程，而是在输入和输出等插件中用于数据转换的模块，用于对数据进行编码处理，常见的插件如json，multiline。

支持的输入类型：

• 标准输入（Stdin）
• 读取文件（File）
• 读取网络数据（TCP）
• 生成测试数据（Generator）
• 读取Syslog数据
• 读取Redis数据
• 读取Collected数据

Filter 数据中转层，主要进行格式处理，数据类型转换、数据过滤、字段添加，修改等，常用的过滤器如下。

• grok: 通过正则解析和结构化任何文本。Grok 目前是logstash最好的方式对非结构化日志数据解析成结构化和可查询化。logstash内置了120个匹配模式，满足大部分需求。
• mutate: 在事件字段执行一般的转换。可以重命名、删除、替换和修改事件字段。
• drop: 完全丢弃事件，如debug事件。
• clone: 复制事件，可能添加或者删除字段。
• geoip: 添加有关IP地址地理位置信息。

支持的输出类型：

• 标准输出（stdout）
• 保存成文件（File）。 将事件数据写入到磁盘文件上。
• 保存成ES。发送事件数据到 Elasticsearch，便于查询，分析，绘图。
• 输出到Redis。将数据发送至redis-server，常用于中间层暂时缓存。
• 输出网络数据（TCP）
• 输出到Statsd。发送事件数据到 statsd。
• 报警到Nagios
• 发送邮件（Email）
• 调用命令执行（Exec）

Logstash执行模型

（1）每个Input启动一个线程，从对应数据源获取数据

（2）Input会将数据写入一个队列：默认为内存中的有界队列（意外停止会导致数据丢失）。为了防止数丢失Logstash提供了两个特性：
Persistent Queues：通过磁盘上的queue来防止数据丢失
Dead Letter Queues：保存无法处理的event（仅支持Elasticsearch作为输出源）

（3）Logstash会有多个pipeline worker, 每一个pipeline worker会从队列中取一批数据，然后执行filter和output（worker数目及每次处理的数据量均由配置确定）

Logstash部署架构

Logstash的理念很简单，它只做3件事情：

1. Collect：数据输入
2. Enrich：数据加工，如过滤，改写等
3. Transport：数据输出

通过组合输入和输出，可以变幻出多种架构实现多种需求。这里是以解决日志汇总需求的部署架构图：

   一个Logstash进程可以有多个输入源，所以一个Logstash进程可以同时读取一台服务器上的多个日志文件。Redis是Logstash官方推荐的Broker角色“人选”，支持订阅发布和队列两种数据传输模式，推荐使用。输入输出支持过滤，改写。Logstash支持多种输出源，可以配置多个输出实现数据的多份复制，也可以输出到Email，File，Tcp，或者作为其它程序的输入，又或者安装插件实现和其他系统的对接，比如搜索引擎Elasticsearch。

---

ELK常用架构及使用场景介绍

---

1、Logstash 作为日志搜集器

  Logstash 通过输入插件从多种数据源（比如日志文件、标准输入 Stdin 等）获取数据，再经过滤插件加工数据，然后经 Elasticsearch 输出插件输出到 Elasticsearch，通过 Kibana 展示。架构图如下：

  把一个 Logstash 数据搜集节点扩展到多个，分布于多台机器，将解析好的数据发送到 Elasticsearch server 进行存储，最后在 Kibana 查询、生成日志报表等。这种结构因为需要在各个服务器上部署 Logstash，而它比较消耗 CPU 和内存资源，所以比较适合计算资源丰富的服务器，否则容易造成服务器性能下降，甚至可能导致无法正常工作。架构图如下：

2、Beats 作为日志搜集器

目前 Beats 包括四种：

• Packetbeat（搜集网络流量数据）；
• Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）；
• Filebeat（搜集文件数据）；
• Winlogbeat（搜集 Windows 事件日志数据）。

  Beats 将搜集到的数据发送到 Logstash，经 Logstash 解析、过滤后，将其发送到 Elasticsearch 存储，并由 Kibana 呈现给用户。架构图如下：

  这种架构解决了 Logstash 在各服务器节点上占用系统资源高的问题。相比 Logstash，Beats 所占系统的 CPU 和内存几乎可以忽略不计。另外，Beats 和 Logstash 之间支持 SSL/TLS 加密传输，客户端和服务器双向认证，保证了通信安全。因此这种架构适合对数据安全性要求较高，同时各服务器性能比较敏感的场景。

基于 Filebeat 架构

  Filebeat 已经完全替代了 Logstash-Forwarder 成为新一代的日志采集器，同时鉴于它轻量、安全等特点，越来越多人开始使用它。基于 Filebeat 的 ELK 集群架构：

  因为免费的 ELK 没有任何安全机制，所以这里使用了 Nginx 作反向代理，避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证，一定程度上提高安全性。另外，Nginx 本身具有负载均衡的作用，能够提高系统访问性能。
  FileBeat，它是一个轻量级的日志收集处理工具(Agent)，Filebeat占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具。
Filebeat 架构的配置部署详解

Filebeat工作原理

  Filebeat由两个主要组件组成：prospectors 和 harvesters。这两个组件协同工作将文件变动发送到指定的输出中。

  Harvester（收割机）：负责读取单个文件内容。每个文件会启动一个Harvester，每个Harvester会逐行读取各个文件，并将文件内容发送到制定输出中。Harvester负责打开和关闭文件，意味在Harvester运行的时候，文件描述符处于打开状态，如果文件在收集中被重命名或者被删除，Filebeat会继续读取此文件。所以在Harvester关闭之前，磁盘不会被释放。默认情况filebeat会保持文件打开的状态，直到达到close_inactive（如果此选项开启，filebeat会在指定时间内将不再更新的文件句柄关闭，时间从harvester读取最后一行的时间开始计时。若文件句柄被关闭后，文件发生变化，则会启动一个新的harvester。关闭文件句柄的时间不取决于文件的修改时间，若此参数配置不当，则可能发生日志不实时的情况，由scan_frequency参数决定，默认10s。Harvester使用内部时间戳来记录文件最后被收集的时间。例如：设置5m，则在Harvester读取文件的最后一行之后，开始倒计时5分钟，若5分钟内文件无变化，则关闭文件句柄。默认5m）。
  Prospector（勘测者）：负责管理Harvester并找到所有读取源。Prospector会找到/var/logs/*目录下的所有.log文件，并为每个文件启动一个Harvester。Prospector会检查每个文件，看Harvester是否已经启动，是否需要启动，或者文件是否可以忽略。若Harvester关闭，只有在文件大小发生变化的时候Prospector才会执行检查。只能检测本地的文件。

• Filebeat如何记录文件状态?

  将文件状态记录在文件中（默认在/var/lib/filebeat/registry）。此状态可以记住Harvester收集文件的偏移量。若连接不上输出设备，如ES等，filebeat会记录发送前的最后一行，并再可以连接的时候继续发送。Filebeat在运行的时候，Prospector状态会被记录在内存中。Filebeat重启的时候，利用registry记录的状态来进行重建，用来还原到重启之前的状态。每个Prospector会为每个找到的文件记录一个状态，对于每个文件，Filebeat存储唯一标识符以检测文件是否先前被收集。

• Filebeat如何保证事件至少被输出一次?

  Filebeat之所以能保证事件至少被传递到配置的输出一次，没有数据丢失，是因为filebeat将每个事件的传递状态保存在文件中。在未得到输出方确认时，filebeat会尝试一直发送，直到得到回应。若filebeat在传输过程中被关闭，则不会再关闭之前确认所有时事件。任何在filebeat关闭之前为确认的时间，都会在filebeat重启之后重新发送。这可确保至少发送一次，但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间（默认禁用）。

3、引入消息队列机制的架构

  这种架构使用 Logstash 从各个数据源搜集数据，然后经消息队列输出插件输出到消息队列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常见消息队列。然后 Logstash 通过消息队列输入插件从队列中获取数据，分析过滤后经输出插件发送到 Elasticsearch，最后通过 Kibana 展示。架构图如下：

  这种架构适合于日志规模比较庞大的情况。但由于 Logstash 日志解析节点和 Elasticsearch 的负荷比较重，可将他们配置为集群模式，以分担负荷。引入消息队列，均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，但依然存在 Logstash 占用系统资源过多的问题。

注

• 文章是个人知识点整理总结，如有错误和不足之处欢迎指正。
• 如有疑问、或希望与笔者探讨技术问题（包括但不限于本章内容），欢迎添加笔者微信（o815441）。请备注“探讨技术问题”。欢迎交流、一起进步。

参考的文章：
ELK超完整教程
ELK+Filebeat 集中式日志解决方案详解
ELK原理和介绍
一文快速上手Logstash
ELK日志分析系统
Kibana用户手册