为什么需要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*
原创不易,如果文章帮到了你,欢迎转发和点赞,让更多的朋友受益!
标签:ELK,kibana,查询,Kibana,日志,数据 From: https://blog.51cto.com/liwen629/7621660