当前, 计算机已经融入到了我们的日常生活中, 生活的各个方面都会涉及到各种计算机系统, 为了监视这些系统运行是否正常并能在系统出现故障时帮助用户及时定位, 系统中通常会设计日志系统来输出一些有用的日志信息, 很多系统还提供了各种人机接口命令(CLI)用来获取系统的配置、告警和状态等信息, 这些信息也是以一定的文本格式输出. 通过对这些信息的充分分析和评估, 可以有效地帮助用户对系统目前的运行状况譬如安全性^[1]、负荷信息^[2]等进行深度了解并采取必要的优化措施. 许多科研技术人员在这方面也做了很多研究工作^[3,4], 并开发了ELK^[5-8]等类似的系统文本日志处理框架, 但这些研究或框架在功能上普遍缺乏通用性研究, 特别是缺乏通用的可配置的日志评估功能及对微服务的支持. 本文基于该需求, 设计了一种系统日志的通用性评估方案, 该方案包括架构的设计和系统日志通用性评估模型的设计. 在架构设计上, 采用了微服务架构, 实现是基于Spring Boot/Spring Cloud^[9]来实现, 部署支持Docker Stack方式和K8S方式部署. 在系统日志通用性评估模型方面, 采用了引擎与规则分离的原则, 来实现评估的通用性.

1 基于Spring Boot/Spring Cloud的系统评估框架的设计

2014 年“微服务架构”^[10,11]被提出后, 其思想经由 Martin Fowler 阐述后, 在近几年持续受到重视, 理论与相关实践都不断发展, 目前它已经成为了主流软件架构模式. 微服务将一个大的系统提供的功能分解成了许多小的服务, 这些小的服务都是独立实现、这些小的服务之间一般采用轻量级的通信协议, 小的服务之间是松耦合且独立部署, 这些小的服务就被称为微服务. 微服务架构具有如下的一些特点:

(1)每个服务足够内聚, 足够小, 代码容易理解;

(2)服务独立测试、部署、升级、发布;

(3)每个服务可以各自进行扩展, 每个服务可以根据自己的需要部署到合适的硬件服务器上;

(4)容易扩大开发团队, 可以针对每个服务(service)组件开发团队;

(5)提高容错性(fault isolation), 一个服务的内存泄露并不会让整个系统瘫痪.

1.1 评估框架总体架构设计

在图1总体架构中, 控制节点和工作节点在系统微服务能力上完全相同, 区别在于启用的微服务能力不一样. 工作节点开启的微服务能力包括日志的上传、集成性检查、解析、组织入库, 而控制节点则负责汇总各个工作节点的数据, 并根据配置的健康检查规则对数据进行健康检查, 同时根据评估规则生成项目的评估报告

1.2 节点上微服务架构的设计

日志的分析一般的流程是收集、解析、入库和分析, 节点上微服务构架如图2, 也是基于该流程来设计的, 除此之外, 本框架中还加入了评估功能.

在图2的微服务架构中, 支撑服务层包括 MariaDB, ES和ActiveMQ, ES用作原始log分析后的存储, MariaDB用作组织后的数据的存储, ActiveMQ用作前后端以及基础服务层之间的消息通信的中间件. 基础服务的各个部分都作为独立的服务来运行, 这些服务都是基于Spring Boot/Spring Cloud框架来开发. 利用Spring Boot/Spring Cloud, 不但可以方便地实现微服务的开发, 而且还能方便地集成对MariaDB, ES, ActiveMQ 等服务的访问.

2 系统日志通用性评估模型设计

方案中设计了两种模型.

(1)通用日志分析模型

日志分析模型拆分成了分析引擎和分析规则, 通过在分析规则中配置数据源来实现分析引擎与数据源的松耦合, 分析引擎不针对某个特定的数据, 只根据分析规则来对数据信息进行处理.

(2)通用日志评估模型

日志评估模型拆分成了评估引擎和评估规则, 通过在评估规则中配置数据源来实现分析引擎与数据源的松耦合, 评估引擎不针对某个特定的数据, 只根据评估规则来对数据信息进行处理.

通用日志分析模型包括分析引擎和分析规则, 在模型中, 分析引擎通过分析分析规则来实现对系统日志的分析检查.

2.1 通用日志分析模型

(1)模型工作的前置条件

1)被分析数据存放在关系数据表中;

2)每张数据表需要一个额外的字段来存储分析结果, 这里暂命名为“checkrs”.

(2) 相关定义

1)数据集: 将要被检查的同一张关系数据表中的所有数据称为一个数据集. 假设数据集有 $ l $ 列 $ m $ 行, 其表示如下:

