本文整理自日志易产品副总裁饶琛琳，受邀分享的“IT运维数据分析及数据管理系统设计概要”主题演讲。

想要获取全部视频内容，请扫描图上二维码添加助理小易微信（rizhiyi2014），备注“数据分析驱动的IT运维”。

大家好，今天分享IT运维数据体系建设相关的主题，主要是介绍一下，在IT环境内，运维工作相当于是整个IT系统建设过程以及建设完成之后，始终需要重视的一项工作。

01 畅谈运维数据

运维数据

在早期的基础运维工作中，运维工程师普遍需要了解Linux系统管理、Windows系统管理或Cisco相关知识即可。那么，在基础运维之上，要如何体现IT运维的真实价值？如何实现更复杂的运维业务需求？数据分析在这方面是大有可为的，数据分析的相关技能同时也可以帮助大家更加高效优质地完成IT运维工作，实现企业与个人发展层面的双重提升。

首先，我们来了解什么是运维数据，运维数据可以用来做什么？

如图一，谷歌Dapper系统开发者、LightStep创始人Daniel Spoonhower表达了自己对可观测性三大支柱的理解。近几年，这张图在IT运维领域广为流传，它比较直观地展示了运维数据到底包含哪些，这些数据分别是什么层次以及针对不同层次的数据又有何要求。

如图我们可以看到，可观测性主要涉及三类数据，指标、日志、调用链，它们各有区分，又部分融合。

举个例子，当我们把日志进行一定的聚合之后，它可能会成为指标；每一条日志信息的具体记录，又可能成为调用链，之后还可以被继续提取成指标。这三者互相之间，又存在从属定向。

谈到数据，有一个必须要强调的问题就是量级。

我们经常提到大数据领域的4V（如图二），其实逻辑就是从不同维度去解释它为什么是“大”数据，运维数据也同样有“大小”的差异。

我们继续来看图一，纵坐标越往下，表示数据量越大；纵坐标最上侧是指标，相对来说数据量比较小。站在系统管理者的角度，一般会部署监控系统、网管系统等，它们都会产生指标，但因为数据量较小，普遍不会考虑针对它们做后续的数据处理。因为，一般只有在数据量足够大的情况下，才会有单独建造数据平台的考量。运维数据同理，一般有日志数据、调用链数据的情况下，由于数据量足够大，才会考虑到所谓运维数据分析这个层面。

数据量最大的当属日志数据，大家可能都见过，但普遍不会思考：什么样的日志数据才属于优质数据？才是值得分析的数据？

优质的运维数据

我们看图三，这里展示了优质的日志数据应该包括哪些内容。

坦白说，确实有很多企业，由于业务开发人员不熟悉或者不够重视日志数据等原因，打印的日志数据比较随意，无法体现出业务价值。

我们认为，优质的日志数据是一段完整的描述，也就是说它的自描述性很好。

比如说，它能够表达清楚这个日志是谁打印的、出自哪里、为什么会出现这个日志、它所代表的这件事的重要程度如何、这件事是否涉及第三方、事件最后的结果走向如何等信息。

在这个前提下，大家可以回想一下，之前见过的像Syslog等经过十几年沉淀下来的，被行业认可、有价值、应用长久的日志数据，是否都包含类似信息。后边讲到具体数据分析的时候，包括谈到机器学习，其实就是利用了日志数据的这些特性。

简单来讲，日志数据已经把某些事件的主谓宾非常细致地记录了下来，我们则是利用类似于文本分析、自然语言处理等技术，去分析这些日志。当然，这一切的前提条件也正是因为，一条完整优质的日志是可以把事件描述得详尽而又清晰的。

刚才我们提到，调用链数据量较大，那这里边都包括什么（见图四）？

调用链的关注面更加细致，主要是展示在分布式系统下，在海量集群中，某一个业务请求都经过了哪些模块或者服务器。所以，调用链数据的关键是它标记了每一个请求，这些请求都拥有请求的唯一ID，当这些请求经过不同模块，将会产生各自模块的ID和这个模块上下游的父子关系ID。

