基于系统日志搭建高质量运维服务平台的分析

王小平

(工业和信息化部电子第五研究所，广东广州 510610)

0 引言

系统日志是记录系统中软件 (设备)和系统问题的信息，同时其还可以监视系统、硬件在运行中发生的事件。维护人员可以通过它来检查错误发生的时间和原因，以便于快速地解决问题。但是，随着系统 (设备)的增加，日志量也日益增加，采用人工的方式逐条检查已经远远满足不了运维的需求。此时便需要使用一套先进的、高质量的方法对日志进行综合分析、即时展示和监测预警。因此，本文就如何搭建一套能帮助运维人员快速地发现系统 (设备)的问题的运维平台给出了应用分析，具有十分重要的意义。

1 系统日志的概述

系统日志是指操作系统、应用系统及其设备产生的日志信息。专业来讲，系统日志也被称为“Syslog”，是一种工业标准的协议，用来记录设备的日志，其是美国加州大学伯克利软件分布研究中心 (BSD)在实施TCP/IP系统的过程中开发的。通过对系统的配置，可以实现运行Syslog协议的机器之间的通信。系统日志可以独立地运行，也可以通过搭建日志服务器来实现集中存储。为了更好地对日志进行区分管理，在标准协议中我们将日志分为8个级别，分别是1级，Emergency：紧急情况，需要立即通知技术人员；2级，Alert：应该被立即改正的问题；3级，Critical：重要情况；4级，Error：错误，不是非常紧急；5级，Warning：警告信息，不是错误；6级，Notice：不是错误情况，也不需要立即处理；7级，Informational：情报信息，正常的系统消息；8级，Debug：系统调试信息。

2 系统日志服务的搭建

本章重点介绍的是如何实现集中搭建日志存储服务，即利用Syslog协议集中收集日志信息存储在本地服务器上。这里将日志收集过程的处理分为日志收集服务端、客户端和日志存储的过程3个部分，如图1所示。

图1 日志收集过程的处理

2.1 搭建系统日志服务端

目前市面上已有专用的日志审计系统，可以用于集中收集系统 (设备)的日志信息。但这类设备不对外开放数据提取接口服务，也就是不可以对数据进行二次加工处理，我们这里需要对数据进行二次处理和展示，因此就需要自行搭建日志服务端。当然现在也有很多成熟的日志收集服务软件，例如：Kiwi Syslog、Linux syslog和Syslog Watcher等，它们都可以很好地支持日志的收集服务。但中国市场上各类系统 (设备)厂家众多，他们的日志发送编码和格式各不相同，如果使用这类软件来接收日志，会出现其中有一部分数据格式错误、内容乱码等问题。这样会造成无法对这部分的数据进行处理分析等问题，因此，需要自行设计日志接收服务端，在接收数据的同时对数据流的格式和编码进行判断处理，保障后期数据在使用过程中的有效性。如前所述系统日志也是一种工业标准协议，通常信息都是通过UDP的形式从客户机发送到接收服务器上的，因而我们只需要建立一个UDP网络服务，使用514端口，用于接收日志即可。在接收数据后对数据流进行编码处理，同时初步判断编码和内容是否标准；若发现有异，则需要重新对数据流进行编码直到正常为止。

2.2 配置系统日志收集客户端

服务端的数据都是由客户端发送来的，需要将客户端进行一一配置。当然日志的产生和发送都需要遵循Syslog标准，这样才能统一收集和配置发送的日志信息。目前国内系统 (设备)研发厂家都遵循这个标准，因此都满足我们发送配置的需要，只是由于系统 (设备)的种类和厂家不一致，因而配置的方式也会有所不同。

a)在操作系统层面，Windows系列中需要使用一个转换工具 “Evtsys”来对系统日志进行转换处理后再发送到指定的服务器上；在Linux系列上可以使用 “rsyslog”来配置日志的发送信息。

b)在应用系统层面，可以配置应用系统记录日志的发送信息。

c)在网络设备层面，可以启动日志记录机制，配置日志发送信息。

d)在安全设备层面，可以通过厂家提供的日志标准服务协议来设置。

e)在物联设备层面，可以通过对物联设备的基础配置来进行设置。

2.3 系统日志存储的过程

搭建好日志收集服务端和配置好日志发送端后并不是就完成了对日志的收集，只是初步地完成了日志的传输过程。为了能对日志进行二次使用，我们必须对日志进行储存才算是完成了日志服务的搭建，储存分为即时数据储存和历史数据储存两个部分内容。

即时数据是指当前还未处理的数据。即时数据储存过程就是指将数据发送给数据处理平台，处理平台完成处理后再反馈处理结果，此时即时数据开始转变为历史数据。

历史数据是指当前分析完成后的数据。历史数据可根据业务需求来选择保存时间 (如3年)，历史数据的储存可以按时间节点进行分量储存 (如年/月/日/时/分)，储存格式为TXT，编码方式为ANSI。

