前言：本篇文章是【读书笔记|大数据时代的数据挖掘】系列的第二篇，是根据此书的第二章所写的读书笔记。
目录
一、数据驱动的网络运维
数据的价值在大数据时代得到了更为直观的体现，很多企业由业务驱动转向了数据驱动，对数据进行更有效的存储和管理是实现大数据分析的基础。
四个阶段
1、网络运维1.0阶段：简单的数据处理
- 日志是指带时间戳的基于时间序列的数据。
- 此时产生的数据量不多，是MB or GB级别的。
- 数据库的使用即可解决问题
2、网络运维2.0阶段：分布式大数据处理框架
- 数据级别达到TB、PB级别，且日志数据的特征之一就是随时间快速增长
- 传统的单机数据库无法解决问题，所以出现了分布式处理技术
- 对大数据的处理包括：数据搜集、数据接入、数据计算、数据输出4个步骤，及搜集、存储、计算以及可视化展示
3、网络运维3.0阶段：网络运维平台套件
- 2.0阶段的几大主流的分布式大数据平台需要操作人员的专业操作，缺少简单易用的数据开发平台
- 出现一站式大数据处理软件，性能强大，简单易用
4、网络运维4.0阶段：智能化网络运维
- 在面对实际应用中异构日志的技术处理、故障溯源、工单分析等复杂的运维需求，3.0时代的分析平台不能提供完美的解决方案
- 于是在已有的智能化运维平台上，需要分析具体的项目需求，结合自然语言处理、大数据挖掘、机器学习等开发高校的算法，研发该领域相关的克定花的高可用处理引擎，构建基于多源数据的智能运维协同分析平台
二、系统日志分析的目的
1、基础概念
自动化计算指IT系统能都适应不同的商业业务逻辑和硬件环境的一种能力，包括计算系统的自动配置、自动修复、自动优化、自动保护。
系统日志是记录生产设备运行过程中产生的数据。系统日志和事件的挖掘是自动化计算的基础和关键。
2、系统日志和事件的分析目的
- 系统问题诊断
系统问题诊断是指判定系统是否发生故障和故障发生的原因。系统日志就是最重要的系统监控的问题诊断数据来源之一。
- 调优与优化
实际中大部分多线程开发最有效的调试手段都是软件人员主动嵌入日志，生成代码，然后通过生成的日志分析和揣测bug出现的原因。
也被用于各种程序优化软件，优化软件的目标是找出待优化的瓶颈，最常见的手段就是在待优化程序代码中主动嵌入可跟踪的日志产生代码，优化软件通过分析日志，跟踪优化程序每个执行函数消耗的运行时间及内存等，从而找到瓶颈。
- 系统安全维护
日志常用于被动攻击的分析和防御中。可以断定和寻找攻击源，从而找到有效抵御措施。
比如，鉴别denial of service（DoS）攻击的最直接办法就是查看服务器的连接请求日志，如果发现在某个时段出现大量异常的同一IP地址的连接请求，即可把此类攻击归结为DoS攻击。
比如一些病毒防御软件通过分析应用程序调用操作系统的API历史记录来分析应用程序的行为是否正常，从而判定该应用程序是否是病毒或蠕虫（worm）。这里的API历史记录也是一种系统日志数据。
三、日志数据分析管理系统的架构
通常大企业的IT服务架构，都依赖于一个日志数据分析和管理系统。日志数据分析管理系统通常是IT服务管理的核心系统架构。本章主要讲述数据挖掘技术在日志数据分析上的应用案例。
架构
- 日志数据的搜集和预处理
许多软件都可以直接从logs目录下复制日志数据文件，还有一些监控软件可以主动抓取系统状态信息生成日志文件，直接传递给后台服务器
通常要求不影响生产服务器的性能下完成
此外，何种数据需要搜集，何种不需要搜集这在系统管理和网络监控领域也是研究的热点之一。
- 历史日志数据存储
日志数据时时刻刻都在产生，因此专门针对日志数据管理的很多数据仓库被用来存储系统历史数据。
与常规数据库不同的是，这里的历史数据仓库以只读和导入操作为主，修改和删除操作较少。很多企业开始使用NoSQL的方式剑历存储日志数据仓库。
- 日志事件数据的分析以及对分析结果的展示和使用
分析方法氛围实时分析和离线分析两类。
通常基于数据挖掘的方法都是针对海量历史数据进行离线分析的，然后将创建的模型用于实时的日志分析。
比如在异常检测里，根据历史数据训练一个分类模型，然后用于实时的日志搜集。
需要注意的是，在系统管理和网络的研究领域中，有一类异常检测故障追踪的方法，并不需要离线的数据分析。
通常针对系统日志事件挖掘出来的结果以知识库（knowledge base）的形式存储在管理系统内，系统管理员还需要查阅和审核以及修改知识库内的结果，才能真正部署在生产服务器上。
四、系统日志的数据形式
- 无结构的日志数据
常见的linux日志等记录在一个纯文本日志文件中，每条日志或者事件都以一条文本消息或短文的形式存储在日志文件中。
包括3个部分：1日志产生的日期和事件；2日志产生的java类；3消息
内容是Hadoop开发人员在定义在Hadoop源代码内部的。描述当前程序在执行何种人物或者遇到何种错误时异常。
很多日志文件没有标准的日志格式，甚至在同一个软件系统内，不同模块生成的日志格式也完全不一样，因为他们可能是由不同开发团队生成的。这样在分析时候，全靠系统管理员在这方面的经验。
- 结构化与半结构化的日志数据
最常见的就是Windows Event Logs，Event Viewer是Windows操作系统中查看Windows Event Logs数据的图形界面程序。Windows大致把Event Logs分程5大类：application、security、setup、system、forwarded events。
- application：应用程序生成的日志数据
- security：与安全相关的事件，比如window防火墙会阻挡外部tcp请求，这些被阻挡的TCP请求就会被记录在这部分日志内
- setup：应用程序的安装和windows组件的安装、卸载、修改
- system：系统内部运行状态的各种日志数据，比如某个服务被停职，某个服务进程被开启等
- forwarded events：是从其他计算机转发的信息
除此之外，很多系统监控系统生成的日志事件数据也以半结构化的形式存储在关系数据库内，不同之处在于，专业监控系统可以通过管理员定制各种复杂的监控信息，产生各种不同的日志数据。而且这些日志数据并不保存在服务器自身文件系统中，而是直接写入海量数据中心的关系型数据库或者NoSQL数据库中。
- 非结构化数据的转换
很多日志数据是半结构化或无结构化的文本，所以在进行分析之前，需要把这种文本数据转化为结构化的事件。在传统的自然语言处理领域，这个人物就是信息抽取。信息抽取有基于规则的，也有基于统计模型的。在学术界，大多都是基于统计模型的。
在没有训练数据的情况下，无结构的日志数据转换还可以通过分析器日志生成的源代码完成。但是很多商业软件系统的源代码不是可以获取的。再次，源代码十分庞大，将文本日志住哪华为各种类型的事件的过程需要使用算法：一般通过聚类，可以得到与标签或者其他的聚类依据。此时也涉及到最长公共子串的问题。
五、基于日志数据的异常检测
1、基于监督学习的异常检测
方法就是分类，类别为“”正常或“异常”。
例子：在大型企业、学校、政府的开放服务器系统内，有大量的用户，但是并非每个用户都是可靠的使用者。极少数的用户会试图跨越本身用户等级，获取系统更高层的权限和秘密的数据。这类用户被称为insider threat。通常unix系统和windows系统会记录每个用户的操作。然后建立用户日志数据。然后利用svm训练算法训练得到一个svm分类器，来对其他未知用户进行判定。
使用朴素贝叶斯分类器来判定异常的系统日志事件。
异常检测的分类数据通常都是非平衡的。非平衡的意思就是绝大多数样本是正常的，极少数是异常的。svm分类器最终得出的分类平面会更偏向于异常的区间。
非平衡数据下的分类问题大致有两类解决办法。
- 第一类：通过采样的方式让训练数据集平衡。以SMOTE算法为代表，具体方案是under-sampling和over-sampling。
under-sampling是只取小部分的正常样本，减少正常样本的数量；over-sampling是重复采样一场样本，增加异常的数量。
under-sampling适合于大数据量的样本，这样减少一点正常的样本也没问题。但是小数据量的就不可以了。over-sampling适合训练集过小的情况下使用，SMOTE算法会在操作时在重复采样的异常样本上增加一些属性的细微变化，来减少过拟合的情况发生。
- 第二类：加入样本的权重值，计算带权值的分类模型的分类函数。
如果用户对原始数据集的分布不了解，通常唯一的办法就是通过不断改变权值来测试svm的效果。（cross-validation）
2、基于无监督学习的异常检测
大致方法是通过数据挖掘里的聚类分析找出远离类簇的数据点，就是离群点。
基于此类方法的异常检测都有一个大前提假设：异常日志事件出现的概率远小于正常的日志事件。
但是现实中在高纬度的数据集内，数据点的分布可能都非常稀疏，对离群点的寻找还需要在子空间内进行。此时还需要利用主成分分析寻找子空间。
子空间聚簇分析
pca试图找到最大k个子空间去表达全部原始数据。这个过程大致可以分为两种情况：
- 一种是假定子空间的坐标轴与原始坐标轴并行，及垂直投影以可获取的子空间。也可以用欧氏距离计算。通过downward-closure的性质，子空间的搜索算法有自底向上法和自顶向下法。
假设原始数据空间是d维的，那么取每个子空间先做投影变换再做聚类分析，至少要做2^d次。 - 另一种是严格按照线性代数描述的线性子空间，广义主成分分析。
注：pca是寻找一个k维度的子空间，使其所有的数据点都落在其中某个子空间内。GPCA是找多个k维度的子空间，并让所有数据点都落在其中某个子空间内。
六、系统故障根源追踪
1、问题产生背景：
在实际的大型企业信息环境下，信息平台通常架构于多层系统之上，且每一层可能也有多个并行计算的服务器。每一层依赖于上一层的服务器。
然而在实际复杂和动态的系统内，要知道各种系统模块和日志事件之间的相互依赖关系并不容易。
一个原因时涉及软件系统和数据的隐私问题。现实中很多系统维护都是外包给第三方做的。
另一个原因是实际系统维护流程很难应付时刻变化的网络环境。不同的部门只负责自己部门的程序和设备之间的关系。很多情况下，大型企业IT环境内的存储设备，对于管理员来说是一个黑盒子。
本文纠结扫如何通过数据挖掘技术分析系统运行日志，揣测不同设别和系统模块之间的依赖关系。
2、日志事件的依赖性挖掘
此处区分四个基本概念的关系：关联、相关、因果、依赖
依赖性是两个随机变量的取值之间存在内在联系
相关性只是这些随机变量的联合分布具有通高同低的或者对立相反的 现象。
依赖不一定相关，相关也不一定依赖。
关联性就是指依赖性，之间存在的关系叫因果关系。
离散性和连续性的相关性：数据类型有两种离散型和连续性，但没关系，都可以做相关性分析
事件依赖挖掘的操作：
在数据挖掘领域，很多事件相关性挖掘更多是一种关联性的模式，在统计上，关联性模式的挖掘除了要求不同事件在联合分布上的相关行外，还要求这种观察现象是频繁出现的。
数据挖掘侧重于快速在大量的高纬度数据中找到目标的参数。
最早分析序列数据上的事件依赖模式的论文是1995，大致思想是将序列数据按照事件分成多个可以重叠的事件擦黄口。如果事件A和事件B同时出现在一个窗口，就可以认定事件A和事件B是频繁出现的事件类型集合，可能具有一定的依赖性。
时间窗口
后来人们发现时间窗口上的高度重合不一定意味着依赖性，于是人们开始用person相关度量来判断频繁集合。
如何寻找合理的时间窗口也是一个问题。这里使用的是一个检验算法：可以将问题转换成：在事件A和事件B独立的请款修改，找到N个事件窗口同时包含两个事件的概率。然后如果N-105，此时出现的概率为0.02，那么就可以认为假设不成立，a和b存在依赖关系。
但如果有一些情况，需要事件B通常发生在A之后的一段时间，那么此时就不能用过宽的时间窗口了，那样会导致假关联。其实，除了宽度参数以外，还有一个位移参数。
其实还有无人工参数的时间窗口寻找方法。
基于依赖关系的系统故障追踪
可以一层一层地根据依赖关系推测最深层出现故障的组件。
可以通过建设贝叶斯网络来估计其他为观测到的组件最有可能的状态。
七、总结
当日志文件多大且内部依赖关系非常复杂的时候，通过一般的数据挖掘方法会得到大量不需要的细节，因此不适用于系统管理员从全局的角度进行分析。所以，研究人员提出了事件总结。
事件总结算法基本要求及相关工作的4个基本要求
- 简洁并准确
- 能够从宏观描述数据
- 能够描述局部数据的夜店
- 尽量少的算法参数
在文中例举了三种方式用于事件总结：
- 基于事件发生频率变迁描述的事件总结：根据事件的发生频率分类
- 基于马尔可夫模型描述的事件总结：解决了时序信息丢失问题
- 基于事件关系网络描述的事件总结
注：在文中也提到了由于第一和第二种方式都晦涩难懂，所以提出了事件关系网路模型，更简单。