ELK 不权威指南 超、凢脫俗 2022-05-25 04:51 204阅读 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
还没有评论,来说两句吧...