摘要：

   在监控之前要考虑的问题，以便您可以在影响您的业务之前改善环境并减轻基础设施事件。
　　
　　随着组织继续将应用程序从遗留系统迁移到云原生，出现了新的监控实践和方法。现代监控使用RED和USE作为处理复杂环境复杂性的标准方法。
　　
　　然而，组织还必须考虑需要回答的元问题——那些为您在监控中的成功程度奠定基础的问题。事实上，您很可能至少以一种本能的方式知道这些答案，但是考虑并理解它们可以使监控您的环境变得更加容易。因此，让我们深入探讨这些元问题是什么，以便在影响您的业务之前更好地监控和缓解基础设施事件。
　　
　　这个系统曾经表现良好吗？
　　
　　对于第一个问题，我们可能拥有所有问题中最“元”的问题。我们的应用程序和基础设施正在以惊人的速度发生变化。我们都处于云原生计算之旅的某个阶段。我们的应用程序世界由微服务架构定义，并由公共或私有云中的弹性计算提供支持。是的，我们仍然需要处理遗留系统。
　　
　　那么，你怎么知道这曾经表现良好，或者根本没有表现？
　　
　　一般来说，我们应该在测试和部署阶段解决这个问题。显然，我们希望系统在一定的性能范围内无错误地运行。但是我们怎么知道呢？让我们把它归结为一个词：可观察性。
　　
　　通过向我们提供有关应用程序和基础设施行为的深入数据，可观察性使我们能够确定我们的成功完成和我们的基本性能范围。但是我们需要确保我们的测试用例被理解和可重复。大多数情况下，我们会使用合成监控来为我们提供监控洞察力，因为它为我们提供了对真实用户、真实世界体验的受控模拟。
　　
　　随着我们继续从多页Web应用程序（在后端呈现）转向单页Web应用程序（在客户端呈现），这种模拟变得更加重要。由于我们的单页应用程序也可能会产生更多的通信（XHR、API调用），我们需要一些方法来可靠地比较性能随时间的变化。
　　
　　综合监控使用脚本模拟最终用户事务，使我们还可以获得某种程度的可重复可靠性。Synthetics还允许我们为我们的性能建立基线，我们可以用它来表明应用程序正在运行并收集指标，使我们能够回答有关性能的问题。事实上，将合成作为测试策略的一部分并在生产中定期使用可以帮助您在超出错误预算或累积SLO之前识别和规避错误燃烧。
　　
　　是什么让您认为有问题？
　　
　　在当今世界，我们需要快速准确地确定错误行为。错误可被视为导致不正确、不完整或意外结果的问题。这些错误通常由指标（如报告HTTP错误）或标志指示符（说明这是一个错误，如在状态代码中）进行跟踪。
　　
　　当然，在现代世界中，缓慢是我们新的停机时间。缓慢的成本销售会导致用户不满意，并且在确定根本原因时可能会令人头疼。
　　
　　当我们需要对事件进行检测、警报和故障排除时，我们最常求助于监控的组合——在基础设施和应用程序中。是的，您确实需要两者。
　　
　　基础设施监控为我们提供了基于数据的可观察性洞察，了解我们的弹性和临时计算环境正在做什么。应用程序性能监控(APM)帮助我们跟踪我们的应用程序，因为它在服务或微服务与底层基础设施之间扭曲。
　　
　　当然，传统的监控和警报要求我们对可能出错的地方有一定的了解。我们监控磁盘空间、网络带宽、内存等。但是在当今的环境中，检测必须扩展以帮助我们跟踪和触发“未知的未知”。
　　
　　在现代概念中，我们最常发现USE和RED作为基本仪表板。USE使我们能够跟踪和发现底层系统（硬件和操作软件）中的问题。RED，通常由我们的APM生成，更多的是应用领域。RED使用分布式跟踪作为跟踪我们请求的基础，并间接地跟踪我们的用户满意度。APM将帮助我们了解那些棘手的“缓慢”问题，并快速找到根本原因。
　　
　　改变了什么？软件？硬件？加载？
　　
　　我们大多数人在日常活动中使用DevOps原则，我们实践的主要部分是部署和集成。使用微服务架构，每天甚至更频繁地看到推送并不罕见。除此之外，弹性自旋和自旋以及无服务器功能为我们的计算环境和连接这些服务的松散耦合通信提供动力，我们不仅有持续的计划变化，而且在我们的可观察性世界中也有不可预测的变化。
　　
　　那么发生了什么变化呢？
　　
　　那么，这里我们需要考虑两个相互关联的数据因素：流数据和全保真数据。我们需要实时查看数据，因为我们的结构可以瞬间改变。可以这样想：无服务器功能可能需要30微秒才能启动，不到一秒就可以完成。当这种情况发生时，我们需要尽快显示该活动及其影响的数据。毕竟，当你去寻找那个功能时，它不会在那里。这使我们得到了全保真数据。如果我们不希望出现问题，我们需要数据来分类和推断根本原因，以及对环境的全面影响。传统上，监控一次只关注一个应用程序或服务，这可能会导致我们错过级联问题。可观察性使我们能够扩大解决这些问题的空间，但我们需要所有数据来确保能够实现。没有什么比发现问题然后发现没有数据可以进行深入检查更糟糕的了。
　　
　　因此，请确保您的数据快速且完整——其他任何事情都会让您的生活变得更加艰难。
　　
　　问题会影响其他人或应用程序吗？
　　
　　随着我们转向更多基于服务的应用程序，不同的团队负责不同的服务并不少见。那么您如何处理爆炸半径问题，其中一次故障可能会影响完全不同的应用程序，或影响意想不到的用户群。
　　
　　好吧，我们在这里考虑的很多点都有帮助，但需要指出的两个项目是AI（人工智能）/ML（机器学习）和相关数据。
　　
　　我们的世界很复杂，深入了解系统中每笔交易的确切流程可能是一项挑战。在一项服务上生成的警报可能是由甚至没有直接连接的完全独立服务的根本原因问题引起的。使用人工智能技术，如果我们拥有所有连接数据，我们可以从警报原因到潜在的根本原因进行跟踪。同样，人工智能/机器学习技术可以帮助识别“正常”行为，即使它们看起来超出范围，例如识别潜在异常实际上是历史重复事件。
　　
　　但是，当出现问题时，我们需要能够在我们的数据环境（例如从应用程序到基础设施，从指标到跟踪到日志文件）之间干净、简单地步进，而不必重复我们的取证步骤。这只有在我们的数据相互关联、以监控工具理解并可以分析、可视化和检查的方式对齐时才有可能。相关数据听起来可能很简单，但是当基础设施数据可以来自为Kubernetespod、容器和应用程序提供支持的数千个虚拟服务器时，我们需要我们的系统来处理该负载，包括有关滞后和倾斜的问题。
　　
　　要记住的东西
　　
　　虽然现在的热门术语是可观察性，但我们仍然在处理监控。可观察性为我们提供了来自所有潜在来源（例如我们的基础设施、编排和应用程序）的新的、更深入的数据。但是我们仍然需要了解这些数据告诉我们什么。虽然我们的工具可以帮助分析和可视化我们的环境，但我们仍然需要回答这些问题，这些问题反过来为识别和响应事件和问题奠定了基础。
　　
　　编辑：Harris