3 高质量运维服务平台建设分析

通常来讲，运维服务是指对运行的服务 (软件、硬件)进行实时的监控，随时发现运行的异常情况，对服务发生的任何异常进行及时的处理，尽可能地避免问题扩大而终止服务。一般运维都是通过人工对系统 (设备)进行巡检，查看系统 (设备)是否处于正常工作状态。此方法只能检查出系统 (设备)当前的总体运行状态，不能查出一些潜在内部的错误和报警信息。例如：操作系统记录内存不足、应用系统记录磁盘空间不够、网络设备报告端口供电异常、安全设备报告资源不足和物联设备报告耗材损耗等，这些异常的信息通过常规的检查维护都不会体现出来。这时，利用系统日志来搭建一个高质量的运维平台则能够很好地解决上述问题，运维者可以从界面中随时掌握系统 (设备)的健康信息，还可以与段信平台、微信公众号联动对接，让运维人员随时随地都可以收到预警信息，达到高质量运维服务的效果。

运维服务平台建设分日志处理、日志分析、动态展示及系统 (设备)预警、第三方应用4个部分，基础架构如图2所示。

图2 运维服务平台的基础架构

3.1 日志处理

平台在接收到日志信息后先要经过初步的处理才可以进入分析阶段。在日志处理环节，首先，对日志的格式进行统一，以便在接下来的其他处理环节减少日志处理时间；其次，对数据进行初步的分类，分类可依照日志的8个级别进行处理；第三，分类完成后再对数据进行计量操作，用于对数据的统计；第四，根据分类和计量结果来计算日志分析需要的线程数量；最后，进行日志分析的任务分配。

3.1.1 格式处理

格式处理即对日志内容进行统一处理，包括内容编码统一和字段内容统一。编码可以理解为对文字进行统一编码，处理后显示为非乱码格式；字段内容统一即把日志解析成为我们需要的字段，解析后的字段包括：地址、名称、时间、级别和内容。

3.1.2 数据分类

数据分类是指对数据级别进行分门别类，包括级别分类和异常内容分类，初步分类可以有效地提高后期数据处理的能力。级别分类是按日志的八大级别进行分类，其中第八级别 (Debug)我们可以只做计量不做分析处理；异常内容分类是对接收到的非正常日志内容信息进行区分，我们把它归入第九类，这类日志为不可分析的信息，所以也只做计量不做分析处理。

3.1.3 数据计量

数据计量是将日志数据进行计量统计的处理环节，是多线程量计算的数据来源依据，同时也是为了方便维护人员后期做交叉对比统计分析。这里的计量包括分类计量和后期的数据分析计量；前者只需要对分好类别的数据做计量统计即可；后者则是对分析后的数据再次细分计量。

3.1.4 多线程量计算

利用当前分类数据量来计算程序分析数据的能力，算出同一时间需要分析完成日志信息的线程数量即是多线程量计算。多线程量计算是解决日志分析吞吐量的一个关键因素，每秒对日志的分析达到的最短时间除了与对分析程序的优化有关外，还要结合处理器最大的处理能力，再合理地分配多个线程进行数据分析，充分地发挥平台对日志的处理效率。

3.1.5 任务分配

任务分配是将日志分配给日志分析处理的过程，是日志分析的起始点。当前环节在接收到日志信息后判断目前已分配的线程数，结合线程的运行状态分配新的数据给另一个线程。若全部线程还未运行完成，则反馈信息给多线程量计算处理环节，检测硬件资源是否可以支撑更多的线程来分析，如果支持则可以增加线程数据量，如果不支持则持续地等待，同时将该信息反馈给日志分析过程，用于提示用户日志信息处理的能力情况。

到这里，整个日志处理环节就形成了闭环，为下一个分析阶段做好了充分的准备，也为运维平台对日志的处理分析能力打下了基础。

3.2 日志分析

日志分析是平台经过日志处理后再按分类要求提取有用的信息，形成结论后对数据加以详细研究和概况总结的一个过程，这一过程也是高质量运维管理体系支持的过程。数据分析可以帮助维护者作出判断，以便于采取适当的行为。这里我们将日志分析分为6类。

3.2.1 可用状态分析

系统 (设备)的可用状态即是系统 (设备)是否可使用的状态，定义为5 min的状态频率判断。首先，在20 min内查询系统 (设备)是否有发生过日志信息，若未发生则需要使用5 min的状态判断频率去获取系统 (设备)的在线状态；有发生则跳过检查。检查完成后记录设备的最后更新状态，为展示预警做好数据准备。

3.2.2 紧急事件分析

紧急事件是指系统 (设备)发生的急需要处理的事件，若不处理则会导致系统 (设备)不可使用，也指系统 (设备)本身发生的事件，例如：故障、资源不足等。我们需要对日志进行分析，过滤排除掉这类信息，并将其记录、推送至紧急事件处理表中。