$ \left\{ \begin{gathered} D = \{ {d_1},{d_2}, \cdots ,{d_l}\} = \left[ {\begin{array}{*{20}{c}} {{d_{1,1}}}& \cdots &{{d_{1,l}}} \\ \vdots & \ddots & \vdots \\ {{d_{m,1}}}& \cdots &{{d_{m,l}}} \end{array}} \right] \hfill \\ {d_i} = \left[ {\begin{array}{*{20}{c}} {{d_{1,i}}} \\ \vdots \\ {{d_{m,i}}} \end{array}} \right],\;1 \le i \le l \hfill \\ \end{gathered} \right.$

2)有效数据集: 数据集 中具有对应检查规则的列的数据组成的数据集合. 假设有效数据集有 $ n $ 列, 其表示如下:

$ \left\{ \begin{gathered} V = \{ {v_1},v{}_2, \cdots ,{v_{n\} }} = \left[ {\begin{array}{*{20}{c}} {{v_{1,1}}}& \cdots &{{v_{1,n}}} \\ \vdots & \ddots & \vdots \\ {{v_{m,1}}}& \cdots &{{v_{m,n}}} \end{array}} \right] \hfill \\ v{}_i = \left[ {\begin{array}{*{20}{c}} {{v_{1,i}}} \\ \vdots \\ {{v_{m,i}}} \end{array}} \right],\;{v_i} \in D,\;1 \le i \le n \hfill \\ \end{gathered} \right.$

3)分析规则集: 用来分析有效数据集V的规则的集合, 规则集里规则的列数必须与有效数据集V的列数一致. 假设分析规则集有p行规则, 其表示如下:

$ \left\{ \begin{array}{l}R=\{{r}_{1},{r}_{2} \cdots ,{r}_{n})=\left[\begin{array}{ccc}{r}_{1,1}& \cdots & {r}_{1,n}\\ \vdots & \ddots & \vdots \\ {r}_{p,1}& \cdots & {r}_{p,n}\end{array}\right]\\ {r}_{i}=\left[\begin{array}{c}{r}_{1,i}\\ \vdots \\ {r}_{p,i}\end{array}\right],\;1\le i\le n\end{array} \right. $

4)分析结果标记集: 当有效数据 ${v_{j,i}}\;(1 \le i \le n, $ $ 1 \le j \le p)$ 不能满足规则时输出的结果标记, 其中 $ {e_i} $ 与 $ {r_i} $ 一一对应, 其表示如下:

$ E = \{ {e_1},{e_2}, \cdots ,{e_n}\} $

(3)分析算法

分析算法见图3. 该算法中, 输入包含: 分析规则集、规则中关联的有效数据集、及对应的分析结果标记集, 输出为分析结果数组.

(4)分析规则的设计

在本模型中, 设计了4种分析规则.

第1种规则: 相等规则. 分析规则中配置数字或字符串, 分析引擎对有效数据与规则中配置的数据进行相等性判断;

第2种规则: 正则表达式规则. 规则以“! ”开始表示正则表达式规则, 分析规则中配置正则表达式, 分析引擎判断有效数据是否满足规则中提供的正则表达式;

第3种规则: 数字范围规则. 分析规则中包含数字范围, 输入方式为[X–Y], 表示数字在X与Y之间都是有效的. 例如规则“vlan[1–100]”, 那么vlan1,vlan2,…,vlan100都是合法的.

第4种规则: SQL条件规则. 规则中以“? ”开始表示SQL规则. 该规则以SQL的条件子句为分析规则. 例如: ”? F1>100 and F2=1000”,表1是一条分析规则的例子.

这条规则将对有效数据进行分析, 检查F1字段是否是字符串“SH”, 判断F2字段是否是数字, 判断F3字符串是否是vlan100或vlan101或…或vlan300, 判断F4字段是否大于100且小于200.

(5) 模型的实现例子

下面是一个对宽带网络用户利用率进行分析检查的例子. 数据集如表2, 有效数据集如表3, 分析规则集和分析结果标记如表4. 表4中第1行是对应的有效数据集中的字段名; 第2行是分析规则集; 第3行是分析结果标记集. 分析结果如表5. 通过检查, 发现用户的可利用带宽的配置都不正常, 分析结果见checkrs列中的结果标记.

2.2 通用日志评估模型

通用日志评估模型同样包括评估引擎和评估规则, 在模型中, 评估引擎同样通过评估规则来实现对日志的评估.

(1)相关定义和解释

数据集: 根据某个或某些特征组合在一起数据, 这些数据存储在多个关系数据表中. 其表示如下:

