开发者社区> smile小太阳> 正文

基于ELK实时日志分析的最佳实践

简介: 摘要:在2018云栖大会深圳峰会大数据分析与可视化专场上,由阿里巴巴搜索引擎事业部开放搜索团队的吴迪带来了“基于ELK实时日志分析的最佳实践”的主题分享。介绍了传统的日志分析、ELK的概念和ELK实时日志分析的实践。
+关注继续查看

在2018云栖大会深圳峰会大数据分析与可视化专场上,由阿里巴巴搜索引擎事业部开放搜索团队的吴迪带来了“基于ELK实时日志分析的最佳实践”的主题分享。介绍了传统的日志分析、ELK的概念和ELK实时日志分析的实践。
数十款阿里云产品限时折扣中赶快点击这里领券开始云上实践吧!
直播视频回顾
以下为精彩视频内容整理:

什么是日志

首先来说一下日志,日志是属于程序的一部分,在编写程序的时候也就写好了日志。日志的作用是为了排查问题,尤其是突发的问题,一般线上出了问题首先翻日志。日志还可以给我们提供报警监控的功能,通过监控日志的变化,通过日志中可以看出系统出现的问题甚至做出预测。

传统的日志分析

通常用Linux中小工具去搜索关键字能得到我们需要用到的信息。这种传统的日志分析的效率是非常低的,尤其是当业务越来越多系统越来越庞大的时候,这时在搜集日志就会变得非常的困难。下面是针对传统日志分析过程中遇到的几点问题:
1、日志的集中收集与存储:当有上千个节点的时候,日志是分布在许多机器上,如果要获取这些日志的文件,不可能一台一台的去查看,所以这就是很明显的一个问题。
2、 日志搜索:这种搜索是基于文件的,并且这种效率也会比较低,并不能表达出逻辑上的关系,并不能对系统的全局作出判定。
3、 分析聚合及可视化:由于日志分布在不同的机器上所以查看起来很困难。
4、 安全、角色管理:当系统变大后就会有上百个人来查看日志,不同角色不同级别的人看到的是不同的日志而不是所有的人都能看到所有的日志,所以传统的日志可能就会有安全上的问题。
5、 可伸缩性:当系统越来越大的时候,会产生大量的日志。

ELK

现在在开源的生态里面,解决日志收集、搜索、日志聚合和日志分析的一个技术站就是ELK。可能大家已经接触过ELK,但在这里再给大家介绍一下,ELK是Elasticsearch+Logstash+Kibana的缩写。
Elasticsearch是一套搜索的框架,它的内核是Lucene,它把Lucene这个算法做了封装,提供了很方便使用的接口,以及有非常强大的扩展的能力。用Elasticsearch就可以很快速的做到全文检索的一个服务。
Logstash也是Elasticsearch公司的一个产品,是用来做数据源的收集,最初它是为了做日志但后来它不光做日志的收集只要是数据都可以用它来收集,它就是一个收集器。
Kibana可以把它理解为一个UI,但它不是一个简单的UI,通过Kibana可以看到ES上的所有数据,在这上面可以做各种的展示可以做各种图形化的界面。
这是ELK的一个介绍。因为ELK在开源的搜索领域是非常的火热,只要提到搜索都会想到Elasticsearch,提到数据的搜集就会想到Logstash,所以现在这套组件都成了标配了。

阿里云Elasticsearch生态

_1


这是一个阿里云的Elasticsearch生态,所有的这些组件都是基于阿里云的。可以看到这个Beats和Logstash是平行的,它俩的作用基本类似。和阿里云合作最重要的一点就是X-Pack,X-Pack提供了很多强大的功能,比如说Security就能解决前边的一些问题,不同级别的人可以看到不同的字段。数据本身也可以得到一个保护,安全也基本上可以放心。再介绍一下Alerting,如果用户在世界的多个地方登录了可以通过Alerting这个功能报警出来,可以做一个预警,因为这种行为可能是被黑客入侵。Monitoring是为了监控整个Elasticsearch技术站的组件。Graph可以分析出在Elasticsearch上所有的数据之间的关系,来帮我们更好的组织数据。Reporting是可以通过对数据的一些计算,能够分析出数据的变化,然后通过Reporting的机制告诉我们这些数据的变化。MachineLearning是在把数据导入Elasticsearch以后通过MachineLearning以后能够通过统计学上的一些计算能够分析出Graph一段时间的数据,甚至可以预测出未来变化的走向。所有的这一切都是建立在阿里云上面的。

数据安全

_2


右边这个大的虚线框是VPC网络,用户的数据和Elasticsearch的数据站都是在VPC里面,接触阿里云的ECS、VPC可能都知道它对于用户来说就是一个封闭的网络,外面进不去里面出不来,除非用户授权。右侧是用户的应用服务,用户的搜索都是在用户的VPC里面。中间是公网服务,通过有密码的保护,黑白名单的限制来保护服务暴露在公网上的安全性。Logstash可以把语音服务器、云数据库和云存储的数据都是可以导入到VPC里面的ES服务,用户这边可以使用到ES的数据。这样一来就可以保护用户的数据不被泄露。

