使用度量标准和异常日志进行异常检测-CSDN博客

在本周的白板演练中，MapR的首席应用架构师Ted Dunning将讨论如何使用包含度量标准和异常的日志来检测微服务行为的异常。

有关此主题的相关材料，请参见：

这是完整的视频转录：

嗨，我是Ted Dunning，我将讨论异常检测，尤其是操作领域中的异常检测，系统如何运行以及何时发现系统未按应有的方式运行。我为MapR工作。他们是我的帽子赞助商，但今天我们不需要。我要特别强调的是，如何在微服务环境中使用标准架构来真正发挥优势，以构建异常检测器，该异常检测器可以检测大型分布式系统何时出现问题。

如果我们在这里稍等片刻，如果我们有一个微服务并且它故意是不透明的，那么我们不知道它的真正作用，我们知道它在技术上称为切入，而我们知道它已经淘汰了。除此之外，微服务中非常标准且非常好的做法是，如果该微服务中有辅助流（例如带有异常）出现。每当观察到某种异常情况时，例如说输入某种形式的格式错误，就说这种方式在其上运行的计算机某种程度上都感到不安，我们应该在包含异常的主题上产生一个异常。

我们还应该常规地，通常地生成度量。如果可能的话，如果输入的每一位数据都需要大量工作，我们应该对每个处理的元素产生度量。如果元素很小并且我们需要做少量工作，则可能应该对这些指标进行一些预聚合，因此我们在指标通道中输出了适量的数据。显然，我们不希望这里出现的数据多于进出大量系统的数据。那太傻了。我们确实希望有足够的指标来使发现问题变得容易，而这通常比人们开始时要多。无论您要在指标的详细程度方面给出什么层次，将其略微提高都是经验法则。

一旦有了这些，关键的问题是我们如何真正检测异常？即使是这个白盒子，我们也不知道它实际上应该做什么，我们如何检测该微服务的异常操作？我们内部没有可见性。我们所看到的是正在发生的事情，正在发生的事情。我们不了解发生了什么事情，或者不知道正确的关系是什么，我们弄清了其中的一些指标，也许还有例外。我们必须确定我们不太了解的白盒是否正常运行。

我们该怎么做？关键是两件事。一种是我们需要将正在测量的内容，正在观察的特定内容转换为看起来像概率对数的东西。第二，我们必须确定该概率的对数是否异常。异常意味着不正常。在发现异常的问题中隐含着发现正常现象。我们必须观察该系统一段时间，确定它所做的大部分工作都是正常的，然后再将异常情况标记为异常。如果这些足够普遍，我们可以了解它们，并使它们成为新常态的一部分。例如，正常状态可能会包含一定程度的故障，当然，我们当然希望系统已经足够好构建，以便稀有和奇数是损坏的部分，而有些系统是我们某些人在奇数和奇数的地方构建的不寻常的是它正常工作时。那是这样的系统的早期阶段。我们将要研究的是正常现象。

让我们先来看一个情况，即系统具有输入或输出，或具有及时事件的异常。这些事件发生。我们确实可以衡量这件事，只是它确实发生了。可能是特定的例外，特定种类的输入或特定种类的输出。这些可能是我们衡量的及时事件。如果这样做，我们可以谈论的这些事情的唯一特征就是它们发生的时间。我们不允许了解这些事件。

如果我们看时间的流逝，就会发生一些事件。碰巧的是，对于一个广泛的类别，事件的时间分布非常重要，因为自上一个事件以来的时间或自第n个事件以来的时间（此处为第5个事件）以来的时间非常非常有用统计上。如果这些事情是泊松分布的，那么到最后一个事件的时间，即从现在到最后一个事件的时间的所谓一阶时间差，是对数分布的，至少假设我们在那里还有另一个事件。这意味着我们可以了解这次的分布情况，如果我们知道事件的发生率，那么最长的时间应该是多少。

第n个差异的关系稍微复杂一些，但是第一个差异对发现事件何时停止有用，而第n个差异对发现事件发生得太快或太慢有用。不过，最大的不同在于第一个差异，我们会更快收到警报。因为它试图解决一个更简单的问题，所以需要较少的信息来解决该问题。如果我们查看发生异常的时间或该系统生成输出的时间，并且查看自从上一次发生异常以来已经有多长时间，那么我们可以找出异常停止发生的时间。我们可以构建一个异常检测器，如果它知道应该发生多快，它可以在不发生时发出警报。例如，输出可能是“我已经完成了销售”。系统坏了吗？它不再有销量吗？从上一个开始到现在有多长时间了？现在，我们可以构建一个系统。

