标签归档:警报

打击警报疲劳:如何唤醒警报策略

如今,工程团队面临着保持系统平稳运行的必要性。这是因为企业与数字客户体验之间的界限正在缩小 – 当应用程序成为企业时,任何缺乏完美用户体验的东西都意味着要达到顶线。

在这种背景下,声音警报策略现在几乎对每个工程团队都至关重要。根据最近的一项调查,58%的DevOps专业人员报告依靠五个或更多可观察性工具来确定性能问题的根本原因,这意味着他们会针对每个问题对多个位置的数千个警报进行排序以找到答案。由于无法始终监控系统健康状况的各个方面,因此智能警报策略可以帮助团队更有效地运营,并将注意力集中在最需要的地方,从而保持业务平稳运行。

但设置警报并不总是像看起来那么简单。为了做到这一点,团队不仅要应对表面下方存在的庞大复杂性,还要对抗“警报疲劳”,或者在过于频繁时忽略通知的倾向。两种情况下的关键是在节奏和紧迫性之间取得适当的平衡。为了帮助您的团队建立更好的警报策略(并在晚上睡得更好),这里介绍我们如何应对Scalyr的挑战

警报结构

首先,关于结构的一个词。在最高级别,警报围绕三个关键支柱设计:指标(您要监控的绩效指标),比较报表(即“大于”,“小于”,“等于”)和阈值(关键值为您)想要比较指标)。

例如,要监视CPU使用率的意外峰值,可以设置以下警报:如果过去15分钟内的平均CPU使用率大于过去的24小时平均值,则触发警报。

阈值

创建警报时,通常可以通过建立阈值来启动。可以将三种类型应用于警报:固定,基于状态和历史。

固定阈值,顾名思义,当性能水平超过某个静态预定级别时触发警报。在测量具有硬限制的性能指标(如CPU使用率或硬盘空间)时,这些是设置和最佳工作的最简单阈值。

基于状态的阈值也简单明了。它们识别系统状态的变化 – 例如,“运行”或“停止” – 并且主要用于监视应用程序进程以发生意外停机。

历史门槛稍微复杂一些。也被称为“滑动窗口”,这些阈值将度量的当前值与其过去的值进行比较。换句话说,监视一个特定的时间段(例如15分钟的窗口),随着时钟滴答而继续移动。例如,基于历史阈值的警报可能显示为:如果15分钟的平均CPU使用率大于24小时前15分钟平均CPU使用率的120%,则触发警报。这里的想法是在滤除噪声的同时识别给定度量中的突然尖峰。

在此主题上,在设置警报时包含“宽限期”也很有用。换句话说,添加一个规则,防止警报被触发,除非它被触发持续一段时间。这有助于滤除小的像差并识别长期活动。

度量

一旦确定了阈值,就需要确定支持警报的指标。每种警报策略都需要涵盖五个关键指标类别:容量,带宽,状态,速率和事件参数指标。

容量指标监视具有固定和已知容量的系统组件,例如磁盘空间和可用内存。如果某些东西可以“填满”或“耗尽”,通常用容量指标来衡量。达到容量时,系统会中断,这意味着阈值应设置在最大容量以下。当击中容量的后果具有严重破坏性时,应将阈值设置得特别低。

带宽指标衡量系统内的流量。例如,网络利用率,CPU使用率和磁盘吞吐量。这种类型的系统活动本质上通常是高度可变的,因此请考虑将警报基于移动平均线。例如,您可以将其设置为测量30分钟窗口的平均使用量,而不是通过查看最新测量来监控网络使用情况。

状态度量标准具有用于监视系统状态更改的不同值,例如“正在运行”或“已停止”。这些系统状态度量标准通常与基于状态的阈值挂钩。

费率指标用于衡量某些事件发生的比率。换句话说,在特定时间段内发生的事件的数量。例如,“每秒请求数”,“每秒错误数”,“每分钟登录尝试数”等。对于可预测的指标,历史阈值最好。对于不太可预测的那些,将阈值基于历史高点或低点通常是一种合理的方法。

事件参数度量基于事件的某些可测量属性,例如响应时间或请求大小。该指标通常用于监控和报告某段时间内所有相关事件的平均值。您为事件参数指标设置的阈值与速率指标的阈值类似 – 使用可预测指标的历史阈值,以及不可预测指标的固定阈值。

通知

有了正确的警报阈值和指标,下一步就是构建一个系统,用于在出现问题时接收通知。这一步至关重要。您可以拥有世界上最好的警报参数,但如果警报没有到达您,它们将无法发挥作用。

现代DevOps环境提供了多种选择。例如,现在可以将警报存储在数据库中并通过电子邮件以每日批次,立即通过电子邮件发送,通过SMS或电话发送或其某种组合来发送。诀窍在于确定哪种交互模型最适合您的团队。

一般来说,紧急警报应该是设计中断的。他们需要立即引起你的注意并传达问题的紧迫性。出于这个原因,在相同的度量标准,不同的阈值和不同的通知方法上“堆叠”警报通常也是有意义的。这里的想法是随着问题变得更加紧迫而升级警报。

警报远远超出了眼睛。设置声音警报策略需要考虑三个关键支柱:阈值,指标和通知。随着应用程序正常运行时间成为每个企业的关键任务,现在花时间为您的应用程序环境和团队找出正确的组合可以发挥重要作用。

https://thenewstack.io/fight-alert-fatigue-how-to-wake-up-your-alerts-strategy/

监控您无法忽视的指标