$ \left\{ \begin{gathered} D = \{ {t_1},{t_2}, \cdots ,{t_n}\} ,{t_i} = \{ {f_{{i_1}}},{f_{{i_2}}}, \cdots ,{f_{{i_m}}}\} \hfill \\ t{}_i \in D(1 \le i \le n) \hfill \\ \end{gathered}\right. $

其中, ${t_i}$ 为一张二维数据表的所有数据, ${f_j}({i_1} \le j \le {i_m})$ 为表 ${t_i}$ 中的一列数据.

评估规则: 一组用来对数据中的数据进行评估的规则. 其表示如下:

$ R = \{ {r_1},{r_2}, \cdots ,{r_k}\} $

其中, $ {r_i} $ 作用在指定表的指定列(字段)的数据上.

排除键值(EV): 数据评估的时候, 用来清洗被评估数据. 当被评估数据包含排除键值时, 那么该数据将被过滤掉. 在规则 中设置.

期望键值(KV): 被评估数据的期望值. 在规则 中设置.

评估权重(W): 该项占百分值评估的分值权重. 在规则 中设置.

有效数据: 如果被评估数据包含期望键值, 该数据即为有效数据.

负面数据: 如果被评估数据不包含期望键值, 该数据即为负面数据;

作用类型(PN): 配置被评估对象的数据取值为期望键值时, 获取的评估分值是正还是负. 在规则中设置.

有效范围(vScope): 有效策略为计数统计策略和平均值策略的时候, 统计得到的数据计算评估得分时的判断依据.

评估方法策略(M): 本模型中定义了3种评估策略:

• 百分占比策略: 计算有效数据数占总数(有效数据加负面数据)的百分比, 然后根据计算出的百分比来计算该项的评估得分.

• 计数统计策略: 按照指定条件分组并统计各分组中不同数据出现的次数. 并把得到的这些次数与某个设定范围(有效范围vScope)进行比较来计算该项的评估得分.

• 平均值策略: 按照指定条件分组并统计各分组中数据的平均值. 并把得到的这些平均值与某个设定范围(有效范围vScope)进行比较来计算该项的评估得分.

评估方法策略在规则中设置.

(2)评估算法

评估算法见图4. 该算法中, 输入包含: 评估规则 及规则中关联的数据, 输出为评估得分数组score.

(3)模型的实现例子

1)规则的定义

由于规则数百条, 表6是小部分规则例子.

2) 评估结果

根据数据得到的评估结果如表7所示, 见score (得分)列.

3 基于微服务的系统日志通用性评估方案的PON网络健康检查系统的实现

PON是一种典型的无源光纤网络, 是指 (光配线网中) 不含有任何电子器件及电子电源, ODN全部由光分路器 (splitter) 等无源器件组成, 不需要贵重的有源电子设备. 一个无源光网络包括一个安装于中心控制站的光线路终端 (OLT), 以及一批配套的安装于用户场所的光网络单元 (ONUs) 目前PON网络作为接入网在全球得到了广泛的应用, 小的PON接入网可能只有几十台OLT, 大的可能有数万甚至数十万台OLT, ONU的数量相对于OLT来说, 更是成倍甚至数十倍, 如何维护和管理这些OLT和ONU, 特别如何对正在服务的PON网络进行一个健康情况的评估并进行优化就变得特别重要.

基于本文介绍的基于微服务的系统日志通用性评估方案, 作者等开发了一套PON网络健康检查系统, 目前该系统已经在多个PON网络的健康评估中得到了应用. 处理过的最小的网络只需要建立一个节点来处理, 该节点既是工作节点, 又是控制节点; 最大网络建立了7个工作节点, 1个控制节点来处理, 处理的日志约1 TB, 该PON网络有25 000多个OLT 上百万个ONT. 从日志开始检查, 分析到最后输出数百张图表及最终的评估报告, 总的耗时约7小时. 该系统在实际的项目中对PON网络的健康服务起到了非常重要的作用, 极大地提高了服务的效率, 得到了用户的高度评价. 图5为某外国电信运营商利用基于本文介绍的分析评估模型开发的系统进行网络评估得到的评估结论.

4 结论

本文介绍了一种系统日志的通用性评估方案, 该方案采用单控制节点/多工作节点模式, 扩展灵活, 支持TB级的系统日志数据分析和评估; 相对于当前流行的 ELK等方案, 设计了配置驱动的评估方法, 具有很好的通用性, 同时该方案方便定制性的二次开发. 基于该方案而实现的PON网络健康检查评估系统在实际中也得到了很好的应用, 极大地提升了服务的效率. 该方案对于今后需要进行系统日志类信息分析和评估的工作人员具有非常好的参考和借鉴作用.