龙空技术网

分布式日志管理系统:从ELK到EFK

微说互联网 4163

前言:

此刻朋友们对“elk监控服务器”大约比较珍视,兄弟们都想要学习一些“elk监控服务器”的相关文章。那么小编也在网上收集了一些有关“elk监控服务器””的相关文章,希望兄弟们能喜欢,看官们一起来了解一下吧!

在我们的服务器上通常会生成各种日志文件,比如系统日志、 应用日志、安全日志。当系统发生故障时,工程师需要登录到服务器上,在日志里查找故障原因。

如果定位到处理请求的服务器部署了多个实例,那么就需要到每个实例的日志目录下去查看日志。另外每个服务器实例还需要设置日志滚动策略,比如每天生成一个文件,以及日志压缩归档策略等。

管理分布式集群的多台服务器的日志,是很麻烦的事情。尤其是排查故障的时候,服务器太多通过日志找故障太麻烦。因此需要把这些服务器的日志集中管理,并提供集中检索功能,这样就可以提高故障诊断的效率。

业界通用的日志数据管理方案主要包括 Elasticsearch 、 Logstash 和 Kibana 三个组件,这三个组件又先后被收购于Elastic.co公司名下。取三个组件的首字母,业界把这套方案简称为ELK。

什么是ELK?

Logstash :数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储以供后续使用。

Elasticsearch :分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点,可以用于全文检索、结构化检索和分析。ES 基于 Lucene 开发,Lucene是现在使用最广的开源搜索引擎之一,Wikipedia 、StackOverflow、Github 等都基于Lucene来构建搜索引擎。

Kibana :可视化平台。能够搜索、展示存储在 Elasticsearch 中的索引数据,使用Kibana可以很方便地用图表、表格、地图展示和分析数据。

Logstash部署架构

常见的Logstash的部署架构如下图所示,主要由Shipper、Broker和Indexer三个角色组成。

Shipper:日志收集者,也就是Agent。负责监控本地日志文件的变化,及时读取日志文件的最新内容,经过处理输出到Broker。Broker:日志Hub,用来连接多个Shipper和多个Indexer。Redis是Logstash官方推荐的Broker,支持订阅发布和队列两种数据传输模式。Indexer:日志存储者。负责从Redis接收日志,经过处理,比如对文本进行格式化,之后写入到本地文件。

无论是Shipper还是Indexer,Logstash始终只做三件事:日志的收集、过滤和输出。主要由三个部分组成:Input 、Filter、Output。

Logstash实例由Input、Filter、Output组成

Input(输入):Logstash实例通过Input插件可以读取多种数据源,输入数据可以是Java日志、Nginx日志 、TCP连接、控制台输入 、Syslog(系统日志)、Redis 、Collectd(系统监控守护进程)等。

Filter(过滤):通过Filter插件可以将日志转换为我们需要的格式。Logstash 提供了丰富的Filter插件,包括date(日志解析)、grok(正则解析)、dissect(分隔符解析)、mutate(字段处理)、json解析、geoip(地理位置数据解析)、ruby等。

Output(输出):通过 Output 插件可以实现数据的多份复制输出,输出目标可以是控制台、Redis 、TCP 、文件、Email等,目前业内常用的输出方式是和搜索引擎Elasticsearch来对接。

接下来我们看一下Logstash与ES如何配合实现ELK架构。

ELK架构

ELK架构

数据收集端:每台服务器都在上面部署 Logstash Shipper来收集日志,经过处理传输到 Elasticsearch 集群。

数据存储与搜索:采用多个 Elasticsearch 节点组成 Elasticsearch 集群,采用集群模式运行,可以避免单个实例压力过重的问题。

数据展示:Kibana 可以根据 Elasticsearch 的数据来绘制各种各样的图表,直观的展示业务实时状况。

Kibana

加入队列的ELK

当并发量较大的时候,由于日志传输峰值较高,会导致 Elasticsearch 集群丢失数据。对于这种Logstash数据超过ES集群处理能力的情况,可以通过队列就能起到削峰填谷的作用, Elasticsearch 集群就不存在丢失数据的问题。

目前业界在日志服务场景中,使用比较多的两种消息队列是Kafka和Redis。Redis 队列多用于实时性较高的消息推送,并不保证可靠。Kafka保证可靠但有点延时。

Kafka作为队列加入ELK架构

轻量级的Agent方案:Filebeat

Filebeat 是基于原先 logstash-forwarder 的源码改造出来的,用 Golang 编写,无需依赖 Java 环境就能运行,安装包10M不到。

Filebeat效率高,占用内存和 CPU 比较少,可以解决在服务器上部署Logstash shipper消耗资源较高的问题,非常适合作为日志收集系统的Agent运行在服务器上。

ELK/EFK总结

基于 ELK或EFK的分布式日志解决方案的优势主要体现在以下几个方面:

扩展性强:采用高可扩展性的分布式系统架构设计,可以支持每日 TB 级别的新增数据。使用简单:通过用户图形界面实现各种统计分析功能,简单易用,上手快响应迅速:从日志产生到查询可见,能达到秒级完成数据的采集、处理和搜索统计。界面美观:Kibana 界面上,只需要点击鼠标,就可以完成搜索、聚合功能,生成炫丽的仪表板。

对于除了ELK方案以外,在分布式日志管理上,我们还有很多其他的选择。近年来随着大数据的发展,海量数据采集组件Flume也开始广泛应用于分布式日志解决方案中。因为没有太多日志分析需求,我的团队采用了更轻量级的方案:Loki + promtail + grafana,建立类似Prometheus的日志监控系统,promtail负责收集日志,Loki负责存储,grafana负责展示。

我会持续更新关于物联网、云原生以及数字科技方面的文章,用简单的语言描述复杂的技术,也会偶尔发表一下对IT产业的看法,欢迎大家关注,谢谢。

标签: #elk监控服务器