ELK原理以及一些处理难点分析
1.ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件，但并非全部。后文的四种基本架构中将逐一介绍应用到的其它套件。
- Elasticsearch是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放REST和JAVA API等结构提供高效搜索功能，可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
- Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和Elasticsearch。
- Kibana是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，
- 还允许他们以特殊的方式查询和过滤数据。
2.这是最简单的一种ELK架构方式。优点是搭建简单，易于上手。缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议供学习者和小规模集群使用。
此架构首先由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户亦可以更直观的通过配置Kibana Web Portal方便的对日志查询，并根据数据生成报表
3.难点以及处理方法
1、ElasticSearch 分布式集群，在企业真实环境中防火墙需要关闭吗？
在实际工作中，ElasticSearch集群只开放对应的端口，不会直接关闭防火墙。
2、将公司的核心流量数据导入ELK平台的过程中，使用Logstash采集数据，那么Logstash能承受多大的数据压力呢？
一个logstash节点，每秒钟能收集个一两万条日志数据(普通的页面浏览日志)，如果单条日志比较大，或者在logstash中filter逻辑复杂，处理能力会再小一点。另外需要补充说明：一条普通日志大概6~8K的大小，转换成流量的话大致是105000KB/S。
3、在ELK的项目中，公司的日志如何动态产生？动态日志又改如何采集？
如果日志只输出到一个文件，比如access.log，那么Logstash直需要监控这个日志文件即可。
如果日志名称按照时间或者大小滚动，那么在Logstash配置文件名的时候使用通配符即可。
4、比如我每天的日志有1g或者10g或者100g，ELK系统架构中，应该需要多少台es，需要多少redis 需要多少logstash等。
可以根据数据量的大小以及每个组件数据处理能力合理规划。
filebeat：每秒钟收集能力大致在3W条左右
redis：每秒钟读取或者写入数据能力在10W条左右
logstash：每秒钟处理能力在1~2w左右
ELasticSearch：处理能力可以很容易水平扩展，单台服务器测试的指标大致在1.5W左右 配置：2核CPU、 16G内存
上述指标是指普通的access访问日志，每条日志大小大致在6~8KB如果单条日志过大或者过小，则指标会有上下浮动。
5、现在我的es集群每次full gc之后, 年老代占用的内存都会上升, 然后full gc会越来越频繁. 基本5天之后集群就得重启了，有没办法不重启强制清理年老代内存。
可以通过参数进行配置，参数配置：
index.cache.field.max_size: 100000
index.cache.field.expire: 60m
index.cache.field.type: soft
如果发现这个效果不明显，可以尝试修改一下JVM内存中年轻代和老年代的占比，把年轻代的内存调大一点，这样可以减少年轻代GC的次数，就不会有很多数据进入到老年代中。
6.logstash正在给es发送数据，无任何外部操作情况下，突然es没了~！：
(。于是翻看我的过往操作，没有发现可以导致类似结果的命令，es的日志在当时的时间点下并没有报告任何信息。后来想到了syslog的功能，于是查看syslog的日志，在/var/log/messages（确认一下路径）中按时间查找到es故障那会儿，找到了报错故障。简单说就是内存严重不足，linux系统先后杀死了我的两个服务：mysqld和es。这两个可都是后台处理数据的呀，如此重要确也能被如此只能的OOM Killer机制选中并杀掉！
