ELK不权威指南

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, 进行获取。 我们将在三个工作日内将资料发送到您的邮箱。

编辑于 2016-10-16

文章被以下专栏收录