减少监控噪音的终极指南

我们不会粉饰它——网络监控是个累赘。我们听到客户谈论的最常见的痛点是缺乏对所有 IT 的单一视图、过度警报以及保持整个工作正常运行所需的管理开销。在这个博客中，我们将讨论如何缓解通常最痛苦的问题——过度警觉和淹没你的工程师和技术人员在难以理解的数据海洋中造成的问题和疲劳——我们称之为“数据洪流”。

监测噪音或“数据泛滥”挑战

问题在于来自多个平台的信息“泛滥”，造成如此多的问题，以至于员工忙于处理它们而无法预防，而由于普遍未通知导致的信息丢失而加剧了这些问题。要解决这些问题，我们需要从寻找它们的原因入手。

来自多个平台的信息泛滥是由于缺乏明确的通知计划和过度配置的监控和警报造成的。尝试创建一个仅限于单一平台的连贯系统，该系统只提醒您可以或将要解决的问题。反应性警报、静态警报以及缺乏自动化和长期可见性使得潜在问题未报告和未解决，直到它们成为主要问题。未能通知会导致遗漏问题，而让问题溜走的参差不齐的监控政策会加剧这种情况。这些是由于 dev 和 prod 之间缺乏通信导致监控系统跟不上配置更改造成的。

创建新的监控策略

控制信息的第一步是创建新的监控策略。这是通过为您的配置奠定基础、定义行动和升级计划以及安排时间表以定期更新该计划来完成的。根据受影响的用户数量和影响的严重程度定义您的优先级。请记住，如果一切都很关键，那么没有什么是关键的。通过制定尽可能具体的行动计划来跟进这一点。您将需要定义：通知谁、何时以及如何通知；何时升级，向谁升级；何时进行更改；以及您可以和不能自动化的内容。

制定行动计划

首要任务是定义一个行动计划，在危机期间可以依赖该行动计划获得详细的指示。您至少需要定义在事件期间应该准确通知谁以及应该使用哪些方法，既用于初始通知，也需要定义升级时间表。在通知管理人员之前，中断应该持续多长时间？这也将在很大程度上取决于中断的范围和优先级，因此请确保您清楚地概述了将传达给他们的内容。请记住，措辞不当的通知会适得其反——它们会导致人们恐慌并采取错误的行动。

另外，请记住考虑一天中的时间和一周中的一天。一些企业是 7/24/365 运营，但许多不是，或者至少不是所有资源。当系统在几个小时后出现故障但直到第二天才需要时，流程是什么？什么时候有人可以解决这个问题？在许多情况下，对非工作时间中断的不同响应是合理且适当的，您的监控计划应反映这一点。

最后，不要忘记看看你可以自动化什么。自动化对事件的初始响应以执行诸如重启服务器、启动新的云资源或重启集群中的服务之类的操作，可以大大减少您的 MTTR——通常甚至在您必须手动干预之前。

管理您的监控通知

在大规模中断期间，您需要能够可靠地将正在发生的事情传达给所有团队和利益相关者。您的监控计划应准确说明您将如何向人们发出通知，尤其是考虑到大规模停电所固有的困难。电子邮件和短信通常是大多数通知所基于的基础，但如果我们没有完全实施我们讨论过的技术以尽量减少它们，它们可能会在危机期间受到影响，或者只是充满警报和通知。

考虑一些替代方法。例如，移动应用推送通知采用与电子邮件完全分离的路径，这些甚至可以从云端启动，因此您的内部网络或系统的状态不会影响它。您还可以将 API 集成到团队通信平台（如 slack、spark、bitrix 或其他平台）中，以确保团队的所有成员都知道正在做什么、何时以及由谁完成。

您的计划还应该利用您拥有的现有操作系统。这有助于消除冗余警报源并将事件整合到可管理数量的警报中。例如，与通知管理器集成可以简化待命安排，并提供一种不依赖于内部邮件基础设施的警报分发方式。许多组织还将使用 ServiceNow 等票务或 ITSM 系统，您需要确保您的计划包括在危机期间应如何使用这些工具以及如何将它们与您的监控和警报系统集成。

减少警报量

还可以通过自动响应某些类型的警报来减少警报量，例如让服务、服务器和端口自动重新启动，同时仍然允许您手动执行命令。在这种情况下，维护窗口就不那么重要了。减少警报数量的另一种方法是将相关问题放入单个通知中，这在级联故障和基础设施依赖警报（即延迟）等情况下特别有用。当然，最简单的减少方法是掌握流程，在处理警报时确认警报，使用计划中断的维护窗口，并与现有流程（例如票务和抄送）集成。不要费心提醒不可操作的项目。

