ELK、EFK 简介
想必你对 ELK、EFK 都不陌生，它们有一个共同的组件：Elasticsearch（简称ES），它是一个实时的全文搜索和分析引擎，可以提供日志数据的收集、分析、存储 3 大功能。另外一个组件 Kibana 是这套检索系统中的 Web 图形化界面系统，可视化展示在 Elasticsearch 的日志数据和结果。
ELF/EFK 工具集中还有 l 和 F 这两个名称的缩写，这两个缩写代表的工具根据不同的架构和使用方式而定。
L 通常是 Logstash 组件，它是一个用来搜集、分析、过滤日志的工具 。
F 代表 Beats 工具（它是一个轻量级的日志采集器），Beats 家族有 6 个成员，Filebeat 工具，它是一个用于在客户端收集日志的轻量级管理工具。
F 也可以代表工具 fluentd，它是这套架构里面常用的日志收集、处理转发的工具。
那么它们（Logstash VS Beats VS fluentd）有什么样的区别呢？Beats 里面是一个工具集，其中包含了 Filebeat 这样一个针对性的日志收集工具。Logstash 除了做日志的收集以外，还可以提供分析和过滤功能，所以它的功能会更加的强大。
Beats 和 fluentd 有一个共同的特点，就是轻量级，没有 Logstash 功能全面。但如果比较注重日志收集性能，Beats 里面的 Filebeat 和 fluentd 这两个工具会更有优势。
Kafka 是 ELK 和 EFK 里面一个附加的关键组件（缩写 K），它主要是在支持高并发的日志收集系统里面提供分布式的消息队列服务。
ELK 的优势
在此之前，先介绍 ELK 日志分析会有一些什么样的优势？主要有 3 点：
1、它是一套开源、完整的日志检索分析系统，包含收集、存储、分析、检索工具。我们不需要去开发一些额外的组件去完成这套功能，因为它默认的开源方式就提供了一整套组件，只要组合起来，就可以完成从日志收集、检索、存储、到整个展示的完整解决方案了。
2、支持可视化的数据浏览。运维人员只要在控制台里选择想关注的某一段时间内的数据，就可以查看相应的报表，非常快捷和方便。
3、它能广泛的支持一些架构平台，比如我们现在讲到的 K8s 或者是云原生的微服务架构。
Kafka 作为日志消息队列，客户端通过 Filebeat 收集数据（日志）后将其先存入 Kafka，然后由 Logstash 提取并消费，这套架构的好处是：当我们有海量日志同步情况下，直接存入服务端 ES 很难直接应承接海量流量，所以 Kafka 会进行临时性的存取和缓冲，再由 Logstash 进行提取、过滤，通过 Logstash 以后，再把满足条件的日志数据存入 ES。
ES 不再是以单实例的方部署，而是采用集群架构，考虑 Kafka 的集群模式， Logstash 也使用集群模式。
我们会看到这套架构稍微庞大，大中型的企业往往存储海量数据（上百 T 或 P 级）运维日志、或者是系统日志、业务日志。
完成ELK服务搭建后，首先我需要开启的是 MySQL 的慢查询配置，那么通过 set global slow_query_log=‘ON‘，这样就可以开启慢查询日志，还需要设置好慢查询日志标准是大于 1 秒的，那么同样是 set global long_query_time 大于或等于 1，它的意思是大于 1 秒的查询语句，才会认为是慢查询，并且做日志的记录。
那么另外还要设置慢查询日志的位置，通过 set global slow_query_log = 日志文件路径，这里设置到 filebeat 配置监听的路径下，就完成了慢查询日志的路径设置。
配置完成以后，需要在 MySQL 终端上，模拟执行一条执行时间较长的语句，比如执行 select sleep(5)，这样就会模拟执行一条查询语句，并且会让它休眠 5 秒。接下来我们看到服务端窗口的 MySQL 这条 sleep 语句已经执行完毕了，同时我们可以再打开 filebeat 的推送窗口，发现这里产生了一条推送日志，表示成功地把这条日志推送给了 ES。
那么接下来我们就可以通过浏览器打开 Kibana 的管理后台，从界面里来看一看检索日志的记录和一些可视化展示的图表，我们可以点击界面上的 Discover 按钮，同时选择好对应的时间周期，然后可以增加一个 filter 过滤器，过滤器里面敲入对应的关键字来进行索引。
这里我敲入的是 slow.query 这个关键字，就会匹配出对应的可以检索的项目，点击想要查询的对应项目，展示出想检索的某一个时间周期内对应的一些日志记录，以及它的图表是什么样子的，同时在下方会有对应的 MySQL 的日志信息打印出来，通过 Kibana 这样的可视化界面就能够看到的相关信息了。
Grok 是 Logstash 最重要的插件。你可以在 grok 里直接使用或应用预定义的表达式名称，grok 支持把预定义的 grok 表达式 写入到文件中，官方提供的预定义 grok 表达式见： https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patternss 。
最直观的grok语法使用参见： ELK应用之Logstash ；
https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html ，这里不做赘述。
下面是从官方文件中摘抄的最简单但是足够说明用法的示例：
第一列是正则grok表达式的名称，可直接使用；第二列是普通的正则表达式 ；
第一行，用普通的正则表达式来定义一个 grok 表达式；第二行，通过打印赋值格式，用前面定义好的 grok 表达式来定义另一个 grok 表达式。 （简单的说就是，名字和表达式，而且可嵌套使用）
grok 表达式使用的基本语法是下面这样的：
小贴士：SYNTAX是指预定义好的表达式的名字，SEMANTIC是指匹配之后要放的字段名字（自定义或随心所欲，只要自己能认识区分的）。
附录：
在日志处理的过程中，有一项非常常见的任务就是把原始的单行日志转换成结构化的日志。如果你使用了ELK，那么你可以利用ES对数据进行聚合，使用Kibana来进行数据可视化从日志中来发现一些有价值的信息。
在LogStash中，这项工作是由logstash-filter-grok来完成的，它有超过200个可用的，大家都认为是比较有用的Grok模式，例如IPv6地址、UNIX路径等等。
下面是一个示例日志
使用Grok库，我们可以很容易的就完成日志格式化提取的任务
提取后的数据格式如下
看起来这是一件非常简单的事情，好吧。。那这篇文章就这样写完了么，当然不是。。
这是一个非常常见的问题。性能这个问题通常都是要被拿出来讨论的，用户通常会发现使用了Grok表达式之后，LogStash处理日志的速度变得很慢。就像前面所说的一样，Grok模式是基于正则表达式的，所以这个插件在性能上已经对正则做了非常多的性能优化的了。接下来的章节，我们会讨论在使用Grok模式中需要注意的点
在设计Grok表达式的时候，我们需要一些方法来测试究竟哪种写法性能表现更好。出于这个原因，我些了个很小的jruby脚步用于测试Grok插件处理我所写的Grok模式的性能，你可以在这里获取到这个 脚本
尽管Grok匹配的性能是非常重要的，但是匹配失败的时候对性能的影响也是我们需要留意的。当grok匹配失败的时候，插件会为这个事件打个tag，默认是_grokparsefailure。LogStash允许你把这些处理失败的事件路由到其他地方做后续的处理，例如
这样的话我们就可以对这些处理失败的事件做性能基准测试了。
现在，我们要开始对Apache的日志进行格式化处理了
然后我们使用下面的Grok模式去进行格式化提取
然后我们使用三种示例日志去测试这个Grok的性能，和Grok不匹配的日志分别出现在开始，中间和结束的位置
下面是性能测试的结果
基于上面这个测试结果，我们可以发现，Grok的性能和不匹配的日志所出现的位置有关，最快与最慢的性能差了差不多6倍。这就能解释为什么有用户提出当Grok匹配日志失败的时候CPU会被吃满的原因了，例如这个issues
https://github.com/logstash-plugins/logstash-filter-grok/issues/37 .
我们能做些什么呢
我们已经知道了处理失败对grok的性能影响是非常大的，所以我们需要解决这个问题。对于正则引擎来说，你需要做的最合适的事情就是减少正则表达式所需要的猜测。这就是为什么贪婪匹配最好少用的原因，那回到这个问题，有没一种更好的方法来调整这个Grok模式呢，让我们重新来看看这行Apache的日志
刚才我们使用的Grok模式是这样的
由于用户以为Grok表达式只会从开头匹配到结束，所以导致了在一些普通的场景下也会出现性能问题。但是实际上，Grok只是被告知“在这段文本中寻找匹配的内容”，这就意味着下面这种示例也会被Grok所匹配。。。
呃。。这都行，不过解决这个问题还是很简单的，我们加一些锚点就搞定了。锚点可以让你再一个指定的位置处理字符串。加入了开始和结束的锚点之后(^和$)，Grok就会从开头处理日志到结束了。这对处理那些不能匹配的日志有非常重要的作用。假如我们没有假如锚点，当正则无法匹配这行日志的时候，它就会开始从子字符串中进行匹配，然后性能就会下降，接下来我们把锚点加上，然后再做一次测试
可以看到性能有了很大的提升，在一开始就匹配失败的场景中，性能提升了将近10倍
你可能会说，“好吧，我的日志都是能匹配通过的，没有上面的问题”，但是事情可能并不是这样的
我们看到过非常多的grok模式在处理同一个网关发出的多种应用日志时候所出现的问题，例如syslog。想象一下这样一个场景，我们使用了“common_header: payload“这种日志格式来记录了三种应用日志
通常我们会在一个Grok里面就把三种日志都处理掉
值得留意的是即使你的日志是能正常匹配的，Grok还是会按照顺序许匹配送进来的日志，当碰到第一个匹配成功的日志就break掉这个循环。这就要我们自己去判断一下，怎么放是最合适的了，不然的话会一个一个往下进行尝试，毕竟是多种不同的格式。
一种常用的优化方案是使用分层匹配来对这个Grok进行优化
这是两种匹配方案的性能测试结果
看起来真有意思。。使用锚点的话，无论哪种方案性能都是一样的。不用锚点的情况下分层Grok的方案比不分层的又快很多
我们已经得出了对_grokparsefaiure进行处理的必要性了，那么我们还能做什么呢？
从3.2.0这个Grok插件开始，它有一些参数可以帮助你了解为什么一个事件会被处理那么久了。使用 timeout_millis 和 tag_on_timeout 可以设置Grok匹配的最大处理时长。如果超时了，这个事件会被打上 _groktimeout 的tag，然后我们就可以把他们送到一个Grok处理失败的ES索引里面去做后续的分析了
另外一个很棒的方法是LogStash5.0带了插件性能统计的功能，我们可以通过API来查看插件处理日志的性能了
然后我们就可以通过 duration_in_millis 来判断一个插件的性能了
希望这篇文章能帮你了解为什么Grok的性能会变得慢和如何去提升他的性能。下面是对这篇文字的总结：
原文： https://www.elastic.co/blog/do-you-grok-grok
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）