服务器微服务实践

微服务实践1-业务日志

2018-10-04  本文已影响186人  Wales_Kuo

日志的目标是进行行为跟踪,将用户行为、系统行为记录下来用于之后的分析的过程都可以称之为日志。在业界逐渐向微服务迁移的过程中,很多的行为记录手段都逐渐的成为业界热门。例如:调用链跟踪,度量指标(metrics),日志收集系统,日志分析系统,应用性能监控(APM)等。

随着微服务概念在业界不断的发展与演进,我也针对微服务中行为跟踪进行了一些研究。在针对不同的环境下需要使用不同的方式去完成行为的跟踪与记录:

系统设计

以上的内容会在之后的文章中做介绍。现在我们拉回来,开始讨论日志。这里深入日志这个话题讨论一点内容。

模式选择

一般的日志收集方式分为两种:拉和推,与消息通信中的Pull和Push的概念是相同的。拉取的方式为由Master主动发起日志获取动作,然后在各个Agent上将日志拉到Master节点。推的方式为由Agent主动的向Master发送日志,Master在接收到日志之后将数据存储起来。

对比以上特点之后,推模式更适用于业务日志类型的内容,具体如下:

拉模式非常适用于系统日志的收集工作,之后会在微服务实践-系统日志中说明拉模式的使用。

技术选型

选择了日志收集方式之后,我们看一下技术选型:
下图来自于Flume官网

Flume架构

下图来自于ELK官网:

Logstash架构

根据以上两图,并综合Logstash和Flume的特点对比如下:

从上可以得出结论,更注重稳定性,效率方面的内容使用Flume比较好。比较注重灵活性,可配置性方面可以使用Logstash。我们这里选择Logstash是因为可以满足业务日志需求,是因为业务日志不需要太高的性能、并且可以在Flow中处理简单逻辑、达到数据清洗的目的。

方案制定

接下来看业务日志的部署结构:
本图来自ELK官网

ELK部署结构

从上图看,要完整的部署Logstash是一件比较复杂的事情。我这里主要的目标是业务日志可以在软件工程师在不修改任何代码的情况下可以将业务日志输出到数据库中,所以,简化后的操作如下图所示:


业务日志架构图

日志又可以分为业务日志,系统日志。业务日志又可以分为操作日志、行为日志、搜索日志等。本次内容设计为业务日志中操作日志的记录系统。操作日志流程:为系统用户访问系统服务。各服务根据业务特点,调用操作日志API,然后API通过Log4J2的Syslog功能将日志信息发送到logstash中。然后由Logstash写入到数据库中。

实施步骤:

上一篇下一篇

猜你喜欢

热点阅读