Logstash架构

_3


Logstash这个架构非常简单,Input就是我能对接各种数据源,比如数据库、OSS等都可以对接。Filter做一些数据的处理,处理完了以后输出,输出可以输出到ES也可以输出到别的系统。所以Date Source通过Logstash输出到Date Destination。

通过Kibana搜索日志

把日志导入到ES这个技术站里面之后,其实就是通过ES解决了日志聚合的问题,可以散布在各个机器上的日志收集到一块,通过ES聚合在一起,通过Kibana就可以很方便的去搜索日志。

通过ES API定制搜索条件

通过API去搜索日志库,通过Kibana可以直接写查询的条件,这个是非常的方便的。

阿里云Elasticsearch性能

刚刚说了Elasticsearch的特性,我们在回来说一下Elasticsearch在阿里云上的一些性能。

_4


我们做了一个Elasticsearch的压测主要是5.5.3版本的,分别在2核4G、4核16G、16核64G的上做了一个压测。使用的是官方的压测工具,没有改任何的参数,都是默认的参数。可以看到这条绿色的线是官方的geonames3.3GB,单doc311B,在16和64G的时候可以达到每秒14万doc。后来做了更进一步的压测就是说多线程的时候它的性能会更好。这个比市面上的同类软件是要高很多的。

业务架构

_5


当需要搭建ELK的时候业务架构是什么样的。先看一下Beats,Beats是可以和业务部署在一起。Beats可以直接到Elasticsearch也可以直接到Logstash,Beats和Logstash的整合应用是现在比较流行的。整体的架构来看Logstash和Elasticsearch一般会分开部署,因为Logstash属于CPU密集型的组件,Elasticsearch属于I/O密集型的组件,所以在部署的时候会把两者分开。

实践

基于机器学习的日志分析

_6


机器学习可以对日志进行分析,这个虚线分析出这段时间内的一个趋势,然后分析所有日志的时候就会发现数据不太对的时候就可以通过Reporting来反馈给我们,并且还可以预测出趋势。

ELK监控告警

ELK监控报警是对ELK技术栈的一个报警,是对索引、节点的一个监控。我们致力于把搜索事业部一些很强大的功能通过阿里云这个平台向外输出,其实这个特性就是我们技术沉淀的一个输出,它会自动的分析整个ES的健康状况。然后把ELK的架构做一个自动的优化。

本文由云栖志愿小组陈欢整理编辑

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
游戏数据运营融合分析最佳实践
针对游戏行业数据分析实时性高、结构化和非结构化数据融合需求,构建游戏数据运营融合分析一体化架构。
544 0
OSS实时日志查询——访问记录秒级查询与可视化分析
OSS新发布“OSS访问日志实时查询”,用户可在OSS控制台,对OSS访问日志,进行可视化的实时查询与分析统计。该功能可简化用户对OSS访问记录的审计、统计、事件回溯、运维分析、问题定位等工作,提升运维效率,挖掘日志数据价值,提高基于数据的决策能力,助力业务发展。
2586 0
Observability:使用 Elastic Stack 分析地理空间数据
在今天的文章中,我们将参考之前的文章 “如何使用 Elasticsearch ingest 节点来丰富日志和指标”。我们可以利用 Elasticsearch ingest 节点来更加丰富我们的数据,并对这些数据做更进一步的的分析。
3742 0
【入门指南】使用阿里云Elasticsearch搭建ELK日志系统
本文介绍了基于阿里云Elasticsearch搭建ELK日志系统的基本步骤,并对kibana和ES的日志检索和分析做简要介绍,可作为新手入门指导。
12923 0
3月24日云栖精选夜读:Docker日志收集最佳实践
今天又是这么晚和读者们相见了,想必作为程序员的我们有的可能才下班,还有的可能还奋斗在一线吧~那么小编精心挑选的这些文章正是给这些经常熬夜的程序猿们品读的,花个5分钟,读读这些文章,让劳累了一天心灵得到放松,明天又能充满活力地写代码!
2646 0
【巡检问题分析与最佳实践】MongoDB 空间使用问题
阿里云数据库MongoDB的空间使用率是一个非常重要的监控指标,如果实例的存储空间完全打满,将会直接导致实例不可用。一般来说,当一个MongoDB实例的存储空间使用比例达到80-85%以上时,就应及时进行处理,要么降低数据库实际占用空间的大小,要么对存储空间进行扩容,以避免空间打满的风险。 然而,阿里云数据库MongoDB的空间使用情况分析并不简单,本文将由浅入深帮您查看,分析和优化云数据库MongoDB的空间使用。
376 0
25
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载