在处理电子邮件警报和报告时，使用分发列表与人员变动保持同步，并为历史报告创建存档。使用历史报告存档来识别“吵闹的鸟儿”，这将有助于发现和消除误报。您可以使用“吵闹的小鸟”来创建模板基线报告和通知摘要报告。让我们看一些警报示例，看看哪些是真正可行的。

如果您收到高 CPU 利用率警报，这是否可行？好吧，可能是 CPU 已经卡在那里一段时间了。允许您为这些类型的警报设置延迟，因此在一段时间内超过 90% 之前它不会生成警报。如果您的 SQL 服务器与 CPU 挂钩，这可能是正常的，并且您不想要那个警报，但如果它已经被锁定了 30 分钟，您可能需要去杀死一个工作。

优化警报

还内置了工具来帮助您优化警报，这将使您能够识别“吵闹的鸟儿”。少数配置的警报导致警报数量不成比例，或者可能需要调整警报灵敏度的警报。您还可以使用模板基线报告准确查看配置模板正在生成哪些警报，并直接对其进行更改，然后可以自动将这些更改推广到应用该模板的所有设备。此外，通知摘要报告之类的内容有助于准确查看发出的警报并计算来自每个设备或每种类型的服务检查或阈值警报的警报数量。

如果交换机端口出现故障，这是否可行？如果它插入了重要的东西，通常是的，所以这是立即报警的好选择。但是，如果它是端口通道的一部分，或者只是大型集群中的一台服务器呢？这可能需要不同的优先级或不同的通知方法，不需要“删除所有内容并修复此”响应。

如果网站宕机了怎么办？嗯，这通常是一个很大的肯定。但是你想确保它从你的环境外部和内部都下降，这样你就可以正确地协调响应。重要的是要知道它是只是返回错误的网页，还是后端出现故障，或其他原因 - 因此使用从多个远程位置启动的应用程序检查等功能可以帮助您在开始故障排除之前评估问题。

使用电子邮件分发列表

我们经常向客户提供的最佳实践建议之一是使用分发列表（而不是单个电子邮件）作为您的电子邮件警报和自动报告。这样做有几个很好的理由，但关键之一是更好地与人事变动保持同步。监控系统检测到问题的事件不止几起，但警报会发送到废弃或无效的邮箱，这导致检测和处理问题的时间明显延迟。它还允许您创建自动报告的简单历史存档并在中心位置共享它们，因此如果您需要返回两年前 9 月的每周绩效报告，它们很容易找到和定位，即使详细数据现在已经存档。

拓扑映射

减少警报数量的最佳方法之一是利用您的工具来利用自动警报抑制技术，例如根本原因检测。通过在您的工具中配置拓扑（或让工具发现它），该工具可以确定该位置的所有远程设备突然无法访问的原因是由于 WAN 路由器故障，而不是发送通知每台远程设备——每台交换机、服务器、应用程序和无线接入点——你可以得到一个单一的警报，立即告诉你问题是广域网路由器，例如。

自动化您的监控和警报响应

此外，控制正在发送的警报数量的一个好方法是集成自动化。自动化有几种形式，首先要看的是自动化对警报的响应，因此在许多情况下，我们可以完全消除发送通知的需要。您可以链接供应商 API，例如 webhook，以便您的监控系统可以重新启动端口、重新测试应用程序，甚至转储实时诊断以响应问题。

允许您通过操作员干预手动控制这些命令，因此，如果您想直接在监控系统的 Web 界面中添加“单击以重新启动服务器”功能，并限制只有管理员可以访问，有一个简单的方法可以做到这一点. 但是请记住，如果您要自动响应，则维护窗口的使用变得至关重要。否则，计划的软件升级可能不会如您预期的那样进行，因为您的监控系统开始在后台采取行动。没有什么比关闭应用程序进行计划升级并让服务器突然重新启动更令人沮丧的了。

如果您使用多个平台接收通知，请确保问题的优先级会影响消息传递的方式，以免紧急通知被埋在多个不同应用的收件箱中。一些常见的通知方法包括电子邮件、SMS、移动推送通知、slack 和 spark。

要管理您的通知，请尽可能集中更改，以避免重复报告和冲突状态。集中化最重要的部分是在团队之间进行单点确认、沟通和查找状态。您可以通过 API、OpsGenie 和 PagerDuty 等通知管理器以及 ServiceNow 和 Remedy 等票务系统将集中化与现有系统集成。

利用自动配置

