传统项目中,如果需要在生产环境定位异常的话,我们常常需要在服务器上使用命令的方式查询。而很多情况我们需要用到微服务架构或集群架构,日志被分散在不同的机器上,使得日志的查询变得异常困难。工欲善其事,必先利其器。如果此时有一个统一的实时日志分析平台,那可谓是绝渡逢舟,必定能够提高我们排查线上问题的效率。本文我们就来一起学习下开源的实时日志分析平台 ELK 的搭建及使用。
〓 ELK 简介
ELK 是一个开源的实时日志分析平台,它主要由 Elasticsearch、Logstash 和 Kibana 三部分组成。
常见模式如下:
1)datasource->logstash->elasticsearch->kibana
2)datasource->logstash->redis/kafka->logstash->elasticsearch->kibana
3)datasource->filebeat->logstash-> elasticsearch->kibana
4)datasource->filebeat->redis/kafka->logstash-> elasticsearch->kibana
5)datasource->filebeat->logstash->redis/kafka->logstash->elasticsearch->kibana
Ps:datasource可以是log4j产生的file文件,也可以是mysql,kafka等
这里我们把elk传输处理场景进行一个,从数据源开始,如何采集,用什么工具采集,采集到哪里,经过怎样的处理过滤,传输到哪里,怎样进行展示。本文介绍第2和第4种方案,推荐第4种方案。
▍Logstash
Logstash 主要用于收集服务器日志,它是一个开源数据收集引擎,具有实时管道功能。Logstash 可以动态地将来自不同数据源的数据统一起来,并将数据标准化到您所选择的目的地。
必须说的是Logstash很占用资源,比较重。它有两个角色shipper[日志收集]和indexer[日志存储],而一台服务器只能存在一个Logstash实例。基于此,如果你一台服务器已经用了Logstash的indexer角色存储日志到ES,再用Filebeat代替Logstash的shipper角色来收集日志,就显得非常有价值,而且它非常轻量,不会加重服务器负担,且Filebeat还非常稳定,基本不会有宕机问题。
Logstash 收集数据的过程主要分为以下三个部分:
• 输入:数据(包含但不限于日志)往往都是以不同的形式、格式存储在不同的系统中,而 Logstash 支持从多种数据源中收集数据(File、Syslog、MySQL、消息中间件等等)。
• 过滤器:实时解析和转换数据,识别已命名的字段以构建结构,并将它们转换成通用格式。
• 输出:Elasticsearch 并非存储的唯一选择,Logstash 提供很多输出选择。
▍Elasticsearch
Elasticsearch (ES)是一个分布式的 Restful 风格的搜索和数据分析引擎,它具有以下特点:
• 查询:允许执行和合并多种类型的搜索 — 结构化、非结构化、地理位置、度量指标 — 搜索方式随心而变。
• 分析:Elasticsearch 聚合让您能够从大处着眼,探索数据的趋势和模式。
• 速度:很快,可以做到亿万级的数据,毫秒级返回。
• 可扩展性:可以在笔记本电脑上运行,也可以在承载了 PB 级数据的成百上千台服务器上运行。
• 弹性:运行在一个分布式的环境中,从设计之初就考虑到了这一点。
灵活性:具备多个案例场景。支持数字、文本、地理位置、结构化、非结构化,所有的数据类型都欢迎。
▍Kibana
Kibana 可以使海量数据通俗易懂。它很简单,基于浏览器的界面便于您快速创建和分享动态数据仪表板来追踪 Elasticsearch 的实时数据变化。其搭建过程也十分简单,您可以分分钟完成 Kibana 的安装并开始探索 Elasticsearch 的索引数据 — 没有代码、不需要额外的基础设施。
在 ELK 中,三大组件的大概工作流程如下图所示,由 Logstash 从各个服务中采集日志并存放至 Elasticsearch 中,然后再由 Kiabana 从 Elasticsearch 中查询日志并展示给终端用户。
▍插入介绍 Filebeat
Filebeat是一个日志文件托运工具,在服务器上安装客户端后,Filebeat会监控日志目录或者指定的日志文件,追踪读取这些文件(追踪文件的变化,不停的读),并且转发这些信息到Logstarsh中存放。上图的收集日志的过程,实际中我们往往会使用Filebeat来完成。
Filebeat 由两个主要组件组成:harvester 和 prospector :
• 采集器 harvester 的主要职责是读取单个文件的内容。读取每个文件,并将内容发送到 the output。每个文件启动一个 harvester,harvester 负责打开和关闭文件,这意味着在运行时文件描述符保持打开状态。如果文件在读取时被删除或重命名,Filebeat 将继续读取文件。
• 查找器 prospector 的主要职责是管理 harvester 并找到所有要读取的文件来源。如果输入类型为日志,则查找器将查找路径匹配的所有文件,并为每个文件启动一个 harvester。每个 prospector 都在自己的 Go 协程中运行。
注:Filebeat prospector只能读取本地文件,没有功能可以连接到远程主机来读取存储的文件或日志。
Filebeat由以上两个组件一起工作来读取文件(就如tail -f)并将事件数据发送到您指定的输出。
〓 ELK 实现方案
通常情况下我们的服务都部署在不同的服务器上,那么如何从多台服务器上收集日志信息就是一个关键点了。本篇文章中提供的解决方案如下图所示:
如上图所示,整个 ELK 的运行流程如下:
1. 在微服务(产生日志的服务)上部署一个 Shipper 角色的 Logstash,或者部署一个Filebeat,主要负责对所在机器上的服务产生的日志文件进行数据采集,并将消