【ELK】01、ELK基础
一、ELK日志分析平台是什么？
首先来看一下传统的日志查找方式：当有客户报障时，需要：
1、登录服务器
ssh ops@10.1.1.1
ssh ops@10.1.1.2
ssh ops@10.1.1.3
…
2、找到位置
cd /apps/logs/nginx/; cd /apps/logs/mysql/;
cd /apps/logs/docker; cd /apps/logs/java/;
…… ……
3、查看日志
head tail grep wc awk count cut …… ……
因此，传统的日志架构存在的以下若干缺点：
[*]开发人员无权登录，经过运维周转费时费力
[*]日志数据分散在多个系统，难以查找
[*]日志数据量大，查询速度慢
[*]一个调用会涉及多个系统，难以在这些系统的日志中快速定位数据
[*]数据不够实时
[*]……
二、ELK概述
1、日志架构的演变
传统的日志架构，需要运维人员强大的正则功底，对日志运用shell命令，
例如：cat tail grep awk sed等，对日志进行处理，再筛选出自己想要的结果或寻找关键字。
有了ELK后，对运维和开发处理日志的要求降低，只需要在web界面上简单的操作，就可以找到自己想要的数据，并进行画图
2、那么ELK名称怎么由来呢？
ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件，但并非全部，而且还可以添加Redis，kafka，filebeat等软件，后文的四种基本架构中将逐一介绍应用到的其它套件。
Elasticsearch：
是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放REST和JAVA API等结构提供高效搜索功能，可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
Logstash：
是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和Elasticsearch。
Kibana：
是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
三、ELK的架构
我们先谈谈第一种ELK架构，如图1，这是最简单的一种ELK架构方式。
优点是搭建简单，易于上手。
缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议供学习者和小规模集群使用。
此架构首先由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户亦可以更直观的通过配置Kibana Web Portal方便的对日志查询，并根据数据生成报表（详细过程和配置在此省略）。
http://img.blog.csdn.net/20160205205319501
图1 ELK架构一
第二种架构（图2）引入了消息队列机制，
位于各个节点上的Logstash Agent先将数据/日志传递给Kafka（或者Redis），并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka（或者Redis）,所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。
http://img.blog.csdn.net/20160205205412035
图2 ELK架构二
这种架构适合于较大集群的解决方案，但由于Logstash中心节点和Elasticsearch的负荷会比较重，可将他们配置为集群模式，以分担负荷，这种架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题。
第三种架构（图3）引入了Logstash-forwarder。
首先，Logstash-forwarder将日志数据搜集并统一发送给主节点上的Logstash，Logstash分析、过滤日志数据后发送至Elasticsearch存储，并由Kibana最终将数据呈现给用户。
http://img.blog.csdn.net/20160205205519785
图3 ELK架构三
这种架构解决了Logstash在各计算机点上占用系统资源较高的问题。经测试得出，相比Logstash，Logstash-forwarder所占用系统CPU和MEM几乎可以忽略不计。另外，Logstash-forwarder和Logstash间的通信是通过SSL加密传输，起到了安全保障。如果是较大集群，用户亦可以如结构三那样配置logstash集群和Elasticsearch集群，引入High Available机制，提高数据传输和存储安全。更主要的配置多个Elasticsearch服务，有助于搜索和数据存储效率。但在此种架构下发现Logstash-forwarder和Logstash间通信必须由SSL加密传输，这样便有了一定的限制性。
第四种架构（图4），将Logstash-forwarder替换为Beats。
经测试，Beats platform 满负荷状态所耗系统资源和Logstash-forwarder相当，但其扩展性和灵活性有很大提高。Beats platform目前包含有Packagebeat、Topbeat和Filebeat三个产品，均为Apache 2.0 License。同时用户可根据需要进行二次开发。
http://img.blog.csdn.net/20160205205555801
图4 ELK架构四
这种架构原理基于第三种架构，但是更灵活，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。
不管采用上面哪种ELK架构，都包含了其核心组件，即：Logstash、Elasticsearch 和Kibana。当然这三个组件并非不能被替换，只是就性能和功能性而言，这三个组件已经配合的很完美，是密不可分的。各系统运维中究竟该采用哪种架构，可根据现实情况和架构优劣而定。
ELK在大数据运维系统中的应用
在海量日志系统的运维中，以下几个方面是必不可少的：
[*]分布式日志数据集中式查询和管理
[*]系统监控，包含系统硬件和应用各个组件的监控
[*]故障排查
[*]安全信息和事件管理
[*]报表功能
ELK组件各个功能模块如图5所示，它运行于分布式系统之上，通过搜集、过滤、传输、储存，对海量系统和组件日志进行集中管理和准实时搜索、分析，使用搜索、监控、事件消息和报表等简单易用的功能，帮助运维人员进行线上业务的准实时监控、业务异常时及时定位原因、排除故障、程序研发时跟踪分析Bug、业务趋势分析、安全与合规审计，深度挖掘日志的大数据价值。同时Elasticsearch提供多种API（REST JAVA PYTHON等API）供用户扩展开发，以满足其不同需求。
http://img.blog.csdn.net/20160205205702084
图5 ELK在运维系统组件中应用图示
汇总ELK组件在大数据运维系统中，主要可解决的问题如下：
[*]日志查询，问题排查，上线检查
[*]服务器监控，应用监控，错误报警，Bug管理
[*]性能分析，用户行为分析，安全漏洞分析，时间管理
综上，ELK组件在大数据运维中的应用是一套必不可少的且方便、易用的开源解决方案。
下面我们就开始详细学习ELK的各个组件
页:
[1]