圈子里关于大数据、云计算相关文章和讨论是越来越多，愈演愈烈。行业内企业也争前恐后，群雄逐鹿。而在大数据时代的运维挑站问题也就日渐突出，任重而道远了。本文旨在针对复杂的大数据运维系统推荐一把利器，达到抛砖引玉的效果，如果文中出现任何纰漏和错误的地方，恳请指正，欢迎讨论，希望大家不吝赐教。
众所周知，大数据平台组件是很复杂的。笔者之前接触的一个大数据平台解决方案，仅平台组件就达20多个，这还没有加上物联网系统各组件。而这庞大的系统整合问题，对于运维来说是很头疼的。所以，在大数据时代下的运维问题是日渐尖锐。
有人把运维比作医生给病人看病，那么日志则是病人对自己的陈述。所以只有在海量分布式日志系统中有效的提取关键信息，才能对症下药。如果能把这些日志集中管理，并提供全文检索功能，不仅可以提高诊断的效率，同时可以起到实时系统监测、网络安全、事件管理和发现bug等功能。基于此，本文向大家推荐一款开源利器——ELK组件(Apache 2.0 License)，提供分布式的实时日志(数据)搜集和分析的监控系统。
ELK多种架构及优劣
既然要谈ELK在大数据运维系统中的应用，那么ELK架构就不得不谈。本章节引出四种笔者曾经用过的ELK架构，并讨论各种架构所适合的场景和优劣供大家参考。
先大致介绍ELK组件。ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件，但并非全部。后文的四种基本架构中将逐一介绍应用到的其它套件。
Elasticsearch是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能;是一套开放REST和JAVA API等结构提供高效搜索功能，可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递(例如 RabbitMQ)和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和Elasticsearch。
Kibana是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
我们先谈谈第一种ELK架构，如图1，这是最简单的一种ELK架构方式。优点是搭建简单，易于上手。缺点是Logstash耗资源较大，运行占用CPU和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议供学习者和小规模集群使用。
此架构首先由Logstash分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询，操作。用户亦可以更直观的通过配置Kibana Web Portal方便的对日志查询，并根据数据生成报表(详细过程和配置在此省略)。
图1 ELK架构一
第二种架构(图2)引入了消息队列机制，位于各个节点上的Logstash Agent先将数据/日志传递给Kafka(或者Redis)，并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka(或者Redis),所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。
图2 ELK架构二
这种架构适合于较大集群的解决方案，但由于Logstash中心节点和Elasticsearch的负荷会比较重，可将他们配置为集群模式，以分担负荷，这种架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题。
第三种架构(图3)引入了Logstash-forwarder。首先，Logstash-forwarder将日志数据搜集并统一发送给主节点上的Logstash，Logstash分析、过滤日志数据后发送至Elasticsearch存储，并由Kibana最终将数据呈现给用户。