ELK 日志分析系统（Elasticsearch + Logstash + Kibana 的理论详解）（附 EFK 架构的介绍）

---

前言

• 日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志应用程序日志和安全日志
• 系统运维和开发人员可以通过日志了解服务器软硬件信息检查配过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误
• 通常，日志被分散的储存在不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志，既繁琐又效率低下。为此，我们可以使用集中化的日志管理，例如：开源的 syslog，将所有服务器上的日志收集汇总
• 集中化管理日志后，日志的统计和检承又成为一件比较麻烦的事情，一般我们使用 grep、awk 和 wc 等 Linux 命令能实现检索和统计，但是对于更高要求的查询、排序和统计等，再加上庞大的机器数量，使用这样的方法依然难免有点力不从心
• 开源实时日志分析 ELK 平台能够完美的解决我们上述的问题，ELK 由 ElasticSearch、Logstash 和 Kiabana 这三个开源工具组成

---

一、ELK 日志分析系统简介

1.日志服务器

• 提高安全性：仅是基于日志来恢复和定位故障，是很困难的
• 集中存放日志，即集中化管理
• 缺陷：对日志的分析困难，因为集中化管理，所以信息量更加巨大

2.ELK 日志分析系统

• Elasticsearch（ES 数据库）：
  • 最重要的两个功能在于索引与存储
  • 百度、Github 的引擎是使用的 ES 索引数据库（主流）
• Logstash：
  • 收集日志
  • 转存至 ES
• Kibana：
  • 是一个展示界面
  • 数据源来自 ES

3.日志处理步骤

1. AppServer 是一个类似于 Nginx、Apache 的集群，其日志信息由 Logstash 来收集

2. 往往为了减少网络问题所带来的瓶颈，会把 Logstash 服务放入前者的集群内，减少网络的消耗

3. Logstash 把收集到的日志数据格式化后输出转存至 ES 数据库内（这是一个将日志进行集中化管理的过程）

4. 随后，Kibana 对 ES 数据库内格式化后日志数据信息进行索引和存储

5. 最后，Kibana 把其展示给客户端

即对前文中 ELK 三个组件的介绍

一点补充→日志的集中化管理（beats）

beats 包括四种工具：

1. Packetbeat（搜索网络流量数据）
2. Topbeat（搜索系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
3. Filebeat（搜集文件数据）
4. Winlogbeat（搜集 Windows 时间日志数据）

---

二、Elasticsearch 介绍

1.概述

• 提供了一个分布式多用户能力的全文搜索（索引）引擎，开源，使用 Java 开发
• 分布式即数据不会放在一个地方
• 正是 ES 这些优秀的机制，所以会被百度等龙头企业所选择

2.核心概念

2.1 接近实时（NRT）

• 指索引和数据处理的能力
• 即从索引一个文档直到这个文档能够被搜索到仅有一个轻微的延迟（一般是1秒）

2.2 集群（Cluster）

• 一个内部组件 ES 的架构（特性：ES 具有集群机制，节点通过集群名称加入到集群时，同时在集群中的节点会有一个自己的唯一身份标识）
• 一个集群就是由一个或多个节点组织在一起，它们共同持有你的整个的数据，并一起提供索引和搜索功能
• 其中一个节点为主节点，其可通过选举产生，并提供跨节点的联合索引和搜索的功能
• 集群有一个唯一性的标示的名字，默认为 Elasticsearch，集群的名字很重要！每个节点都是基于集群的名字加入到集群中的。因此，确保在不同环境中使用不同的集群名字

2.3 节点（node）

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

2.4 索引（index）

• 索引（库）→索引类型（表）→索引的具体文档（记录）
• 索引根据以上这个方式来进行数据（位置）定位
• 一个索引就是一个拥有几分相似特征的文档的集合
• 一个索引由一个名字来标识（必须是全小写），每当我们需要对这个索引中的文档进行索引、搜索、更新和删除的时候，都需要使用到这个名字
• 相当于关系数据库中的库

2.5 类型（type）

• 在一个索引中，你可以定义一种或多种类型
• 一个类型是你的索引的一个逻辑上的分类/分区，其语义由你自定义
• 类比与关系数据库中的表

2.6 文档（document）

• 一个文档是一个可被索引的基础信息单元
• 类比于关系数据中的列

2.7 分片（Shard）

