漫谈ELK在大数据运维中的应用

圈子里关于大数据、云计算相关文章和讨论是越来越多，愈演愈烈。行业内企业也争前恐后，群雄逐鹿。而在大数据时代的运维挑站问题也就日渐突出，任重而道远了。众所周知，大数据平台组件是很复杂的。而这庞大的系统整合问题，对于运维来说是很头疼的。所以，在大数据时代下的运维问题是日渐尖锐。

有人把运维比作医生给病人看病，那么日志则是病人对自己的陈述。所以只有在海量分布式日志系统中有效的提取关键信息，才能对症下药。如果能把这些日志集中管理，并提供全文检索功能，不仅可以提高诊断的效率，同时可以起到实时系统监测、网络安全、事件管理和发现bug等功能。基于此，本文向大家推荐一款开源利器——ELK组件，提供分布式的实时日志（数据）搜集和分析的监控系统。

ELK简介

Logstash 早期曾经自带了一个特别简单的 logstash-web 用来查看 ES 中的数据。其功能太过简单，于是 Rashid Khan 用 PHP 写了一个更好用的 web，取名叫 Kibana。这个 PHP 版本的 Kibana 发布时间是 2011 年 12 月 11 日。

Kibana 迅速流行起来，不久的 2012年8月19日，Rashid Khan 用 Ruby 重写了 Kibana，也被叫做 Kibana2。因为 Logstash 也是用 Ruby 写的，这样 Kibana 就可以替代原先那个简陋的 logstash-web 页面了。

目前我们看到的 angularjs 版本 kibana 其实原名叫 elasticsearch-dashboard，但跟 Kibana2 作者是同一个人，换句话说，kibana 比 logstash 还早就进了 elasticsearch 名下。这个项目改名 Kibana 是在 2014 年 2 月，也被叫做 Kibana3。全新的设计一下子风靡 DevOps 界。随后其他社区纷纷借鉴，Graphite 目前最流行的 Grafana 界面就是由此而来，至今代码中还留存有十余处 kbn 字样。

2014年4月，Kibana3 停止开发，ES公司集中人力开始Kibana4的重构，在 2015 年初发布了使用 JRuby 做后端的 beta 版后，于 3 月正式推出使用 node.js 做后端的正式版。由于设计思路上的差别，一些 K3 适宜的场景并不在 K4 考虑范围内，所以，至今 K3 和 K4 并存使用。

2016-10-27 发布了 Elastic Stack 5.0 版

ELK架构原理

ELK是Elasticsearch、Logstash、Kibana的简称，这三者是核心套件，但并非全部

Elasticsearch是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放REST和JAVA API等结构提供高效搜索功能，可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。
Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和Elasticsearch。
Kibana是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。

ELK优点

Elastic Stack 在最近两年迅速崛起，成为机器数据分析，或者说实时日志处理领域，开源界的第一选择。和传统的日志处理方案相比，Elastic Stack 具有如下几个优点：

处理方式灵活。Elasticsearch 是实时全文索引，不需要像 storm 那样预先编程才能使用；
配置简易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 设计，都是目前业界最通用的配置语法设计；
检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的；
前端操作炫丽。Kibana 界面上，只需要点击鼠标，就可以完成搜索、聚合功能，生成炫丽的仪表板。

ELK用途

日志，对于不同团队来说会有不同的使用目的：

对于数据仓库团队来说，日志是他们要分析的信息数据来源之一；
对于安全团队来说，日志是他们构建安全防御与漏洞挖掘的一种特征来源和触发信号源；
对于应用团队来说，日志是他们了解自己的系统运行状态与排除错误的一种手段；

在服务结点不多的情况下，各个团队怎么使用这些日志或许可以百花齐放，但在中大规模服务部署的情况下，日志类别 * 技术方案 * 对接的系统等等这些因素的组合将极大加重系统研发和维护的负担，所以，我们需要一套分布式环境下集中采集，分析和管理日志的技术体系。

ELK日志采集和分析体系的建立

一套日志的管理体系通常需要处理以下几个阶段的工作：

日志的采集
日志的汇总与过滤
日志的存储
日志的分析与查询

1 日志的采集

灵活性是我们选择日志采集方案更看重的因素，所以logstash属于首先方案，它可以兼顾多种不同系统和应用类型等因素的差异，从源头上进行一些初步的日志预处理。

logstash唯一的小缺憾是它的不轻便，因为它是使用jruby开发并跑在java虚拟机上的agent，当然啦，同时也是优点，即各种平台上都可以用。

2日志的汇总与过滤

kafka在我们挖财已经属于核心的中间件服务，所以，日志的汇总自然而然会倾向于使用kafka。

日志的过滤和处理因为需求的多样性，可以直接对接订阅kafka，然后根据各自的需求进行日志的定制处理，比如过滤和监控应用日志的异常，即使通过zabbix进行预警；或者数据仓库方面在原始日志的基础上进行清洗和转换，然后加载到新的数据源中；

3日志的存储

原始的日志存储我们采用ElasticSearch，即ELK技术栈中E的原本用途，遵循ELK技术栈中各个方案之间的通用规范，比如日志如索引采用logstash与kibana之间约定的index pattern。

4日志的分析与查询

ELK技术栈中的Kibana已经可以很好的满足这一需求，通过在web页面对日志进行搜索查询、图表关联.

5日志报警功能与zabbix的集成

我们的监控平台选择了使用zabbix，所以各个系统如果有监控需求，最好都对接zabbix，避免维护多套不必要的运维系统。

在应用日志处理过程中，我们希望可以识别错误或者异常信号，然后通过zabbix报警和通知相应devops人员，为了达到这一目的，我们可以复用zabbix中的action/user/usergroup等实体配置，并且配置相应的虚拟host/item/trigger等实体，然后由日志处理系统在需要的时候，直接通过active的方式上报数据，具体操作方式为：

① 在日志处理系统中，通过zabbix_sender或者根据zabbix_sender的通信协议，在合适的时机发送状态数据；

② 在zabbix中，配置相应的host/item/trigger， item为zabbix trapper类型，key与zabbix_sender发送的key相对应；

日志系统亦可通过微信公众号进行规则报警，我们可以通过关注微信公众号，对匹配到并触发报警规则的日志进行查看，进行业务、服务的分析和日志定位。可以很方便的对监控字段建立起预警机制，在错误大规模爆发前进行预警。