综上，虽然表面上看起来都是系统打印的一行行的日志，但是和我们狭义上认为的运维日志数据是有一些区别的。

运维数据的作用

得到了有价值的数据之后，我们可以用它们来做什么呢？在这里可以给大家举几个例子。

网站业务分析

以网站访问日志为数据源，可以实现网站用户分布、设备类型、请求数、错误数、首屏耗时、用户体验等方面的统计分析。

我相信，所有运维从业者，包括从10年前就已经在做LAMP架构的运维工程师，都应该了解访问日志，这类日志中大概有10到30个字段信息。

本质上来说，如何能确定网站业务正常运行呢？答案是通过业务分析来判定。有的人说，我网站的服务器没有宕机，我是否可以认定网站就是正常运转的。事实并非如此，服务器没挂和服务器运行得好，这中间差别是非常大的。

一个网站的运维人员，如果能够拿出各种来源的访问情况，比如来自北京、上海、iOS、安卓、PC端、联通、教育网等等各类来源的指标数据，甚至包括这些来源访客打开首屏的耗时、滚动加载页面的详细信息等，那这个网站的运维价值将会受到公司更多的关注，因为无论是业务端还是研发端的同事，都能通过这些统计分析结论，获取到人工无法实现但同时对整个网站运营又十分重要的信息，进而促使研发与运维部门共同合作，合力提升网站的整体业务水平。

这就是数据的价值体现。

安全分析

以系统日志、网络日志、安全审计日志为数据源，可以实现IT资产和不同漏扫情报等数据信息的关联分析、告警归并、自动化编排和响应处置。

这里涉及到的运维数据分类会有不同。

普遍来说，安全设备提供的日志是基于“宁滥勿缺”的宗旨，它们的设计理念是不漏报任意一条，因此可能会产生非常多的错报。这是由于每一个安全设备的开发厂商，只能站在自己的产品角度去考量设计，并不会过多考虑其他安全设备的情况。

作为运维分析人员，我们要从大局出发，将这些信息从不同的角度进行汇总，再归纳总结、扬长避短，将这些漏扫、安全防火墙、应用防火墙，甚至是相关的业务数据统一管理对比，通过最终的关联分析，将大量不必要传送到人员层面的信息过滤掉。一般情况下，如果没有实现这样的关联分析，单纯看安全设备输出的信息，可能一天就有几十万条告警，已经完全超出人为能够处理的范畴了。针对这些海量告警，我们也需要通过关联分析提炼出真正有意义的告警信息，然后考虑进行编排和响应。

测试分析

以自动化测试日志、代码变更打包日志为数据源，可以实现不同版本下代码变更和自动化测试日志的关联对比、异常跟踪等。

以自动化测试日志、代码变更、打包的系统日志做数据源，我们可以提供不同版本下代码变更的版本号或函数，与对应的自动化测试日志进行关联分析和对比，包括测试未通过时的异常跟踪情况等信息的分析和对比。这样，测试和研发部门实现联动，能够更加快速地修复Bug，完成版本更新。

这其实也是DevOps领域的一个新趋势，简单来说，我们不仅能够提升发布系统效能，还能够通过运维层面的日志分析手段来加快研发部门的相关任务进度，最终整个DevOps的流程与效率实现显著提升。

用户行为分析

以访问日志、前端、SDK埋点日志为数据源，可以实现用户留存分析、交易路径分析、页面热力分析等，这同时也是增长黑客领域新生的、最重要的技术手段。虽然从商业角度来看，数据价值的实现方向有所不同，但基本都是依赖运维数据分析技术来实现的。

基础设施分析

以系统日志、堡垒机日志为数据源，可以实现内网IT用户行为监控、系统和 AD域关键事件监控和趋势分析，能够直接满足基础的等级保护要求。

02 日志系统规划

在提到日志系统的规划时，业内有一些经典理论是可以借鉴参考的。

著名的Marcus Ranum日志法则

Marcus Ranum是世界知名的安全专家，也是世界上第一款IDS产品的设计者，被公认为是防火墙之父。他在最开始设计防火墙产品的时候，就已经指出产品要以日志的方式来打印，还需要考虑如何管理日志。

