普元云计算-基于微服务的日志中心设计、实现与关键配置

 

转载本文需注明出处：微信公众号EAWorld，违者必究。

 

引言：

日志向来都是运维以及开发人员最关心的问题。运维人员能够及时的经过相关日志信息发现系统隐患、系统故障并及时安排人员处理解决问题。开发人员解决问题离不开日志信息的协助定位。没有日志就至关于没有了眼睛，失去了方向。

 

微服务日渐火热，享受微服务架构带来的种种好处的同时也要承担起由微服务带来的种种困扰。日志管理就是其中一个。微服务有一个很大的特点：分布式。 分布式部署的结果就致使日志信息散落在各地，这样就给日志的采集存储带来了必定的挑战：

 

• 如何及时采集日志信息？

• 如何将日志信息进行汇总？

• 汇总以后如何对日志信息进行检索分析？

 

这篇文章将探讨一下日志管理的相关问题。

 

 

目录：

 

1、日志的重要性和复杂性

2、基于微服务的日志中心架构设计

3、日志中心的流程与实现

4、日志中心的关键配置

5、总结

 

1、日志的重要性和复杂性

 

要说管日志，在管日志以前有一个先决条件，咱们须要知道日志是什么，能作什么，有什么用。援引百度百科的话，它是记录系统操做事件的记录信息。

 

在日志文件内部记录了当前系统的各项生命体征，就像咱们在医院体检事后拿到的体检单，上面反应了咱们的肝功能、肾功能、血常规等的具体指标。日志文件在应用系统中的做用就如同体检单，它反应了系统的健康状态、系统的操做事件、系统的变动情况。

日志在系统中扮演着监护人的身份，它是保障高可靠服务的基础，记录了系统的一举一动。运维层面、业务层面、安全层面都有日志的身影，系统监控、异常处理、安全、审计等都离不开日志的协助。

日志种类繁杂，一个健壮的系统可能会有着各类各样的日志信息。

 

如此复杂多样的日志，是否要一网打尽？哪些又是咱们所须要的？这都是咱们在设计日志中心架构时须要考虑的问题。

 

2、基于微服务的日志中心架构设计

 

日志中心是微服务生态中不可或缺的一环，是监控的二当家。在此分享一下咱们的产品级设计实践，了解一下，在基于微服务的架构，日志中心在技术架构中所处的位置是怎样的，以及如何部署。

 

在这一设计中，微服务结构由如下几部分组成：

• 域：一个域是一套注册中心、配置中心、业务监控中心、网关等组成的生态圈。一个域内有能够有多个系统。

• 系统：一个系统内部能够部署多个应用。

• 应用：轻耦合的微服务应用。

图片中并无日志中心这四个关键字，由于他是由多个独立组件共同协同构成的。

这些组件分别是Filebeat、Kafka、Logstash、Elastic search，他们共同构成了日志中心。 

 

咱们通过考量研究肯定了一套适用于当下微服务架构日志管理流程。

 

1. 日志选取    ----    肯定选择哪些日志记录分析

2. 日志采集    ----    filebeat轻巧作收集

3. 日志缓冲    ----    kafka缓存本地作缓冲

4. 日志筛选    ----    logstash筛选过滤

5. 日志存储    ----    elasticsearch建索引入库

6. 日志检索    ----    利用elasticsearch自己的检索功能 

7. 日志展示    ----    参考kibana风格实现日志数据可视化

 

在传统的ELK上替换了Logstash作日志采集的部分采起Filebeat，在日志存储前多了kafka缓冲和logstash筛选。这一套流程在保障功能完备同时提升性能、尽量作到轻量部署。

 

3、日志中心的流程与实现 

选择：以业务场景为原则

日志内容复杂多样，如何去收集有价值的日志是咱们重点关注的。日志的价值实际上是取决于业务操做的，不一样的业务场景下相同类型的日志的价值会大相径庭。

