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》