随着DevOps运动的兴起,人们开始关注Web应用程序监控工具。这是一件好事。监控Web应用程序(特别是在生产环境中)通常是事后的想法 – 通常在发生一些事件后才会实施。到那个时候,价值已经失去 – 无论是崩溃,性能不佳还是安全漏洞。

拥有强大的监控策略可收集有关Web应用程序运行状况的信息。在解决您的应用程序问题时,将硬信息用作指南会产生奇迹。然而,可能有太多好事。信息太多会导致信息疲劳,这与没有足够的信息一样糟糕。如果您的应用程序中显示的信息太多,那么它最终可能会被调整掉。发生这种情况时,就像没有监控一样。

在本文中,我将讨论一些需要考虑进行监控的最重要指标。此外,我们将介绍用于无缝提供信息的信息呈现方法。让我们开始吧。

选择最重要的指标

如上所述,任何无法采取行动的信息都是您需要消耗的精神体重。充其量,你只会忽略这些信息,最糟糕的是,它会将你的监控变成一个混乱的混乱,并没有提供太多的价值。一个很好的起点是过滤掉信息以显示关键指标,这是否意味着减少信息或建立监控策略。

让我们考虑一些关键指标:

错误处理

有几种方法可以处理应用程序中的监视错误:

  • 使用Raygun的崩溃报告 等工具可以轻松地显示Web应用程序中发生的任何错误。该工具允许使用交钥匙解决方案来确定应用程序中发生的错误,包括频率和确定优先级;
  • 为适当的环境使用内置度量报告。例如,如果您使用Microsoft Azure进行托管,则可以设置指标,以通过电子邮件向您发送有关服务器上可能出现的任何类型的5xx错误的信息。
  • 在您的应用程序中构建错误处理 这通常是最经济和最简单的方法,但很容易失控(同时,确保您的错误处理不会产生自己的错误)。

应用程序性能监控:内部工作

接下来,应用程序性能监视(APM)是应用程序的关键指标。APM工具提供了一种监视应用程序内部工作方式的方法。最有用的功能是确定应用程序中发生的任何瓶颈。应用程序性能管理包含两组主要指标:

  1. 应用程序最终用户所体验的性能。这包括加载时间,请求量等等;
  2. 用于应用程序的计算资源。这允许确定应用程序中的任何硬件瓶颈。

例如,假设性能正在成为您的应用程序的问题,并且用户开始经历缓慢。这些问题可能变得非常模糊,难以发现。与应用程序中发生的错误不同,性能问题更多的是滑动规模。也许它只是慢,因为互联网连接很差?也许用户只会责备自己?由于性能不是绝对的,因此用户的阈值可能会有所不同。

就像错误处理一样,有几种方法可以处理应用程序性能管理:

  • Raygun的APM As APM 这样的开箱即用的工具可以是一项非常大的工作,这是一种简单的方法,可以立即从监控中获得大量价值,而无需太多工作。
  • 手动将性能记录添加到应用程序中。这包括为查询语句添加调试语句,计算时间等。

到目前为止,我们已经指出了两个用于您的应用程序的关键指标。这有助于减少信息疲劳并仅查看最重要的信息,从而使您的Web应用程序保持完美状态。下一步是查看该信息,演示文稿可以在评估Web应用程序的状态时发挥重要作用。

演示:有效地消化信息

与指标一样重要的是,管理监控功能的另一个关键方面是接收信息。理想的交付方法是不需要大量工作来收集所需信息的方法。我有两种方式来考虑这个问题:

  1. 尽快向我提供重要信息。应用程序发生故障或严重错误之类的内容符合此条件;
  2. 获得所有应用程序状态的高级视图。我应该能够快速看到这个并获得应用程序的工作状态,如果需要,可以深入挖掘。

让我们来看看以下每一个:

#1:关键信息警报

正确消化监控信息的第一个方面是收到紧急情况的警报。与涉及优先权的所有事项一样,区分紧急问题和非紧急问题也很重要。信息过载在这里成为一种风险 – 如果您开始收到数百封有关系统错误的电子邮件,那么下一个合乎逻辑的步骤就是过滤掉这些电子邮件。这使你回到以前的状态,没有良好的监控。

有一种简单的方法可以实现有效的警报:

  • 需要立即关注的关键问题是什么?停机时间,安全问题或性能下降超过SLA可以成为优秀候选人;
  • 警报的最佳方式是什么?如果您的团队正在使用Slack,获取Slack通知可能是立即与您联系的最佳方式。也许短信息?电子邮件也是一种选择,尽管将这些警报与其他电子邮件混乱区分开来可能很困难。

重新审视前面提到的Raygun产品,有一系列集成可以使警报方法易于实现。无论您认为哪种方法最适合接收警报,Raygun都应该能够覆盖它。

#2:仪表板

最后,让我们看一下在管理监控功能时消化数据的最后一个方面。仪表板提供了在任何给定时间查看应用程序状态的视觉效果。

让我们来看看Raygun为其Crash Reporting应用程序提供的仪表板:

快速浏览一下,我可以看到如下数据:

  • 当前在应用程序上的实时用户数;
  • 平均加载时间;
  • 最近崩溃的数量。

所有这些都以易于呈现的方式提供了关于应用程序性能的硬数据。如果由于开发工作而提高性能,您将能够以有意义的方式呈现它。

纠缠您的监控能力

现在您已阅读本指南,您应该配备监控的关键信息和接收所述信息的最佳方式。您是否淹没了无法弄清楚如何有效使用的指标?考虑过滤掉您的指标,只使用上面探讨的指标,看看它是否有帮助。

https://thenewstack.io/monitoring-metrics-you-cant-afford-to-ignore/