ELK架构实现日志收集分析

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: ELK架构实现日志收集分析

引言


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


环境搭建过程见Linux系统ELK环境搭建手册


架构图如下:


20170210192330840.png

下面说一下这个架构的实现原理,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和内存较高,并且没有消息队列缓存,这样存在数据的丢失的隐患。

 

架构二:


20170210194836737.png

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


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


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


20170210195941996.png


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

 

通过分析对比我们最终选择flume来代替logstash进行数据的收集和传输。在下面的博客中将分享flume+kafka+ES框架的学习。


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
20天前
|
监控 应用服务中间件 定位技术
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
|
1月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
1月前
|
存储 SQL 监控
|
1月前
|
运维 监控 安全
|
1月前
|
存储 监控 安全
|
1月前
|
监控 关系型数据库 MySQL
分析慢查询日志
【10月更文挑战第29天】分析慢查询日志
42 3
|
1月前
|
运维 NoSQL Java
后端架构演进:微服务架构的优缺点与实战案例分析
【10月更文挑战第28天】本文探讨了微服务架构与单体架构的优缺点,并通过实战案例分析了微服务架构在实际应用中的表现。微服务架构具有高内聚、低耦合、独立部署等优势,但也面临分布式系统的复杂性和较高的运维成本。通过某电商平台的实际案例,展示了微服务架构在提升系统性能和团队协作效率方面的显著效果,同时也指出了其带来的挑战。
84 4
|
1月前
|
监控 关系型数据库 数据库
怎样分析慢查询日志?
【10月更文挑战第29天】怎样分析慢查询日志?
42 2
|
2月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1699 14
|
2月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
146 1