CN112181927A - 一种微服务架构下的日志审计方法 - Google Patents

Abstract

一种微服务架构下的日志审计方法，首先提供一个公共的SDK包，作为日志输出的公共组件，使用open zipkin实现对请求链路的记录与跟踪，为每一个服务间交互请求生成唯一guid进行关联，将从中获取到相关guid存入到服务交互日志中实现日志的全链路关联，在运行时将日志内容输出到服务的文件目录下；日志过滤模块匀速消费缓存队列中的日志内容，针对不同topic的日志进行针对性的过滤与转换后存储到es集群中；最后通过kibana和运维管理平台实现日志内容的展示和告警。本发明通过日志中心提供对日志的实时采集、分析、展示能力，并通过日志中心及时了解系统性能、用户行为，保障微服务的高可靠运行。

Description

一种微服务架构下的日志审计方法

技术领域

本发明涉及计算机系统开发技术领域，具体涉及一种基于微服务架构的日志审计的方法。

背景技术

业务系统、设备及应用程序在运行过程中实时产生，记录运行内容的文本称为日志，每条日志记录一般都会包含日期，时间，用户和内容等信息描述。用户或者运维管理人员可以通过查看日志来检查系统错误发生的原因，统计系统的活动记录，或者找出用户的异常操作。

由于系统架构的日趋庞大，以及系统架构复杂性愈发增加，由此会产生大量的日志信息。很多企业都开始将整体型应用拆分为微服务形式。而在拆分大型应用时，我们需要建立松散耦合的模块，从而保证其便于测试并降低变更风险。另外，这些模块亦可独立部署以实现横向规模扩展。然而，这也会带来一些初看并不严重，但长远影响极其重大的问题——其中的典型代表就是日志记录。

在微服务的架构下，各个服务的日志是独立记录在服务器硬盘上，而服务间交互通过http这种无状态协议进行，导致日志与日志间难以产生关联，增加了运维管理人员排查日志的复杂度。这些日志需要存储以备查询和分析，而传统的关系数据库对日志存储、查询、分析的能力有限。

随着软件系统的容量、复杂度日趋提高，原有的日志管理模式存在的问题，在采集方面过去主要采用http接口的方式，由客户端(业务系统、服务器等)向服务端(审计平台)主动推送日志，这样的高耦合导致服务端接口改变时所有的客户端需要随之改变。日志监控方面在微服务架构下，过去的单节点发送日志的形式已经难以监控到一个请求链路上的所有日志状态。因此，需要考虑一种大容量复杂场景的日志审计方案。

发明内容

本发明的目的是提出一种高效的微服务架构下的日志审计方法，通过自定协议的方式实现日志审计。

本发明的技术方案如下：

一种微服务架构下的日志审计方法，其特征在于：

(1)首先提供一个公共的SDK包，作为日志输出的公共组件，其功能包含：服务链路追踪，服务请求过程中生成唯一标识符并记录；日志输出，根据不同类型日志自动修改日志格式并输出到消息队列；

(2)使用open zipkin实现对请求链路的记录与跟踪，zipkin在跟踪的过程中为每一个服务间交互请求生成唯一guid进行关联，将从中获取到相关guid存入到服务交互日志中实现日志的全链路关联；

(3)业务系统在集成了日志组件后，在运行时将日志内容输出到服务的文件目录下；

(4)日志过滤模块将匀速消费缓存队列中的日志内容，针对不同topic的日志进行针对性的过滤与转换后存储到es集群中；

(5)最后通过kibana和运维管理平台实现日志内容的展示和告警。

日志中心在微服务架构中起到了至关重要的作用，它是微服务监控的一个非常重要的切入点，本发明以技术实践为蓝本阐述了其设计、实现与关键配置，并详细阐述了日志审计个关键步骤和一些考量原则。采用这样的架构和原则，可以通过日志中心提供对日志的实时采集、分析、展示能力，并通过日志中心可以及时了解系统性能、用户行为，保障微服务的高可靠运行。

具体实施方式

本发明根据日志的产生源，将日志分类为系统日志和应用日志，其中系统日志多为中间件、开源组件等运行时产生的日志，此类日志信息多为格式、内容、位置单体固定，需要在解析时针对不同的组件进行专门的日志分析，应用日志一般是由开发人员在项目中开发的应用程序、业务系统，此类日志可以通过事前协议，产生出固定的日志内容。