建立方式，我们要看这里的活动时间，在那儿采取第n个差异，通常是第一个差异，因为我们通常担心事情何时停止而不是何时开始。我们看那里的第n个差，然后乘以估计的比率。如果发生率很高，那么自上次事件发生以来的时间总是很小，因此当我们将它们相乘时，它就成为单位。当比率低时，时间会很大，但是比率会低，然后再次相乘就可以得到标准化的分布。当标准化输出变大时，我们可以说我们有一个异常，特别是我们有一个异常代表了事件的停止。当我们采用第n个差异时，情况会稍微复杂一些，因为此异常分数的上下偏移意味着不同的事物。

一旦获得异常分数，我们就可以保留过去的值的历史记录，然后可以计算发现第99.9个最大值的时间，这可以让我们发出警报。仍然缺少一块。缺少的部分是此费率模型。费率模型可让我们估算当前的费率。我们无法衡量当前汇率的正确性，因为可能存在异常，使汇率错误。我们必须利用我们的经验以某种方式进行预测，进行追溯，以决定目前的汇率。根据过去的证据，如果一切正常，应该如何计算？例如，这里是标称图。这是水平时间，表示某个时间段（可能是几分钟，10分钟，一个小时）中的事件计数。通常，利率上升，下降，下降，然后第二天又上升。

事实证明，我们可以很好地预测当前汇率，这很实际，可以通过查看事物24而不是根据最近的计数，最近的计数日志和远距离的计数来预测计数的对数， 25和26小时前，或7乘24、7乘24加1，依此类推。这为我们提供了有关我们应该期望的每日模式和每周模式的信息。通过查看一个小时前和两个小时前的信息，可以设置比例。从一天或一周前开始的更早的度量可以得出形状，而当前的度量可以得到比例。通过将这些日志计数合并为一个预测，我们可以预测我在其中圈出的内容，即当前的日志计数。如果您查看我们有关异常检测的书，则可以使用Wikipedia上圣诞节页面的访问量来了解如何完成此操作。您可以看到，即使在11月进行了培训，我们也可以很好地预测当圣诞节页面变得非常流行时12月的情况。

这就是我们建立计数模型，费率模型的方式。速率模型插入此处，乘以n倍，通常是自上次事件以来的第一个差异，这给我们带来了异常。每当异常超出正常范围时，我们就会出错，要么太快要么太慢。这就是我们如何查看这些指标和异常或事件进出的时间。这是构建异常检测器的一种方法，该异常检测器确实运行良好。不要告诉任何人，但这确实很容易构建。您需要进行一些线性回归来建立速率模型，需要进行一些减法，PhD水平减法和乘法运算以获得该值。您可以使用称为t-digest的东西来构建直方图，以表示在异常方面应视为大的直方图，也可以仅计算出它应该呈指数分布。无论哪种方式，您都将在这里运行非常非常简单的系统。

您也可以做一些更复杂的事情。一些系统没有按时间重复的动态特性。这通常发生在以下情况下：当观众从我们这里获得一些输出，点击，造访之类的东西时，它们会导致流量上下波动，夜间下降，白天流量上升。观众有它的模式，所以我们可以很好地预测。系统内部可能会以不规则的间隔运行。当有数据可用或正在等待其他事件时，可能会有一项工作开始或某些事情发生，并且可能不是定期执行的。我们还需要能够在其中查找异常。

我们可以做的是，我们可以采用输入的大小，输出的大小或我们可以计算的任何其他度量标准，通常是小聚合，对于系统来说，它就是在进行聚合，转换或其他简单操作，例如也就是说，输入的大小应该预测输出的大小，或者它应该预测记录的等待时间，或者诸如此类的数目。我们还可以在多个变量之间建立稍微复杂的关系，然后使我们可以将历史点标记为正常分布。我们可以从字面上构建一个模型，该模型说什么是正常的，系统工作的特征之间的正常关系是什么。然后，如果我们测量的值与正常值相差甚远，则可以再次建立异常。

例如，在这里您可以看到，随着输入大小的增加，输出大小的增加，但是在此异常时刻，这里的输入很大，几乎没有输出。东西坏了。这就像管道破裂。水进来了，但是水没有出来。这就是我们可以检测到的异常。这里真正的关键不是数学，也不是算法。这些都是数学上相当简单的事情。

关键在于提前计划和构建微服务架构的艰苦工作，该微服务架构会提出指标并提出例外情况。它告诉您有关内部情况的一些信息。一旦具有很小的可见性，一旦黑框变成白色，您就可以检测到异常，并且可以自然地发出警报，告诉您系统何时不正常（即发生故障）。这就是在微服务架构的上下文中进行异常检测的想法，这是一个非常非常强大的概念。非常感谢你。