转载本文需注明出处:微信公众号EAWorld,违者必究。
引言:
日志向来都是运维以及开发人员最关心的问题。运维人员可以及时的通过相关日志信息发现系统隐患、系统故障并及时安排人员处理解决问题。开发人员解决问题离不开日志信息的协助定位。没有日志就相当于没有了眼睛,失去了方向。
微服务日渐火热,享受微服务架构带来的种种好处的同时也要承担起由微服务带来的种种困扰。日志管理就是其中一个。微服务有一个很大的特色:分布式。 分布式部署的结果就导致日志信息散落在各地,这样就给日志的采集存储带来了一定的挑战:
这篇文章将探讨一下日志管理的相关问题。
目录:
一、日志的重要性和复杂性
二、基于微服务的日志中心架构设计
三、日志中心的流程与实现
四、日志中心的关键配置
五、总结
一、日志的重要性和复杂性
要说管日志,在管日志之前有一个先决条件,我们需要知道日志是什么,能做什么,有什么用。援引百度百科的话,它是记录系统操作事件的记录信息。
在日志文件内部记录了当前系统的各项生命体征,就像我们在医院体检过后拿到的体检单,上面反应了我们的肝功能、肾功能、血常规等的具体指标。日志文件在应用系统中的作用就如同体检单,它反应了系统的健康状态、系统的操作事件、系统的变更状况。
日志在系统中扮演着监护人的身份,它是保障高可靠服务的基础,记录了系统的一举一动。运维层面、业务层面、安全层面都有日志的身影,系统监控、异常处理、安全、审计等都离不开日志的协助。
日志种类繁杂,一个健壮的系统可能会有着各种各样的日志信息。
如此复杂多样的日志,是否要一网打尽?哪些又是我们所需要的?这都是我们在设计日志中心架构时需要考虑的问题。
二、基于微服务的
日志中心架构设计
日志中心是微服务生态中不可或缺的一环,是监控的二当家。在此分享一下我们的产品级设计实践,了解一下,在基于微服务的架构,日志中心在技术架构中所处的位置是怎样的,以及如何部署。
在这一设计中,微服务结构由以下几部分组成:
图片中并没有日志中心这四个关键字,因为他是由多个独立组件共同协同构成的。这些组件分别是Filebeat、Kafka、Logstash、Elastic search,他们共同构成了日志中心。
我们经过考量研究确定了一套适用于当下微服务架构日志管理流程。
1. 日志选取 ---- 确定选择哪些日志记录分析
2. 日志采集 ---- filebeat轻巧做收集
3. 日志缓冲 ---- kafka缓存本地做缓冲
4. 日志筛选 ---- logstash筛选过滤
5. 日志存储 ---- elasticsearch建索引入库
6. 日志检索 ---- 利用elasticsearch本身的检索功能
7. 日志展现 ---- 参考kibana风格实现日志数据可视化
在传统的ELK上替换了Logstash做日志采集的部分采取Filebeat,在日志存储前多了kafka缓冲和logstash筛选。这一套流程在保障功能完备同时提高性能、尽可能做到轻量部署。
三、日志中心的流程与实现
微服务应用会分布在各个域内的各个系统。应用的日志也就相对应的产生在各个域内的各个系统。进行日志管理首先要做好日志的采集工作。日志采集工作我们选择Elastic Stack中的Filebeat。
Filebeat和应用是挂钩的,因为我们需要知道针对每个落点去收集日志信息,所以轻量其实是我们考量的主要因素。
Filebeat会有一个或者多个的叫做Prospector的探测器,可以实时监听指定的文件或者制定的文件目录的变更状况,将变更状况及时的传递到下一层---Spooler处理。
Filebeat还有一个特性我们放到日志筛选那里进行介绍,它是定位来源的关键。
这两点刚好满足我们实现日志的实时采集的需求。通过Filebeat动态的将新增的日志进行及时存储取样。至此如何采集日志信息的问题已经可以完美解决。
在日志存储之前,我们引入了一个组件--- Kafka,作为日志缓冲层。 Kafka起一个缓冲的作用,避免高峰期应用对ES的冲击。造成由于ES瓶颈问题而引发数据丢失问题。同时它也起到了数据汇总的功能。
选用kafka来做日志缓冲有几个优点:
日志信息经过filebeat、kafka等工具的收集传递,给日志事件加了很多附加信息。利用Logstash实现二次处理,可在filter里进行过滤或处理。
我们在Filebeat收集信息的时候通过将同一个Server上的日志信息发送到同一个Kafka的topic中来实现日志的汇总,这个topic名称就是server的关键信息。在更细粒度的层面上你也可以将每一个App的信息都当作一个topic来进行汇总。Kafka中通过Filebeat接受到的日志信息中包含了一个标识---日志是从哪里来的。Logstash的作用就是在日志汇入ES之前,通过标识将对应的日志信息进行二次筛选汇总处理,输送给ES,为之后的搜索提供依据。方便我们清楚的定位问题。
Elastic 是 Lucene 的封装,提供了 REST API 的操作接口,开箱即用。
选用ElasticSearch的原因主要为:可分布式的部署,方便拓展;处理海量数据可以应对多种需求;强大的搜索功能,基于Lucene可以实现快速搜索;活跃的开发社区,资料多、上手简单。
Elasticsearch本身就是一个强大的搜索引擎,支持通过系统、应用、应用实例分组、应用实例IP、关键字、日志级别、时间区间来检索所需要的日志信息。
(注:图片摘自互联网
https://blog.csdn.net/my_bai/article/details/68062701 服务调用折线图)
四、日志中心的关键配置
在此就不再赘述关于各个组件的安装方法了,大家可以很轻松的从网络上找到相关教程。我们在这里介绍一些关键的配置,确保大家在安装过程中关键环节少走一些弯路。
Filebeat的关键配置
对于EOS的应用我们是这样做的:统一输出在/opt/apps/logs/目录下,如:/opt/apps/logs/应用ID/应用ID_system.log, /opt/apps/logs/应用ID/应用ID_trace.log
五、总结
日志中心在微服务架构中起到了至关重要的作用,它是微服务监控的一个非常重要的切入点,本文以我们的团队技术实践为蓝本阐述了其设计、实现与关键配置,并详细阐述了日志管理的7个关键步骤和一些考量原则。
首先,在日志的选择上,要以业务场景为原则;选择之后的采集环节,可侧重考虑轻量级的Filebeat;在采集之后,选用吞吐量大的Kafka避免系统瓶颈造成的数据丢失;在存储之前,采用Logstash提前标识,便于问题的定位 ;充分利用ES和Kibana的功能来实现存储、检索和展现。
采用这样的架构和原则,我们可以通过日志中心提供对日志的实时采集、分析、展示能力。并通过日志中心可以及时了解系统性能、用户行为,保障微服务的高可靠运行。
关于作者:赵瑞栋,普元SOA&云计算部门java工程师,从事Eclipse插件开发,参与普元EOS8 Platform开发,现主要参与EOS8微服务管理平台开发工作。