ELK的简单科普文章，加入了自己的一些理解。 内容包括ELK的基本介绍， 应用场景， 架构设计， 监控及自监控， 业界进展及推荐资料等。

用户故事

场景一

作为一个运维工程师， 某天虚拟机出现故障， 想看看虚拟机是否有异常日志，物理机上是否有异常日志， 管理物理机的云平台／系统是否有发生异常日志， 一个个主机 系统登陆过去， 输入账号密码费时费力，有时还会出现记不住密码干着急的情况，大大影响了排障的效率。 有没有一个系统，能够集中查看和搜索日志，不需要繁琐的登陆， 方便的获取排障所需的重要信息， 有异常还能够订阅？

场景二

作为一个开发人员， 开发的系统经常需要调用外部的api， 每次出现问题需要去查看日志，看是哪个环节出现问题， 是调用第三方api出错，还是连接数据库出错，只能一个一个查。 另外还会遇到的问题是， 有时候无意中grep了一个大的文件，导致iowait冲高，引发不必要的系统异常告警。 有没有一个工具能够提供各种仪表盘，每次打开一个页面就能一目了然的看到调用各个api的情况，调用了多少次， 失败了多少次？

场景三

开发人员上线新版本，上线过程中可能会出现各种问题。 有时不能及时发现会引起哪些异常，对其它系统有哪些影响。有没有一个工具 可以看到和分析上线新版本前后的变化？这样 就能有助于分析相应的故障是否是和上线新版本有关了。

场景四

作为一个团队领导， 团队开发产品已经上线一段时间了， 希望看到产品有多少人访问， 哪个功能访问了多少次，模块的出错率如何，每次都到机器上去跑分析脚本，费时费力，还不直观， 如果产品部署在分布式集群统计起来更是麻烦， 有没有一个系统能以更加简便的方式可以查看到这些情况？

上述的问题，ELK统统可以解决。

ELK是什么鬼?

简而言之， 如果说日志是埋在土里的宝藏，那么ELK是开采宝藏的蓝翔挖掘机。

概述

ELK是一套解决方案而不是一款软件， 三个字母分别是三个软件产品的缩写。 E代表Elasticsearch,负责日志的存储和检索； L代表Logstash, 负责日志的收集，过滤和格式化；K代表Kibana，负责日志的展示统计和数据可视化。

其中Elasticsearch是整个ELK的核心， L和K都有相应的替代方案。 这里重点介绍下ElasticSearch（下面简称es）的一些知识。

相关架构概念

• 上面是一个1个node， 2个replica， 3个shard的结构
• cluster（集群）由多个node（节点）组成
• 数据会被索引，并保存在index里（类比RDBMS里的DB)
• 一个index可以切成多个shard（分片），每个shard可以有多个replica（副本）
• node分为三种类型， 分别是master node，data node ，client node。 每个cluster会有一个node被选举成master，负责维护cluster state data。
• shard均匀分布在所有可用的data node

ES 和 关系型数据库的概念比较

ES本身可以理解为自带搜索引擎的数据库。 有些概念可以和关系型数据库（比如说MySQL） 进行对比。 概念的对比如下表所示：

ELK vs Linux Grep

ELK能做什么?

应用场景

• 安全领域

通过分析系统日志， 发现攻击或者非法访问行为，可以追踪定位相关安全问题。 比如结合FreeIPA(一款集成的安全信息管理解决方案)， 可以做一些暴力破解行为可视化分析等。

• 网络领域

日志分析和监控可以作为网络设备监控的一种补充， 其它监控系统，如zabbix大多是通过snmp的方式来获取网络设备的性能数据， 这种方式有其局限性，如无法监控端口的flapping， 无法监测到设备引擎挂掉等情况。 此外由于snmp监控的方案通用型不好， 各个厂商有自己的私有OID, 意味着需要对这些不同的厂商适配不同的监控模板。 另外， snmp获取数据的实时性相对会比syslog日志慢一些。

• 应用领域

分析和展示移动端业务的实时情况，如设备类型分析， 业务访问量， 业务访问高峰情况等；分析nginx日志得到网站的访问情况，如网站点击数， api请求总数、平均每秒请求数、峰值请求数，可以大体了解系统压力，作为系统扩容、性能及压力测试时的直接参考。

• 另类应用

用于社会工程学的用户画像；函数堆栈调用分析；网络流量分析

ELK落地方案

架构选型

下面是一种常见的ELK架构

这个架构的优点是简单，维护起来也方便。 但是也有一些问题。

• shipper耗主机资源。 直接用logstash当作日志采集的agent， 会比较重，会占用不少主机资源， 因此官方现在已经不推荐用logstash当shipper了， 推荐使用beat。
• 权限控制的问题。 kbana自身对页面访问权限控制这块是比较弱。 如果希望对页面的访问权限做控制， 可以考虑使用es search guard + ldap + nginx的方案来实现。
• 跨网络分区的问题 。如果有多个数据中心，且日志的流量比较大， 让日志跨网络分区进行传输，无疑会占用不少宝贵的专线带宽资源，会增加运营的成本，且有可能影响到其它应用的正常运行。 有一个解决此类问题的方案， 在各个网络分区各搭建一套ELK集群，日志不跨网络分区进行传输， 然后单独使用某些es节点作为tribe角色， 对搜索请求进行合并和路由。

为解决上面提到的问题， 设计了以下架构：

当然， 上面的架构也不是一层不变。如果日志量更大，可以考虑使用hangout来代替logstash， 用kafka来替代redis， 从而获得更大的日志吞吐量。

监控告警

日志的告警

可以采用elastalert。 当然也可以自己开发应用从es或者kafka取数据来做分析。

自身的监控

• 使用zabbix 监控。 网上可以找到对应的模版。
• 使用官方提供的marvel方案， 不过是收费的。
• 使用open falcon监控。 我们内部有一套open falcon系统， 所以我们尝试用open falcon来监控es集群。

挑战和思路

SaaS化

就是把ELK提供为SaaS服务，目前新浪云， 青云， aws等云平台上面已经有相应的服务了。 把日志分析系统SaaS化， 可以免去用户搭建和维护elk集群的麻烦，减少用户的使用成本，同时也可以给云平台自身带来更多的附加值。

大数据分析

用ELK堆栈来存储和索引海量的日志数据， 后面再结合大数据分析和机器学习工具，可以做智能运维分析， 减少运维人员之苦。

推荐资料

• 《Elasticsearch 权威指南》
• 《ELK中文指南》
• 《Mastering ElasticSearch》
• 《Manning Elasticsearch in Action》

如果需要一些ELK相关技术分享ppt， 电子书等，可以关注我们的公众号hackstoic，在公众号里回复您的姓名，邮箱，注明elk， 进行获取。 我们将在三个工作日内将资料发送到您的邮箱。