根据以往的业务实践，结合企业级的一些业务需求，咱们选定关注如下几类日志。

• 跟踪日志【trace.log】 Server引擎的调试日志，用于系统维护人员定位系统运行问题使用。

• 系统日志【system.log】 大粒度的引擎运行的入口、出口的日志，用于调用栈分析，能够进行性能分析使用。

• 部署日志【deploy.log】 记录系统启动、中止、构件包部署、集群通知等信息的日志。

• 引擎日志【engine.log】 细粒度的引擎运行日志，能够打印上下文数据，用于定位业务问题。  

• 构件包日志【contribution.log】 构件包记录的业务日志（使用基础构件库的日志输出API写日志）

 

经过以上几种日志，咱们能够在分析问题时明确咱们要查找的位置，经过分类缩小查找范围提升效率。

 

采集（Filebeat）：侧重考虑轻量级

       

微服务应用会分布在各个域内的各个系统。应用的日志也就相对应的产生在各个域内的各个系统。进行日志管理首先要作好日志的采集工做。日志采集工做咱们选择Elastic Stack中的Filebeat。

 

• Filebeat是一个开源的文件采集器，基于go语言开发，不须要java环境，它是对logstash的重构产物。Filebeat对环境依赖很低比较亲民。                              

• Filebeat是一个轻量的采集器，最新版的Filebeat体积大约是20M左右，而logstash有近百兆。Filebeat更利于部署实施，减轻宿主压力。                                    

• 以前曾有对filebeat和logstash的测试对比，在采集日志方面，filebeat比logstash花费更少CPU和内存。Filebeat在日志采集方面有更好的性能表现。 

 

Filebeat和应用是挂钩的，由于咱们须要知道针对每一个落点去收集日志信息，因此轻量实际上是咱们考量的主要因素。

Filebeat会有一个或者多个的叫作Prospector的探测器，能够实时监听指定的文件或者制定的文件目录的变动情况，将变动情况及时的传递到下一层---Spooler处理。

Filebeat还有一个特性咱们放到日志筛选那里进行介绍，它是定位来源的关键。

这两点恰好知足咱们实现日志的实时采集的需求。经过Filebeat动态的将新增的日志进行及时存储取样。至此如何采集日志信息的问题已经能够完美解决。

 

缓冲（Kafka）：吞吐量大、易扩展、上限高

在日志存储以前，咱们引入了一个组件--- Kafka，做为日志缓冲层。 Kafka起一个缓冲的做用，避免高峰期应用对ES的冲击。形成因为ES瓶颈问题而引起数据丢失问题。同时它也起到了数据汇总的功能。

 

选用kafka来作日志缓冲有几个优势：

• 吞吐量大，一个topic能够拆分为多个partition。建议这几个partition在不一样的磁盘中。

• 分布式系统易拓展。

• Kafka的性能主要取决于它对磁盘的连续读写，它的性能很大程度上是取决于磁盘处理的能力。能够说只要磁盘性能容许，它就能够无限制的接收来自Filebeat的日志信息，从而实现一个缓冲的做用。

 

筛选（Logstash）：提早埋点、方便定位    

日志信息通过filebeat、kafka等工具的收集传递，给日志事件加了不少附加信息。利用Logstash实现二次处理，可在filter里进行过滤或处理。

咱们在Filebeat收集信息的时候经过将同一个Server上的日志信息发送到同一个Kafka的topic中来实现日志的汇总，这个topic名称就是server的关键信息。在更细粒度的层面上你也能够将每个App的信息都看成一个topic来进行汇总。Kafka中经过Filebeat接受到的日志信息中包含了一个标识---日志是从哪里来的。Logstash的做用就是在日志汇入ES以前，经过标识将对应的日志信息进行二次筛选汇总处理，输送给ES，为以后的搜索提供依据。方便咱们清楚的定位问题。

 

 

