为什么需要ELK

一般我们在工作中查询日志搜索问题时，通常需要直接在日志文件中进行grep、awk 操作就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。随着微服务的广泛应用，无论系统日志，还是业务日志都更进一步了。运维或者开发们发现要从这么大规模的系统中(几百个上千个服务)产生的千亿规模日志去排查问题，简直是难于上青天啊。而ELK的出现解决了这个痛点，他是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。ELK elasticsearch, logstash, kibana三个开源工具的简称，一般用于搭建日志分析系统。

elasticsearch是核心，是一个分布式搜索引擎，查询速度快，提供数据的存储和检索。

logstash负责数据的收集和处理，目前多使用一个更加轻量级的工具filebeat进行收集数据。

kibana用于可视化展示elasticsearch中的数据，并提供一些操作。

ELK基础架构如下：

这是最简单的一种ELK架构方式。优点是搭建简单，易于上手。缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。此架构由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户亦可以更直观的通过配置Kibana Web方便的对日志查询，并根据数据生成报表。

 ELK架构的改进如下：

此种架构将收集端logstash替换为beats，更灵活，消耗资源更少，扩展性更强。同时可配置Logstash 和Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

总结：大家可以简单的理解为，我们需要在应用上安装一个东东(可以是logstash或者filebeat)负责收集应用上的日志，然后elasticsearch负责对日志进行处理，最后用户通过kibana来对日志进行查询操作，对于我们使用者来讲，我们只需要关注kibana的使用即可，核心目的就是快速地在海量应用里找到我们所需的日志信息！关于ELK的环境搭建这里就不多说了，我在这里重点讲解以下，在微服务的测试过程中，如何利用ELK来帮助我们分析和定位问题。

Kibana的使用

我们用 Kibana 来搜索，查看存储在 Elasticsearch 索引中的数据并与之交互。通过Kibana可以很容易实现高级的数据分析和可视化，以图表的形式展现出来。对与测试人员来讲，我们用的最多的就是日志索搜功能。单击侧面导航中的 Discover 进入 Kibana 的数据探索功能：

 Kibana中的常用查询：

要搜索一个确切的字符串，需要使用双引号引起来。如果不带引号，将会匹配每个单词。

例子：message:"登录成功"

多条件查询用 AND OR连接 例如：192.168.1.181 AND 更新  "登录成功" OR "操作成功"

支持正则 例如 *error*，包含error的字段。

返回查询 允许一个字段值在某个区间。[] 包含该值，{}不包含。

举个栗子：

1.只知道应用名，要查询此应用的某异常信息，如何操作？

搜索框输入 weixin AND "异常信息"

2.想检查某应用中是否有SQL异常 weixin AND *SQLException* 

异常关键字：IOException、SQLException、JDBCException、sqlnestedException、socketException、ClassNotFoundException、 *UnknownHostException*

原创不易，如果文章帮到了你，欢迎转发和点赞，让更多的朋友受益！