由此，他制定了以下几个原则：

• 收集日志数据的数量绝不能超过你觉得可能使用的数量

个人理解是要做到言之有物，即打印输出的信息一定要有价值。这里也与我们刚开始提到的“什么样的日志才是优质日志”相呼应。

• 无趣事件发生的次数正是我们所感兴趣的

在考量数据分析时，这一条是我认为特别重要的一条，虽然看起来概念很基础，但却是我们日志易企业内部经常强调的一点。

简单来说，所有运维数据分析产品的最顶层设计，肯定有一个事件趋势图，这同时也是Ranum日志法则提炼出的最重要的一点。举个例子，即使是内容为“无异常”的日志，如果每天能够打印一千次，甚至是一万次，它就变成了我们值得关注的信息。为什么之前一天打印一千次，而今天却打印了两万次？这说明仍有问题存在，我们需要去关注并检查问题详情。

所以，“次数”可以说是日志分析的起点。

• 除了与第一法则冲突的情况之外，尽可能收集所有数据

这一条不仅仅局限于设计层面的思考，国家已经出台很多法律法规，也有相关的明确要求，例如《网络安全法》、《数据安全法》、《个人信息保护法》、等保2.0等。尤其在金融行业，某些金融机构按照相关法规要求，需要留存日志长达6个月以上，券商机构甚至要求日志留存长达12个月到18个月。

显然，针对企业是否应该全面收集、留存日志数据，国家层面已经给出了指导方向。

• 如果没有实时系统管理员，实时性便无关紧要

日志常见错误用法

• 沿用的默认配置是不打印日志

这显然是不应该的。

一旦系统出现问题，运维基本是全瞎全盲的状态。所以，我们运维工程师在配置所有应用时，必做事项中一定需要有“检查打印日志”这一条的。

• 非重大故障不看日志

这一条主要是强调，日志的价值不仅仅体现在运维出故障的时候。数据分析同理，不是只有在故障已经发生，才需要去做分析求结论，除非是针对性的根因分析或故障分析。在未发生重大故障时，我们也应该通过一些分析手段，从海量日志中提炼出那些能够体现业务价值的日志分析结论来，做到防患于未然，事前防范永远好过事后填坑。

• 日志留存时间太短

这一点可以参照相关法规要求，直接作为企业数据管理指导方针。

• 先给日志排优先级再局部收集
• 不看应用程序日志
• 只搜索已知的故障关键字

在已知的关键字都搜索完成或者运维人员不知道怎么搜索的情况下，我们就需要考虑，如何利用技术手段发现一些未知的故障关键字，这个后边会介绍。

日志管理系统规划落地

针对这一部分内容，我想额外强调一点，就是在设计技术架构之前，一定要做好数据层面的规划，包括日志级别、跟流程的关系以及需要提前完成的元数据管理，为后续的数据分析作支撑。

这里总结几点考量内容：

日志级别、留存、元数据处理

日志级别常见于Syslog和Log4j两种日志记录方式中，二者大同小异。当然，如果存在其他库的日志，运维工程师也应该督促研发同事，建立公司内部的日志数据规范，这属于比较基础的数据管理要求了。

Syslog中除了日志级别以外，还约定了一系列的元数据（见图十），同时也再一次呼应了我们从开始就强调的“优质日志”应该包括的信息，这些是系统管理领域几十年间沉淀下来的经验总结，非常值得借鉴，能够帮助企业做到有备无患。

开源的日志采集Agent种类繁多，逻辑相对简单。图十一是我们日志易做的一些主流产品的性能对比。通过对比我们发现，日志采集工具的性能表现大致和编程语言的选择相关，但在产品功能实现、自我维护方面，各家的差别较大。

针对日志采集选型，我们建议主要关注功能和运行资源消耗，因为一般日志采集需要和实际业务的应用运行在同一台服务器上，采集占用的资源如果超过预期，实际业务运行很可能会受到影响。

日志清洗、关联选型

日志是一段描述性的信息，这一点与看图说话写小作文是类似的逻辑。

