LSTM UEBA异常检测——deeplog里其实提到了，就是多分类LSTM算法，结合LSTM预测误差来检测异常参数
结合CNN的可以参考：http://fcst.ceaj.org/CN/article/downloadArticleFile.do?attachType=PDF&id=1497
除了行为，其他还结合了时序的异常检测的：https://conference.hitb.org/hitbsecconf2018ams/materials/D1T2%20-%20Eugene%20Neyolov%20-%20Applying%20Machine%20Learning%20to%20User%20Behavior%20Anomaly%20Analysis.pdf 里面提到了。也本质上就是LSTM做回归。
deeplog除了检测序列是否异常外，还检测命令参数是否正常，也就是用LSTM去预测取值，看MSE是否很大。https://github.com/charles-typ/DeepLog-instroduction 这里有更加详细的说明。
--------------------------------------
DeepLog：基于深度学习的日志异常检测
简介
本文介绍一个基于深度学习的日志异常检测系统——DeepLog，来自安全领域顶会CCS2017。
系统日志记录了系统的各个时段的状态和重要事件，是性能监控和异常检测的重要数据来源，而异常检测是构建安全可靠系统的关键一步。现有基于日志的异常检测方法主要分为三种，分别是使用PCA做异常检测、分析不同日志类别相关性做异常检测以及使用工作流模型做异常检测。虽然这些异常检测方法能够有效地应用在特定的领域，但是它们不是一个通用的在线异常检测方法。因此，通过系统日志做自动化地异常检测是非常有必要的。
挑战
系统日志的应用比较复杂，存在如下挑战：
•非结构化日志，它们的格式和语义在不同系统之间有很大差异，一些现有的方法使用基于规则的方法来解决这个问题，但是规则的设计依赖于领域知识，例如工业界常用的正则表达式。 更重要的是，基于规则的方法对于通用异常检测来说并不适用，因为我们几乎不可能预先知道不同类型日志中的关注点是什么。
•时效性。为了用户能够及时的发现系统出现的异常，异常检测必须要及时，日志数据以数据流的形式输入，意味着需要对整个日志数据做分析的方法不适用。
•异常类型多。系统和应用程序可能会产生多种类型的异常。我们希望异常检测系统不仅针对于特定的异常类型，还能检测未知的异常。同时，日志消息中也包含了丰富的信息，比如log key、参数值、时间戳等。大多数现有的异常检测方法仅仅分析了日志消息的特定部分(比如log key)，这限制了它们能检测到的异常类型。
DeepLog设计思想
针对上述挑战，论文作者提出了一种基于深度学习的日志异常检测系统——DeepLog。DeepLog通过以下三步异常检测来综合判断系统异常，其框架如下图所示。
1.执行路径异常检测。将异常检测问题转换成一个log key的多分类问题，使用LSTM对日志的log key序列建模， 自动从正常的日志数据中学习正常的模式并且由此来判断系统异常。同时，LSTM可以增量式地调整模型参数，以便适应随着时间推移而出现的新日志文件。
2.参数和性能异常检测。f有时候系统虽然是按照正常操作步骤执行的，但是记录的日志中的参数是不正常的，比如延迟比正常要大，这种情况也属于异常。
3.工作流异常检测。虽然工作流模型在异常检测的有效性上不如LSTM模型，但是工作流模型可以可视化地帮助运维工程师在发现异常后找出异常的原因。
1、执行路径异常检测
大多数系统日志都是由系统按照一定的格式输出的非结构化的文本，log key来表示一类日志(例如k1: Took * seconds to deallocate network)，现有很多方法可以提取日志的log key。一般的，日志会按照一定的顺序输出，分步记录了系统的状态，即文中的执行路径。DeepLog将执行路径异常检测的问题转换为log key的多分类问题，使用下图所示的LSTM网络对log key序列建模。假设日志共有n个log key，DeepLog的输入为一个时间窗口内的log key序列，输出为所有的log key在该log key序列之后出现的概率的向量。也就是说，如果新来的一条日志对应的log key不是接下来出现概率较大的log key，则视为异常。
例如一段时间内logkey序列为,DeepLog读取日志的窗口h为3，则DeepLog的输入序列和输出logkey分别为,和{ k3,k4,k5–> k6}。
在实际应用中，一个给定的log key序列之后可能会出现多种日志，而且这些日志可能都是正常的。例如系统在尝试连接到主机时，“Waiting for * ” 和 “Connected to * ”这两种日志都属于正常的日志。所以DeepLog在这一步的异常检测时，按照下一个log key出现的概率排序，将前几个log key都视为正常。
2、参数和性能异常检测
有些系统异常发生时，它的日志不会偏离正常的执行路径，但是它日志内的参数会与正常情况下的参数有较大差异。DeepLog将每一个log key对应的参数保存下来，作为异常检测的数据源。与执行路径异常检测的方法类似，参数和性能异常检测也会使用LSTM网络建模。它的输入为某个log key对应日志中近期历史的参数值向量，输出为下一个参数值的预测值。在实际应用中，如果预测值和观测值之间的误差在高斯分布的高置信区间内，则输入的日志参数被认为是正常，否则认为是异常事件。
3、工作流异常检测
在许多系统日志中，日志消息是由多个不同的线程或并发运行的任务生成的。然而现有的方法都是基于单个任务的日志来生成工作流模型。所以在创建工作流模型时，会下图两种情况。图a表示的是同一个任务并发产生了不同的日志，图b表示新的任务产生了新的日志类型。DeepLog会将日志分类成不同任务对应下的日志，然后使用传统的工作流模型来生成工作流，方便运维工程师查看异常原因。
实验验证
DeepLog使用了两个数据集来验证DeepLog的有效性，分别是从亚马逊获取的HDFS日志和自己模拟的OpenStack日志。首先作者使用HDFS日志对比了DeepLog与PCA、IM等传统方法在执行路径异常检测的准确率。
从图中我们看到，DeepLog的Precision、Recall、F-measure都高于其他传统的异常检测算法。然后作者通过自己模拟的OpenStack异常来证明参数和性能异常检测的有效性，下图中a、b两个子图展示的是正常的日志参数对应的MSE(均方误差)，c、d两个子图是有异常时MSE的变化，红色虚线代表的是不同置信区间的边界。通过对比这四个子图，我们可以看出DeepLog可以有效的从数值型参数中检测异常。
最后，作者使用OpenStack异常的例子解释了工作流模型的使用场景。下图展示的是一个OpenStack系统异常的例子。在log key序列出现之后，理论上下一个log key应该是k39，但是实际的log key为k67，即发生了异常。通过查看工作流，我们可以发现异常发生在"Instance destroyed successfully"之后，"Deleting instance files *"之前，说明异常发生在清理虚拟机的过程中。
结论
本文介绍了一种基于日志的异常检测系统——DeepLog，用于自动、准确的检测系统异常。DeepLog分别包含执行路径、参数和性能、工作流异常检测三个部分，综合的来判断系统是否发生了异常。由于长度限制，本文没有介绍DeepLog的算法细节，特此附上论文链接。