3.2.3 错误提示分析

错误类信息是指系统 (设备)发生的常规异常信息，这类信息在短时间内不能反映系统 (设备)的健康程度，但是可以根据这类信息来反馈系统(设备)在接下来运行的一段时间内有可能发生的故障。通过错误提示发生的频率来判断错误有可能发生的时间点，运维者就可以提前做好维护准备，不用担心事件发生的突然性。

3.2.4 告警分析

告警分析主要是用来分析提取出系统 (设备)目前发生的比较紧要的事件信息。通常告警信息包括状态、紧急事件两大类，这里作为整合的一个告警分析功能是用于界面展示提示。

3.2.5 黑客攻击分析

系统 (设备)最大的威胁来自外界的黑客攻击，维护者需要随时掌握系统 (设备)被攻击的状态信息，随时做好应急处理措施。平台通过对部分设备的日志进行分析后可以掌握攻击者的攻击信息和攻击目录信息，从而对症做好保护措施。

3.2.6 异常利用分析

系统 (设备)的异常主要是维护异常，平台结合维护者对系统 (设备)的在线维护产生的登录日志进行分析，非维护期间产生的登录信息则是异常行为，系统会及时地记录此类异常行为并推送给展示平台用于告警维护。

3.3 动态展示及系统 （设备）预警

从日志收集到日志处理再到日志分析，这一切的准备都是为了日志展示和预警，展示是为了更加直观地体现系统 (设备)的运行情况，预警是为了及时地掌握系统 (设备)事件信息，都是为了辅助和提高维护者对系统 (设备)的运维能力。

3.3.1 系统 (设备)安全展示

系统 (设备)安全是指系统 (设备)自身安全和运行安全，主要反馈系统 (设备)被攻击的频率和运行环境的安全。互联网+时代的到来，引来了来自各界的各类攻击，安全防护已成为了建设和监控的重点，因此我们需要随时掌握系统 (设备)的攻击安全状态，并提前做好防范，以保障系统 (设备)的安全运行。

3.3.2 应用状态展示

应用状态是指系统 (设备)的可运行状态，这里将其分为可用和停用两类。设置轮播巡视界面展示所有需要监控对象的运行状态，通过这种简单直接的方式可以更好地对系统 (设备)进行监控。

3.3.3 运行健康展示

运行健康是指系统 (设备)发生综合性事件的频率，包括带故障运行时间、离线次数。系统 (设备)运行健康的程度直接体现了系统 (设备)的运行健康情况，同时也可以反映出维护者对其运维的能力。

3.3.4 预警

预警是指对已整合的资源进行分析，获取危险源、隐患和运行状况信息，进行监测监控，分析风险隐患，预防潜在危害。平台除了要有展示功能外，最重要的还是要有预警提示功能，遇到重要信息时需要告警，将有故障或即将要发生故障的系统(设备)及时地推送出来，让运维者做好提取准备，随时处理告警信息。

3.4 第三方应用

要搭建一个高质量的运维平台，不仅需要依靠系统自身的建设，还要结合目前市面上最常用的通讯工具和手段来配套运行。当运维人员在现场办公时，我们可以利用这个平台直观地对系统 (设备)进行监管，当我们离开工作场所时则可以通过移动终端工具来掌握系统 (设备)的运行状态，遇到紧急事件时也可及时地收到信息并找到处理方法。

3.4.1 APP应用

APP应用是在智能化终端发展路上必要的产物，是手机、平板必不可缺的应用。在平台建设中可独立地研发出APP展示预警功能应用，移植平台本身的展示功能，通过专用APP可以更专业地为运维人员提供运维服务。

3.4.2 微信应用

手机微信作为最近几年最火、最流行、运用得最广泛的网络社交工具，当然也需要配套使用，绑定运维人员的微信账号，利用微信的 “企业微信”和 “微信小程序”功能可更方便地提供信息通知和对事件处理的能力。

3.4.3 短信应用

笔者认为手机短信通知是目前最简单、最粗暴、最有效的功能应用，作为一种安全、可靠的信息通知手段，在未来的十几年内都具有核心价值。我们可以将一级最重要的信息推送给运维人员，以告知当前急需处理的事件。

4 结束语

基于系统日志搭建高质量运维服务平台是为了能够掌握所运维的系统 (设备)的运行状态，提供线上预警方式，是运维服务能力的重要体现。在实际运维中，还可以通过其他手段来保障系统 (设备)的正常运行。但在信息社会快速发展的今天，应该正确地认识信息手段带给我们的影响。通过收集日志信息来搭建的运维服务平台是高效的、也是高质量的，其可以提高运维能力及带动运维服务发展，为支撑互联网+的发展服务打下坚实的基础。