鉴于日志非结构化的特点，日志清洗比大数据体系里的数据清洗要省略一些内容，较少涉及元数据的血缘追踪、数据缺失和质量监控等。日志的元数据是相对稳定的，不存在转换的过程，所以血缘追踪不太适用。打印出来的日志，本身我们就无法知晓它的结构，也无法判断它是否存在信息缺失，最多只能判断是否存在重复的情况。

所以，日志清洗的选型主要关注正则表达式解析等功能、集群性能、UI交互便利性方面。

如图十三，例举了一些常见格式的日志清洗。

对于基础设施层、应用中间件层而言，日志格式通常有比较明确的配置参数，可以对照进行清洗，方便快捷；而对于业务层的日志，则非常依赖代码开发者的自身素养，清洗难度较高，这也是为什么运维工程师和研发工程师需要配合的原因。

我确实见过一些企业的日志，里边全是编码，研发人员有自用的数据字典，然后打印日志的时候也只打印编码，这时就非常需要运维与研发的密切配合，至少这个数据字典运维人员肯定是需要有的。

固定分析场景下的预聚合、上卷

接下来就谈到入库的阶段。

根据日志中的关键字段，进行日志数量趋势的统计和展示，是日志分析的一个主要场景（见图十四）。

对于格式相对固定的日志分析，比如我们刚提到，运维工程师最常见的访问日志，这类日志的常见分析场景普遍比较固定，比如状态码、访问来源等分析。我们可以通过预聚合（Rollup）的方式，在流式入库之前把统计点提前准备好，将日志转换为指标，后续指标查询性能将得到大幅提升。

存储的选择

我们要根据数据量规模、查询时效性要求等，对比选择合适的存储方案。有一点我是比较认同的，就是世上没有万能药。

分布式系统本身的运维是需要成本的，不管如何选型，在数据量大的基础上，都是需要投入专人来维护的。我们采用预聚合的方式，也是为了优化运维分析，以实现降本增效。

比如，谈到数据提取、清洗这件事情到底是在入库前做还是在入库之后进行呢？

业内有两种公认的方式，即所谓的Schema On Write和Schema On Read，也就是ETL与ELT。本质上，这两种方式就是时间与空间的衡量交换（见图十五）。

针对指标数据的存储选型，选择相对较多（见图十六）。

在过去，指标数据存储通常会跟随监控系统的选型一起决定。举个例子，有的企业选择了Nagios系统，则不需要再考虑这个Nagios系统的指标需要怎么存储了。但现在，由于运维数据分析已经是针对不同类型数据的综合分析，我们更侧重于把指标和日志、调用链等关联起来分析。所以，能否在生态、可视化层面共存就成为新的考量选项。

03 数据模型与分析

在完成基础的技术选型之后，我们就需要考虑如何在技术平台上完成相关分析，这就涉及到如何构建数据模型。

如何构建数据模型

如何去实现不同数据类型之间的关联分析或多源分析呢？

通常，我们需要构建一个相对稳定，且命名、类型一致的数据模型，充分发挥模型的适用性。

很多运维厂商已经在组建自己的数据模型集合，宗旨是将来自不同数据源、经历过不同清洗或命名不同的日志进行统一化，或者说标准化。比如，访问日志经过不同的反向代理之后，可能命名全都变了，但实际上改变前后的数据依旧在描述同一个事件。

这时，我们就需要一套数据模型来规范这些数据。

数据模型通常包括模型分类层级、数据范围约束、维度类型字段、数值类型字段、字段转换等（见图十七）。一般而言，基础设施、应用、中间件等层面的数据模型都有较好的约束效果。

成功构建数据模型之后，即使是遇到非结构化的日志数据，也可以实现高效便捷的多维可视化分析。

日志数据的分析可视化

数据模型根据维度、数值、时间等字段的类型区分，可以自动推荐合适的可视化方案。在数据模型中，我们可以约定好能够实现维度分析或数据分析的字段。

构建了数据模型之后，很多基础的数据分析是可以通过分析软件来实现的。

指标数据的分析可视化