存储(ES)：方便扩展、上手简单

Elastic 是 Lucene 的封装，提供了 REST API 的操做接口，开箱即用。

选用ElasticSearch的缘由主要为：可分布式的部署，方便拓展；处理海量数据能够应对多种需求；强大的搜索功能，基于Lucene能够实现快速搜索；活跃的开发社区，资料多、上手简单。

 

检索（ES）：分门别类

Elasticsearch自己就是一个强大的搜索引擎，支持经过系统、应用、应用实例分组、应用实例IP、关键字、日志级别、时间区间来检索所须要的日志信息。

 

展示（Kibana）：简单配置、清晰明了

查看密密麻麻的日志信息的时候，经常会有一种晕眩感。须要经过精简提炼日志信息，对日志信息进行整合分析，以图表的形式将日志信息进行展现。在展现的过程当中咱们能够借鉴和吸取Kibana在日志可视化方面的努力，实现日志的可视化处理，只需经过简单的配置就能够看到对某一个服务或者某一个应用的清晰的可视化的日志分析结果。    

（注：图片摘自互联网https://blog.csdn.net/my_bai/article/details/68062701 服务调用折线图）

 

 

4、日志中心的关键配置

在此就再也不赘述关于各个组件的安装方法了，你们能够很轻松的从网络上找到相关教程。咱们在这里介绍一些关键的配置，确保你们在安装过程当中关键环节少走一些弯路。

 

Filebeat的关键配置

 

• enabled配置为true，表示打开日志采集能力。

• 在path中配置文件路径或者是文件目录位置，支持多级搜索。

对于EOS的应用咱们是这样作的：统一输出在/opt/apps/logs/目录下，如：/opt/apps/logs/应用ID/应用ID_system.log, /opt/apps/logs/应用ID/应用ID_trace.log

• 在output.kafka中配置输出对象。建议以本身的主机名做为topic名字，同一台机器上收取的各类日志会发送到kafka的同一个队列。

 

Kafka以及Zookeeper关键配置

• zookeeper.connect为zookeeper的集群地址

 

• server.1,server.2, server.3，

  注意和/opt/zookeeper/myid的内容里的数字一致用来标识server。

Logstash的关键配置

• Input 配置数据源输入

• Filter 将收取的源文件路径作截取，获取的文件名做为appid并将其存储在es数据中。做为后期筛选的标志。

• Output 配置数据源输出，输出信息到elasticsearch中。

 

Elasticsearch关键配置

 

• network.host 配置可访问es的地址，开发环境中配置为0.0.0.0表明容许任意一个ip访问，在生产环境中需配置为特定的ip，限制访问。

 

 

 

5、总结

 

日志中心在微服务架构中起到了相当重要的做用，它是微服务监控的一个很是重要的切入点，本文以咱们的团队技术实践为蓝本阐述了其设计、实现与关键配置，并详细阐述了日志管理的7个关键步骤和一些考量原则。

 

首先，在日志的选择上，要以业务场景为原则；选择以后的采集环节，可侧重考虑轻量级的Filebeat；在采集以后，选用吞吐量大的Kafka避免系统瓶颈形成的数据丢失；在存储以前，采用Logstash提早标识，便于问题的定位 ；充分利用ES和Kibana的功能来实现存储、检索和展示。

 

采用这样的架构和原则，咱们能够经过日志中心提供对日志的实时采集、分析、展现能力。并经过日志中心能够及时了解系统性能、用户行为，保障微服务的高可靠运行。

 

备注：本文的全部设计和实现的相关实践，来源普元最新的微服务架构平台EOS 8。

                                           

关于做者：赵瑞栋，普元SOA&云计算部门java工程师，从事Eclipse插件开发，参与普元EOS8 Platform开发，现主要参与EOS8微服务管理平台开发工做。

             

关于EAWorld：微服务，DevOps，数据治理，移动架构原创  技术分享，长按二维码关注