让我们谈谈另一种自动化监控过程的方法，那就是自动化监控系统的配置。确保您的集中可见性可以保持最新，而您的环境不断变化是关键。具有易于使用的基于 Web 的 API，允许您将配置过程直接链接到监控中，或通过 API 自动发现资源，然后使用规则推动配置向前发展，以定义控制各个方面的类别、战略组和模板以最小的开销监控配置。您甚至可以通过 API 将您的部署与自动维护窗口相关联。将新系统投入监控（或将其移除）所花费的时间越少，也意味着有更多时间专注于更重要的任务以推动业务向前发展。

使用灵活的自动配置系统来自动化您的配置。自动配置附带一组规则来帮助您入门，并且可以轻松自定义或创建它们以适应您的环境。您可以使用它们来设置设备属性，例如基于任何设备标准的类别、站点和应用程序组——包括诸如正在运行的进程、打开的端口、设备名称或 SNMP 值等内容。这可确保您的配置过程中没有手动步骤。通过这种方式，您可以轻松确保设备最终出现在正确的报告中，并且始终应用正确的设置。这些会在发现设备时自动应用到设备，也可以根据需要重新应用，因此如果您想确保所有 STAYS 都按照您想要的方式进行配置，您可以强制执行。

不要依赖手动流程来管理配置。自动发现不应仅限于扫描，并确保使用 API 的深层链接。可以使用 vCenter、puppet/chef、Hyper-V 和超融合将监控链接到配置。自动发现您使用的云资源和系统，包括 Azure、AWS 和 GCP。利用基于异常的阈值来检测和警告异常行为并自动生成基线，但请仔细考虑您的敏感性。

使用级联模板自动化

使用我们使用 AutoConfig 引擎设置的这些标准，可以将所有相关模板动态应用到您的设备。将自动应用多个模板，每个模板的设置将智能地滚动到设备上。这样，上线的新 SQL 服务器不仅可以获得您想要的基本 Windows 服务器设置，还可以获得特定于 SQL 的应用程序检查和设置。您可以使您的模板与您的监控计划保持一致，以确保它们设置适当的优先级和时间，并让它们定义正确的身份验证、升级和主动响应自动化操作。它的设计足够灵活，可以满足全球企业客户的需求，同时对于小型 IT 部门来说仍然足够简单，无需大量培训或专职人员即可使用。

使用基于模板的配置时：设置所有警报、阈值和服务；按优先级、应用程序和平台创建模板；并定义升级、操作和自动化。使用基于规则的自动化应用模板，这些模板可以自动应用到发现的设备，将确保您不会错过任何配置步骤，并允许根据需要重新应用规则。

使用异常检测

检测异常行为，而不是仅仅依靠静态警报设置，是主动监控并在问题影响用户之前发现问题的关键方法。您可以轻松地使用异常检测来发现应用程序行为的变化，并且它几乎可以应用于任何地方——CPU、内存使用、正在运行的进程，甚至是日志消息。如果您的应用程序从每小时 10 次登录失败变为 1000 次，那么最后一次部署可能没有您预期的那么顺利，现在您可以开始进行故障排除了。

将使用我们保留的大量历史数据自动生成基线行为模型，并随着您的环境变化和演变自动调整基线。可以根据观察一天中的某个时间、一周中的某天甚至每小时的基线行为的变化来检测异常情况。这使您可以发现意外影响，例如导致后端 SQL 服务器上 CPU 出现异常行为的软件更改。

我们的一位客户发现了一个问题，通常在星期三上午 10 点，数据库服务器以 50-60% 的速度运行，但突然以 15% 的速度运行。事实证明，用户界面的软件更改破坏了应用程序深处表单上的 CSS，前端团队没有注意到它，客户也无法正确完成订单。这种异常是一种永远不会触发静态阈值的异常行为，但在这种情况下，早在他们注意到订单急剧下降和可能导致的客户投诉之前就揭示了一个问题。

管理流程

制定成功的监控计划的关键是确保它被使用并始终掌握监控系统。确保您的技术人员和工程师在处理问题时承认问题。不要让监控屏幕被警报淹没。充满警报的监控屏幕很容易错过关键警报。需要尽快对警报采取行动并确认或更正。在支持团队的正常工作时间之前，让警报排在队列中是不可接受的。如果条件在非工作时间是可以接受的，那么只有在不可接受并且有人可以解决问题时才应该生成警报。在特定时间范围内未得到解决的警报应升级。

此外，对计划内停机使用维护窗口不仅有助于减少警报数量，而且还将使正常运行时间报告正常化，因此在给定月份内没有计划外停机的系统可以显示 100%，而无需手动调整报告或编写解释将它们汇总到高级管理层。最后，不要忽视警报。忽略警报肯定会惹上麻烦。在某些时候，会犯错误，有人会忽略错误的警报。通过确保甚至看不到不可操作的警报来完全避免该问题。您仍然可以在不利或异常情况发生后报告以进行主动调查。