指标数据的分析相对简单，可基于分类、总分、同环比等方式进行对比分析。大多数情况下，都是以时间序列趋势图来呈现。

结构化数据的分析可视化

结构化数据的分析和可视化工具相对较多，几乎所有BI工具都可以归为此类。除了基础的统计分析，也可以尝试结合常规的机器学习等手段。从运维数据的特性出发，这里建议使用Superset、Jupyter等对大数据平台适配性较高的新型分析可视化软件。

统计分析入门知识分享

下面我们来聊一些运维分析中常见、有效、性价比较高的入门知识。

首先第一点，数据的频率、趋势是最关键的信息之一。作为运维工程师，一定要能够非常熟练地统计出各种数据的趋势，这是站在时间轴（纵向）角度来分析的经典方式；站在非时间轴（横向）角度来看，频数分布或者说占比分布也很重要。这是我们运维人员在做数据分析时，最基础、最常用且非常有效的入门知识。

基于以上两方面的分析，我们可以构建基线，比如同环比、3σ异常检测、Boxplot异常检测等，或者进一步结合机器学习等技术。

统计知识之同环比基线

同环比基线是最简单的动态基线，分为纵向的时序同环比基线和横向的分组内同比基线。

通常，在一个稳定的 IT 环境中（比如集群），指标数据应该与服务相同业务的其他设备指标及自身历史指标间保持稳定。

统计知识之3σ检测

自然界中，大量随机数据服从正态分布或可以转化为正态分布。在正态分布中，99.7%的数据集中在[μ±3σ]，这就是我们常说的3Sigma原则。

但是，我们在运维工作中碰到的绝大多数数据，往往不会直接服从正态分布，需要经过各种处理，比如去掉趋势、周期，剩下的残差部分可能服从正态分布。现实中，持续分解这些数据将耗费大量资源，一般我们会引入现成的持续分解库，或者是机器学习模型，自动化获取残差。

统计知识之Boxplot检测

四分位统计相对而言比较简单，对数据分布不敏感，是适用于典型非正态分布数据（比如请求耗时）的简便方案。根据敏感度需要，可以选择采用标准四分位或四分位与绝对均值偏差相结合的方法。

统计知识之经典机器学习算法

其实，有一些经典的机器学习算法是比较容易上手的，技术要求也较低。虽然近几年深度学习的概念热度很高，但并不代表只有深度学习才算做AI。我们可以采用KDE算法，对同比一周内相同时段的数据进行针对性建模，拟合最佳的数据分布，甚至可以根据工作日、休息日的特征，分别进行建模。

针对数据选择的范围，我以个人经验为例阐述一下。

一般而言，我们不会选择对一个“7天内所有响应耗时数据”去拟合一个总的数据分布，因为这个数据分布结果对任一部门几乎没有价值。比如说，针对一个网站的被访问时间数据，其中高峰点和非高峰点的数据差别是非常大的，我们最终还是需要考虑这些运维数据的特征，将同比一周或者一个月时间范围内相同时段的数据，单独进行拉取，进行针对性建模并拟合分布。这样得到的数据分布结果通常更具参考价值，这也是很多网站目前使用的统计分析方案。

搜索处理语言SPL（Search Processing Language）

SPL是日志分析产品的通用查询语言，类似关系型数据库的SQL。SPL语法模拟了运维人员在终端Shell上的命令行书写方式，起到了管道符传递的作用（见图二十四）。

04 日志与运维新趋势

可观测性概念

可观测性工程理念的传播，源自Twitter工程师在2012年的一次分享，是指通过对不同类型运维数据的综合性使用，来观测业务运行状态，定位业务故障根因，进一步缩短MTTR，实现SRE。

如图二十五所示流程：

• 第一步，我们接到告警
• 第二步，及时打开仪表盘，确认是哪个指标出现异常
• 第三步，检查具体对应指标的情况，结合之前提到的同环比分析、分组内基线对比等，判断是哪台机器出现异常
• 第四步，查看具体对应机器的日志存在什么问题，如果能够发现问题所在，即可直接解决，如果只查到一些相关的粗浅记录，则无法定位到具体代码级别根源
• 第五步，打开定位到具体对应模块的调用链，查看其中是否有代码级别的问题描述，如果有，即可直接联系研发同事解决问题

