ELK架构实现日志收集分析

共计 2157 个字符，预计需要花费 6 分钟才能阅读完成。

引言

最近项目有了上线计划，现在面临着日志收集分析的问题，所以让小编来研究一下日志收集分析架构，下面就给大家分享一下小编搭建的第一套日志框架。

环境搭建过程见

 Linux 下日志分析 ELK 环境搭建手册  http://www.linuxidc.com/Linux/2017-05/143777.htm

架构图如下：

下面说一下这个 ELK 架构的实现原理，logstash 在架构中起到的作用是从每台服务器上的某个路径中的文件中收集数据，并且按照预先编写好的过滤规则来过滤数据，然后按照要求将日志传输到 ES 集群中，然后通过 kibana 进行数据的展示。

下面就是比较核心的一步，进行 logstash 的配置，里面包含对数据输入的配置，数据过滤的配置，数据输出的配置。这三个配置是最重要的。

文件名称为：elasticsearch_output.conf

input {
    file {
        path => “/var/log/nginx_access.log”
        type => “nginx”
        start_position => “beginning”
        sincedb_path => “/dev/null”
    }

}

filter {
    grok {
        match => [“message”, “%{TIME}\s+(?<Level>(\S+)).*?\((?<http>(\S+))\)\s*%{TIMESTAMP_ISO8601:time}\s+\[(?<uuid>(\S+))\]\s*\[%{IPORHOST:clientip}\].*”]
  }
}

output {
    elasticsearch {
        host => “192.168.22.189”
        protocol => “http”
        index => “itoo_output-%{type}-%{+YYYY.MM.dd}”
 document_type => “nginx”
        workers => 5
    }
}

因为我们的系统按照约定将日志文件输入到某个路径下面的.log 文件中，所以在选择输入类型的时候选择了 file 类型，其中还有 TCP、UDP、rsyslog 等类型。

filter 是我们自己编写的过滤规则，这个规则需要我们分析自己的日志，然后利用 logsta 已经给我编写好的一下正则表达式来完成自己的过滤规则的编写。

下面的地址是已经编写好的正则匹配文档：

https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns

输出我们选择了 ES，关于 ES 的介绍就不在本编博客中介绍，host 是我们搭建的 ES 集群的主节点的 ip 地址。index 就是在 es 中创建的名称。

然后我们在需要收集日志的服务器上面启动 logstash 服务运行这个配置文件即可，启动命令为

./logstash -f elasticsearch_output.conf

这样我们就会可以在 es 中查看已经导入的日志数据，并且当日志文件有更新的时候，logstash 会自动将新增加的内容收集并传入到 ES 中供我们查看。

这个架构已经搭建完成了，但是这存在着几个问题？

第一：编写过滤规则比较费事

第二：如何将一条错误堆栈信息收集成一条信息存储在 es 库中

这种架构的优缺点

优点：搭建简单，易于上手。

缺点：logstash 消耗资源大，运行占用的 CPU 和内存较高，并且没有消息队列缓存，这样存在数据的丢失的隐患。

架构二：

我们选择将 Linux 自带的 rsyslog 日志收集系统充当 logstash Agent，解决我们日志收集的问题。这样我们将分散每台服务器上面的日志通过 rsyslog 日志收集到并传输到 Logstash 服务器上面的某个文件中，然后我们在通过 logstash 过滤后送到 es 集群中，在这个架构中，如果日志系统比较大的情况下，我们还可以将 logstash 做成集群。这样就可以承担更大的日志量了。

这种架构在日志量不是很大的中小型项目中足够使用，这样我们是在一定程度上解决了日志量过大的问题，但是我们并没有解决 logstash 过滤文件编写的问题，也就说 logstash 比较难于定义，这是因为 logstash 是 ruby 语言编写的，这对于我们 Java 程序员来说不容易。所以我们也没有采用。

对于比较热衷于 logstash 的 用户，并且数据量比较大的情况下，采用第三种架构

这种架构小编没有搭建，以为我们决定采用 EFK 架构了，所以对于这种架构，小编知识从理论方面进行了分析，基于上面两种架构的弊端，在架构三中我们引入了 kafka 消息中间件类似消息队列的功能。并且 kafka 的集群搭建也是非常容易的，这样如果日志产生量非常大的情况下，我们可以将过剩的日志缓存在 kafka 集群中，慢慢的提供给 logstash 集群中进行过滤、传输到 ES 集群中。这种架构均衡了网络传输、从而降低了网络闭塞尤其是丢失数据的可能性。但是也没有解决 logstash 占用资源的问题。

通过分析对比我们最终选择 flume 来代替 logstash 进行数据的收集和传输。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-05/143778.htm