• 在实际情况下，索引存储的数据可能超过单个节点的硬件限制，如一个巨大的文档需要1TB的空间，可能并不需要存储在单个节点的磁盘上，或者这样子从单个节点上搜索请求速度会非常慢。为了解决这个问题，Elasticsearch 提供将索引分层多个分片的功能
• 如，一个40G的文件，分为两份20G的文件，存放至两个节点上，这样读取这个40G的文件时，会效率更快
• 当在创建索引时，可以定义想要分片的数量，每一个分片就是一个全功能的独立的索引，可以位于集群中任何节点上
• 分片的两个最主要特点就是：
  • 水平分割扩展，增大存储量
  • 能够分布式并行跨分片操作，提供性能和吞吐量
• 分布式分片的机制和搜索请求的文档如何汇总是有 ES 进行控制的，且对用户完全透明

2.8 副本（Replicas）

• 网络问题等很多方面的风险可能会接踵而来，为了健壮性，强烈建议要有一个故障切换机制，无论何种遇到何种故障，都能防止分片或节点不可用（单点故障）

• 为此，ES 让我们将索引分片复制一份或多份，称之为分片副本或副本

• 核心是为了容灾，不过也可以处理任务

• 分片加上副本的使用：例如，四台主机同时处理一项任务，理论上效率可以提高四倍！

• 副本也有两个最重要的特点：

  • 高可用性，以应对分片或节点故障，故此，分片副本要在不同的节点上
  • 高性能，增加吞吐量，搜索可以在所有的副本上执行

2.9 小结

• 总之，每个索引可以被分成多个分片，且一个索引也可以被复制0次（即没有复制）或多次
• 一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别
• 分片和副本的数量可以在索引创建的时候指定，在索引创建之后，你可以在任何时候动态地改变副本的数量，但是你事后不能改变分片的数量
• 默认情况下，ES 中的每个索引被分片5个主分片和1个副本，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个副本分片（1个完全拷贝），这样的话每个索引总共就有10个分片

---

三、Logstash 介绍

• 一款强大的数据处理工具，完全开源，基于消息（message-based）的简单架构，并运行在 java 虚拟机（JVM）上
• 它只做三件事：
  • 实现数据传输（input）
  • 格式处理（filter）
  • 格式化输出（output）
• 数据输入、数据加工（如过滤，改写等）以及数据输出
• 即收集日志和输出日志，供以后使用（如搜索）

---

四、Kibana 介绍

1.概述

• 一个针对 Elasticsearch 的分析及提供友好、可视化的 Web 平台，开源免费！
• 用于搜索、查看存储在 Elasticsearch 索引中的数据
• 可以通过各种图表进行高级数据分析及展示，让海量数据更容易被理解
• 它操作简单，基于浏览器的用户界面，可以快速创建仪表板（Dashboard）实时显示 ES 查询动态
• 设置非常简单

2.主要功能

• 与 Elasticsearch 无缝之集成：ELK 初始是由 ES 收购了另外两家个技术（Logstash+Kibana），把其糅合在一起进行开发整合，形成了一个完整的技术
• 整合数据，复杂数据分析：能够很好的处理海量数据，节省我们分析日志数据的时间，降低其复杂度
• 让更多团队成员受益：有了这么一个公共的展示界面，只要有权限就都能进去查看，强大的数据可视化接口让各岗各业都能够从数据集合中收益
• 接口灵活，分享更容易： API 可以很方便的被调用，并将可视化数据快速交流，方便查看
• 配置简单，可视化多数据源：配合和启动非常简单，用户体验良好，可以对不止一种数据或日志类型进行展示，并且是精细化展示
• 简单数据导出：可以很方便的导出感兴趣的数据，与其他数据集合并融合后快速建模分析，从而发现新结果

---

五、拓展：EFK

• ELK 的构成：

  • Elasticsearch（数据库）
  • Logstash（数据处理工具）
  • Kibana（展示界面，数据来源于 ES）

• EFK 的构成（功能性分离 + 抗高并发）：

  • Elasticsearch
  • Logstash（↓仅做数据格式处理的工作，并发量太大时仅靠 Logstash 很难承受，而且它很吃资源）
  • Filebeat （↑搜集文件数据，轻量级的日志收集工具，性能比上者强）
  • Kafka（服务之间传递数据的消息代理，承载数据的交互及传输，抗高并发能力相对而言较强，每秒能处理几十万的并发量）
  • Kibana
  • Redis（缓存，减压）

EFK 是 ELK 的 plus 版，多用于业务体量非常大，及对日志收集、格式转换并且处理的一个复杂程度非常大的架构