为什么需要ELK
一般我们在工作中查询日志搜索问题时，通常需要直接在日志文件中进行grep、awk操作就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。随着微服务的广泛应用，无论系统日志，还是业务日志都更进一步了。运维或者开发们发现要从这么大规模的系统中(几百个上千个服务)产生的千亿规模日志去排查问题，简直是难于上青天啊。而ELK的出现解决了这个痛点，他是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。ELKelasticsearch,logstash,kibana三个开源工具的简称，一般用于搭建日志分析系统。
elasticsearch是核心，是一个分布式搜索引擎，查询速度快，提供数据的存储和检索。
logstash负责数据的收集和处理，目前多使用一个更加轻量级的工具filebeat进行收集数据。
kibana用于可视化展示elasticsearch中的数据，并提供一些操作。
ELK基础架构如下：
这是最简单的一种ELK架构方式。优点是搭建简单，易于上手。缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。此架构由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户亦可以更直观的通过配置KibanaWeb方便的对日志查询，并根据数据生成报表。
ELK架构的改进如下：
此种架构将收集端logstash替换为beats，更灵活，消耗资源更少，扩展性更强。同时可配置Logstash和Elasticsearch集群用于支持大集群系统的运维日志数据监控和查询。
总结：大家可以简单的理解为，我们需要在应用上安装一个东东(可以是logstash或者filebeat)负责收集应用上的日志，然后elasticsearch负责对日志进行处理，最后用户通过kibana来对日志进行查询操作，对于我们使用者来讲，我们只需要