这个流程被抽象而得的内涵，普遍认为就是可观测性概念的体现，即我们从最表层的监控，可以直接深入到底层，相关所有信息都能够查找出来，最后将完整详细的信息提供给研发同事，辅助他们快速解决问题。

可观测性，其实就是把运维分析中不同类型的数据（日志、指标、链路等），通过一个总的名目或入口汇集到一起。

如图二十六我们可以看出，原有的告警、监控这些都没有发生改变，但是从思维方式上来讲，可观测性为我们提供了一些新颖、高效的总结归纳，同时为我们整体的运维工作指导了方向。

云生态

公有云上的日志服务

公有云生态环境下，大量基础设施、中间件都托管给了公有云产品。在这一方面，运维工程师需要转变视角，多从业务角度去观测运维体系。同样，这些云产品的日志采集、清洗，就成为了公有云日志服务的核心能力，也是云计算运维工程师的必备技能。

云原生变革

近几年，以Kubernetes技术为核心的云原生概念势头正旺。从运维数据分析的角度来看，Kubernetes最大的特点就是它放弃了传统的IP，改用动态的标签和命名空间。

由此，也导致日志分析存储技术产生了一些新变化，通过标签可以快速过滤到足够细分的日志数据范围。所以，在小范围内，全文索引可以通过并行的暴力 grep实现替代。

05 日志与AIOps

业务代码日志的分析难度是较大的，日志频繁更新也会影响数据模型的稳定性。2016年，国防科技大学计算机学院廖湘科等在《软件学报》上发表了《大规模软件系统日志研究综述》的论文，其中谈到：

• 在软件开发中进行日志记录是普遍的，平均30行代码中就有1行是日志
• 日志信息对实际部署系统的运行故障调试有较大帮助，缩短故障调试时间的加速比为2.2
• 日志代码的更新频率比其他代码（比如业务代码）要快约1倍
• 约四分之一的日志修改是把新的程序变量写入日志
• 约一半的日志修改是对日志消息静态文本的修改

日志模式识别原理

在研发人员打印日志比较随意而且发版之后修改较为频繁的情况下，针对业务代码构建数据的模型稳定性相对较差，我们需要采用新办法来解决这类问题，比如结合一些模式识别、文本聚类等方式。

如图三十，对比下来有8条具体日志，第一步我们可以先通过实体识别技术，将时间、IP等信息识别出来，替换完成后得到四个基础模式；第二步进行进一步的对齐、聚类、相似性计算等操作，此时我们得到两条日志；最终，我们还可以通过判断来确认是否还能实现向上提取。

日志模式在故障定位中的运用

类似上述技术在故障定位中的作用非常大。当运维工程师得到的已知关键字不全时，搜索一个error可能会得到170多条结果，全部看完的话费时费力、效率低下，还不一定能找到需要的信息（见图三十一）。

但通过模式识别， 系统会自动在这170多条信息中分析出其中某5条，告诉我们其实这170多条描述的无非就是这5条所包含的内容，查看5条与查看170条的耗时显然是有很大区别。

站在运维排障角度，运维工程师通常会逐条检查这5条信息。可见，利用自然语言数据处理技术帮助运维工程师缩小了尝试范围，减少尝试次数，缩短了排障耗时，自然能够大幅提升运维排障效率。

DNS请求日志的异常检测

此外，我们也可以针对日志做一些比较标准的机器学习，比如特征提取。

DNS Tunnel是一种常见的安全威胁。通过针对请求日志进行特征提取，配合一些公共域名白名单，我们可以实现极高准确率的DNS tunnel异常检测，这种属于比较传统的异常检测，通常精确度较高。

DNS请求日志中，我们还可以提取查询类型、查询域名等的特征值，比如FQDN整体长度、子域名长度、域名层级数量、中间级域名最大长度、中间级域名平均长度、大写字母数量、数字数量、熵值等。