ELK 日志分析系统

前言

• 日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志应用程序日志和安全日志,
• 当你管理上百台服务器时，再使用传统的方法查询日志，既费时又费力，为了处理这些问题，我们可以使用ELK（日志分析系统）
• ELK平台是一套完整的日志集中处理解决方案，将 ElasticSearch、Logstash 和 Kiabana 三个开源工具配合使用， 完成更强大的用户对日志的查询、排序、统计需求

一、ELK 日志分析系统简介

1.日志服务器

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

2.ELK 日志分析系统

由 ElasticSearch、Logstash 和 Kiabana 三个开源工具组成

2.1Elasticsearch（ES 数据库）：

• 是基于Lucene（一个全文检索引擎的架构）开发的分布式存储检索引擎，用来存储各类日志
• 最重要的两个功能在于索引与存储

2.2Logstash：

• 收集日志
• 转存至 ES

2.3Kibana：

• 是一个展示界面
• 数据源来自 ES

3.日志处理步骤

1. 在所有需要收集日志的服务器上部署Logstash；或者先将日志进行集中化管理在日志服务器上，在日志服务器上部署 Logstash
2. Logstash 收集日志，将日志格式化并输出到 Elasticsearch 群集中
3. Elasticsearch 对格式化后的数据进行索引和存储
4. Kibana 从 ES 群集中查询数据生成图表，并进行前端数据的展示

4.将日志进行集中化管理(beats )

beats是–组轻量级采集程序的统称，这些采集程序包括并不限于:

• filebeat: 进行文件和目录采集，主要用于收集日志数据。 (elk -》elfk)
• metricbeat:进行指标采集，指标可以是系统的，也可以是众多中间件产品的，主要用于监控系统和软件的性能。
• packetbeat:通过网络抓包、协议分析，对–些请求响应式的系统通信进行监控和数据收集，可以收集到很多常规方式无法收集到的信息。
• winlogbeat: 专门针对windows的event log进行的数据采集
• Heartbeat: 系统间连通性检测，比如icmp, tcp, http等系统的连通性监控。

二、Elasticsearch 介绍

1.概述

• 提供了一个分布式多用户能力的全文搜索（索引）引擎，开源，使用 Java 开发
• 分布式即数据不会放在一个地方

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 版，多用于业务体量非常大，及对日志收集、格式转换并且处理的一个复杂程度非常大的架构