ELK 不权威指南

超、凢脫俗 2022-05-25 04:51 254阅读 0赞

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

# 用户故事 #

## 场景一 ##

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

## 场景二 ##

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

## 场景三 ##

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

## 场景四 ##

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

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

# ELK是什么鬼? #

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

## 概述 ##

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

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

## 相关架构概念 ##

![20180508134347267][]

*  上面是一个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） 进行对比。 概念的对比如下表所示：

![20180508134427811][]

**ELK vs Linux Grep**

![20180508134458582][]

**ELK能做什么?**

## 应用场景 ##

*  安全领域

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

*  网络领域

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

*  应用领域

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

*  另类应用

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

# ELK落地方案 #

## 架构选型 ##

下面是一种常见的ELK架构

![20180508134527529][]

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

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

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

![20180508134624596][]当然， 上面的架构也不是一层不变。如果日志量更大，可以考虑使用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》

尝试自行搭建一下？[安装搭建教程][Link 1]

\------------------------------------------------------

我的[个人域名][Link 2]

期望和大家一起学习，共同进步，共勉

欢迎交流问题，可加个人QQ 469580884

或者，加我的群号 **751925591**，一起探讨交流问题

不讲虚的，只做实干家

Talk is cheap，show me the code

![20180411181545874][]

[20180508134347267]: /images/20220525/415a41c49470480bb45aa02918b74e3c.png
[20180508134427811]: /images/20220525/ec58805f521d4329a94416b26333c85f.png
[20180508134458582]: /images/20220525/310fa11899b748f48e335fd0e75434b6.png
[20180508134527529]: /images/20220525/140fea116062477f986387e024bb82c4.png
[20180508134624596]: /images/20220525/1b2163c747a341c09efade395a7ebf7e.png
[Link 1]: https://blog.csdn.net/hemin1003/article/details/73295303
[Link 2]: http://heminit.com/
[20180411181545874]: /images/20220525/a8f8fc9030904230bce78483ad47316a.png