应用日志可以通过在系统架构的不同层次分为用户操作日志，服务交互日志，应用运行日志和数据操作日志。

其中用户操作日志由客户端记录，服务端生产，主要记录用户对于应用程序的操作，比如查询，新增，修改，删除等事件。

服务交互日志是指应用程序或者微服务间的交互，根据执行动作主要分为响应和请求两种。根据不同协议会有不同的交互形式，例如http协议交互，socket协议交互，mq协议交互等。

应用运行日志是指业务系统在运行时，由自身主动发起的动作的日志记录，例如系统启动、定时任务等日志。

数据操作日志是业务系统对数据的修改记录，针对不同的数据源，包括关系化数据库、非关系化数据库、文件系统等，例如oracle、redis、MongoDB、elasticsearch、fastDFS等。

当根据不同情况分解出多种日志类型时，业务逻辑最终需要由一个或者多个组件构成。而在追踪这些事务时，我们往往很难对其加以识别。因此，需要为每个事务生成一个惟一标识符，并利用其关联事件以及追踪各项事务。

最后审计日志记录程序中的日志事件应包括：

1、操作系统(OS)事件：

启动和关闭系统；

启动和停止服务；

网络连接更改或失败；

更改或尝试更改系统安全设置和控件。

2、操作系统(OS)审核记录：

登录尝试(成功或不成功)；

登录后执行的功能(例如，读取或更新关键文件，软件安装)；

帐户更改(例如，帐户创建和删除，帐户权限分配)；

成功/失败使用特权帐户。

3、应用帐户信息：

成功和失败的应用程序验证尝试；

应用程序帐户更改(例如，帐户创建和删除，帐户权限分配)；

使用应用程序权限。

4、应用操作：

应用程序启动和关闭；

应用失败；

主要应用配置更改：应用程序事务，例如，电子邮件服务器，记录每封电子邮件的发件人，收件人，主题名称和附件名称；Web服务器记录请求的每个URL以及服务器提供的响应类型；业务应用程序记录每个用户访问哪些财务记录。

日志系统分为日志输出，日志采集，缓存队列，日志过滤，日志存储，日志展示及告警六个模块，可以达到一个应用程序或业务系统从应用编码到应用上线到应用运维一个生命周期的功能全覆盖。具体实现过程如下：

首先需要提供一个公共的SDK包，作为日志输出的公共组件，其功能包含：1、服务链路追踪，服务请求过程中生成唯一标识符并记录。2、日志输出，根据不同类型日志自动修改日志格式并输出到消息队列。微服务客户端需要接入此公共SDK，通过AOP拦截的方式，实现在业务编码过程中不需要考虑日志的输出与格式，达到全自动的日志拦截与记录。

使用open zipkin实现对请求链路的记录与跟踪，zipkin在跟踪的过程中会为每一个服务间交互请求生成唯一guid进行关联，将从中获取到相关guid存入到服务交互日志中实现日志的全链路关联。

业务系统在集成了日志组件后，会在运行时将日志内容输出到服务的文件目录下。

使用Kafka进行日志传输的原因在于其有数据缓存的能力，并且它的数据可重复消费，Kafka本身具有高可用性，能够很好的防止数据丢失，其次由于根据业务不同的需求，不同时间段内产生的日志数量也大有不同，通过kafka可以实现高并发情况下的日志缓存，延迟日志过滤模块的消费。

日志过滤模块将匀速消费缓存队列中的日志内容，针对不同topic的日志进行针对性的过滤与转换后存储到es集群中。

最后通过kibana和运维管理平台实现日志内容的展示和告警。

Claims (1)

1.一种微服务架构下的日志审计方法，其特征在于：

(1)首先提供一个公共的SDK包，作为日志输出的公共组件，其功能包含：服务链路追踪，服务请求过程中生成唯一标识符并记录；日志输出，根据不同类型日志自动修改日志格式并输出到消息队列；

(2)使用open zipkin实现对请求链路的记录与跟踪，zipkin在跟踪的过程中为每一个服务间交互请求生成唯一guid进行关联，将从中获取到相关guid存入到服务交互日志中实现日志的全链路关联；

(3)业务系统在集成了日志组件后，在运行时将日志内容输出到服务的文件目录下；

(4)日志过滤模块将匀速消费缓存队列中的日志内容，针对不同topic的日志进行针对性的过滤与转换后存储到es集群中；

(5)最后通过kibana和运维管理平台实现日志内容的展示和告警。