RED方法监测微服务的新策略
通过使用RED指标--速率、错误和持续时间--你可以充分了解你的服务对终端用户的表现。
监控一个应用程序对于为用户提供高质量的产品和体验至关重要。但仅仅收集大量的应用指标并不能解决真正的问题。软件公司需要的是一种方法，从他们的指标中获得可操作的见解，以便他们能够迅速解决用户遇到的任何问题。
进入RED方法：
[也在InfoWorld上：为什么你应该使用微服务架构]
RED方法的由来
RED方法是Tom Wilkie根据他在Google工作时学到的东西创造的一种监控方法。RED源于谷歌建立的一些最佳实践，被称为 "四个黄金信号"，由谷歌的SRE团队开发。
RED背后的主要理由是，以前的监控理念和方法，如USE方法，并不完全符合软件公司和现代软件架构的目标。USE更适用于硬件和基础设施，而RED方法打算把重点放在应用程序的用户实际体验上。
RED方法的目标是确保软件应用程序为终端用户正常运行，而不是其他。在现代的微服务架构、容器和云基础设施时代，只要你的服务水平目标（SLO）得到满足，与硬件相关的指标就不那么重要了。
RED方法解释
RED是指速率、错误和持续时间。这些代表了你想为你的架构中的每个服务监测的三个关键指标：
- 速率 - 服务每秒钟处理的请求数。
- 错误 - 每秒失败的请求数。
- 持续时间 - 每个请求所需的时间量。
使用这三个指标，你可以对你的服务的表现有一个坚实的了解。请求的数量给你一个基线，说明有多少流量进入你的服务。这些请求中出现错误的部分让你知道一个服务是否在你的SLO内运作。最后，你的服务处理每个请求的时间长度让你了解你的应用程序的整体用户体验。
RED方法的好处
RED方法的第一个好处是帮助减少工程师确定服务出现问题的原因所需的认知负荷。RED将每个服务的内部细节抽象成可以在整个架构中理解的东西。这不仅意味着问题可以更快地得到解决，而且也更容易扩大运营团队的规模，因为成员现在可以为他们自己没有编写的服务随叫随到。
RED的抽象性使得人们很容易理解什么地方出了问题，并确定如何修复它。即使他们要修复的服务实际上是一个他们内部不了解的黑盒子，工程师也可以查看遥测数据并确定改善用户体验的最佳行动。因为每个服务都使用相同的指标，所以培训时间或服务特定知识的数量也会减少。
RED方法的另一个好处是，它与用户和公司的整体目标更紧密地结合起来。用户并不关心你的基础设施。他们不关心你的CPU利用率，你的内存使用，或任何其他硬件指标。他们关心的是当他们使用你的应用程序时是否开始看到错误信息。他们关心你的网站上的页面是否需要很长时间来加载。当一个服务没有达到你的SLO，而你的用户有一个糟糕的体验时，RED方法就会非常清楚。
RED方法的最后一个好处是，在你的服务中实现任务和警报的自动化变得更加容易。重复性任务的自动化更简单、更安全，因为所有的服务都被同等对待。你还可以将各种服务的仪表盘布局等标准化，因为使用的是相同的三个指标。
RED方法的局限性
所有这些好处并不意味着RED方法是完美的。RED方法主要是为请求驱动的应用程序设计的，所以对于涉及批处理或流的用例，它可能无法提供你需要的洞察力。
第二个缺点是，RED的 "外部 "观点意味着你很难知道一个服务离失败有多远。流量的轻微增加可能会导致你的响应时间增加，而你可能没有内部应用指标来确定原因。使用RED方法意味着你的指标可以根据多种因素进行不同的解释，所以它确实需要慎重的实施。
好消息是，RED方法从来就不是为了涵盖监控的所有方面。Tom Wilkie建议将RED监控方法与其他监控方法（如USE）结合起来使用，以使团队对其应用进行全面监控。
相关的：
