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

在我们的服务器上通常会生成各种日志文件，比如系统日志、应用日志、安全日志。当系统发生故障时，工程师需要登录到服务器上，在日志里查找故障原因。
如果定位到处理请求的服务器部署了多个实例，那么就需要到每个实例的日志目录下去查看日志。另外每个服务器实例还需要设置日志滚动策略，比如每天生成一个文件，以及日志压缩归档策略等。
管理分布式集群的多台服务器的日志，是很麻烦的事情。尤其是排查故障的时候，服务器太多通过日志找故障太麻烦。因此需要把这些服务器的日志集中管理，并提供集中检索功能，这样就可以提高故障诊断的效率。
业界通用的日志数据管理方案主要包括 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 集群。
【分布式日志管理系统：从ELK到EFK】数据存储与搜索：采用多个 Elasticsearch 节点组成 Elasticsearch 集群，采用集群模式运行，可以避免单个实例压力过重的问题。
数据展示：Kibana 可以根据 Elasticsearch 的数据来绘制各种各样的图表，直观的展示业务实时状况。

文章插图
Kibana
加入队列的ELK当并发量较大的时候，由于日志传输峰值较高，会导致 Elasticsearch 集群丢失数据。对于这种Logstash数据超过ES集群处理能力的情况，可以通过队列就能起到削峰填谷的作用， Elasticsearch 集群就不存在丢失数据的问题。
目前业界在日志服务场景中，使用比较多的两种消息队列是Kafka和Redis 。Redis 队列多用于实时性较高的消息推送，并不保证可靠。Kafka保证可靠但有点延时。