如何利用RED和USE metrics实现监控
监测是什么?
监控是一项关于系统实时数据收集、处理、聚合和展示的艺术。 你可以监控各样的查询、错误、系统处理时间、服务器正常运行时间等。 监视是每个软件的关键和必要部分，因为它能帮助你掌控你的系统，快速并且主动地对意外问题作出反应，并最终防止或减少停机时间。
不同的监控方法
在关注监控软件选择之前，我们可以花一些时间来区分不同监控方法实现的目标:
-
白盒监控:这种方式是基于系统内部暴露的metrics ，在白盒类别中，我们有完整的系统地图，我们知道关于过程和组件的每一个细节，对我们来说没有什么是隐藏或封闭的。 它包括日志、接口，如JVM概要分析接口或HTTP Handler发出的内部统计信息。 这种监控类型是否成功取决于我们使用正确的instrumentation来检查系统内部结构。 白盒允许检测到即将发生的问题，失败重试，当然，包括显而易见的错误
-
黑盒监控:这种方式是基于测试用户可以看到的外部可见行为。 我们不知道系统内部是如何工作，但我们可以在不同条件下(时间、地理位置、连接方法, 不同的电脑和/或操作系统等)量化出指标在哪里扩大/超过或有显著的变化(10%的价值始终是一个好的变化参考,不管是好是坏); 这种方法会让你的用户有一定了解如何使用你的服务，但通常不会帮助你防止问题的出现;
我们的监控目标
你不能改进你没有测量的东西(Peter Drucker)，所以监控是改进你的产品(性能、可靠性等等)最重要的起点，我们想要改进我们现有的监控架构，以提高我们能实现以下目标的能力:
- 分析长期趋势:我的数据库有多大，增长速度有多快? 我的日活跃用户增长速度有多快?
- 警告:有东西坏了，需要有人马上修理它! 或者，什么东西可能很快就坏了，所以应该有人来检查一下。
- 构建仪表板:仪表板应该反馈关于你的服务的基本问题，通常包括某种形式的HTTP指标。
- 进行特别的回顾性分析(即调试):我们的延迟突然上升; 这段时间还发生了什么?
Prometheus “如何启动你的监控”
Prometheus是一个用于监测和警报的开源生态系统，专注于可靠性和简单性。自从它创建以来，许多公司和组织都采用了Prometheus，并且该项目拥有一个非常活跃的用户和开发者社区。
我们选择采用Prometheus是因为它的许多特性允许我们在软件和基础设施的不同部分满足不同的需求:
- 一种基于时间序列数据的数据模型，该数据由度量名称和键/值对标识
- 这是一种非常灵活和强大的查询语言，可以帮助聚合数据，结果可以实时聚合并直接显示或通过HTTP API使用，以允许外部系统显示数据
- 不依赖分布式存储;节点是单点服务器并且自治的
它之所以被选中，还因为它和我们的产品一样，采用微服务架构，它对多维数据收集和查询的支持是Prometheus相当大的优势。
Prometheus专为可靠性设计，即使在系统停机期间也允许你快速诊断问题,因为每个服务器是独立的,不依赖网络存储或其他远程服务,即使基础设施的其他部分没有回应，我们依然可以使用它。
Grafana -以丰富多彩的方式展示数据
Grafana是一个用于显示时间序列分析的开源软件。它允许我们利用指标中查询、可视化并且生成警报。大+ Grafana的很大好处是可以集成多样的本地数据源,如果将来我们需要改变或集成新的除了Prometheus以外的数据源，也是不难的事。我们也可以很容易地在同一个仪表盘图形使用来自不同源的数据。
Grafana还允许我们在查看数据时非常快速和轻松地创建和配置警报，我们可以定义阈值，并在出现问题时通过Slack获得通知。
四个黄金信号
四个黄金信号是谷歌SRE定义的一系列指标，在监控以用户为中心的系统时被认为是最为重要的几个因素:
- 延迟:服务一个请求所需的时间;
- 流量:衡量系统有多少需求;
- Errors:请求失败的比率;
- 饱和度:我们的服务有多“饱和”，基本上就是我们离耗尽系统资源有多近;
在监控时，我们并不全使用这4个指标。取决于我们所监视的内容，我们会选择基于这4个指标的子集来使用以下两种不同的方法，例如:对于HTTP指标，我们使用RED方法，而对于基础设施，我们使用use方法。
从四个黄金信号到使用RED原则监控
RED方法是“四个黄金信号”的子集，专注于微服务架构，包括以下指标:
- 速率:我们的服务每秒处理的请求数;
- Error:每秒失败的请求数;
- 持续时间:处理一个请求所花费的时间;
获取这些指标非常简单，特别是使用Prometheus这样的工具，我们可以为每个服务使用相同的指标并且在Grafana显示结果的仪表板中创建一个标准且易于阅读的格式。
从监控的角度来看，对每个服务使用相同的指标，以相同的方式对待它们，有助于运维团队的可伸缩性，减少团队所需的特定于服务的学习成本，并减少了on call工程师需要记的那些在紧急事件下特定服务的特殊情况——所谓的“认知负荷”。
基础架构 和 USE 方法
USE方法更侧重于基础架构监控，可以用来监控物理设备等资源，并且仅基于三个参数：
- 利用率：所使用资源的比例，因此100%的利用率意味着不能接受更多的工作；
- 饱和：资源有无法服务的额外工作的程度，通常排队；
- 错误：错误事件的计数；
虽然这种方法在一开始就帮助我们确定每个资源（CPU、内存、光盘等）要使用哪些具体指标，但我们的下一个任务是如何解释它们的值，虽然这并不总是那么明显。
例如，虽然100%的利用率通常是瓶颈的标志，必须采取措施降低瓶颈，但恒定的70%利用率也可能反应出问题，因为它隐藏了由于metirc是在比突发更长的一段时间内100%利用率的突发而被平均的值，因此没有被识别。
USE方法帮助我们识别可能是系统瓶颈的问题并采取适当的对策，但由于系统很复杂，因此需要谨慎调查，因此当您看到性能问题时：
这可能是个问题，但不是问题所在。
在继续检查其他资源的参数之前，必须使用合理的方法对每个发现进行分析。
开发过程中遇到的问题
在实施新的监测时，我们遇到了两个必须克服的挑战。
- 第一个挑战是在容器上部署监控系统，这带来了一个很大的问题：存储管理。容器本身不提供持久性存储，因此如果由于任何原因无法使用，我们将丢失其中存储的数据。
作为这个问题的解决方案，我们找到了REX Ray，这是一个专注于为容器存储接口（CSI）创建企业级存储插件的项目。REX Ray提供了一个与供应商无关的存储编排引擎。主要设计目标是为Docker、Kubernetes和Mesos提供持久存储。由于我们使用Docker，这对我们来说是一个很好的解决方案。
起初，我们尝试使用其Amazon EBS集成，但出现了一个问题：EBS位于一个可用性区域，当容器移动到另一个可用性区域时，它将失去与存储的连接。然后，我们转而使用在整个AWS地区都可用的Amazon EFS，这使我们永远不会失去与存储的链接，即使容器在可用性区域内移动。 - 第二个挑战是找到一种自动、轻松或以编程方式生成仪表盘的方法。Grafana没有提供太多的API，我们发现自己存在配置版本控制的问题，还必须手动重复模式以创建新的仪表盘、警报等。
为了解决这个问题并减少手工工作量，我们找到了GrafanaLib，这是Weaveworks的Python库。它允许我们从易于管理和源代码控制的简单Python脚本生成仪表盘。
未来的发展，我们对新的监控满意吗？
我们很高兴地了解我们的监控架构是如何实现，如何工作的，并且它开始真正帮助我们控制我们的软件。它提供了更多信息，速度更快，并统一到易于管理的仪表板中。在最近的一个场景中，由于HTTP服务的新仪表盘，我们注意到当特定客户端调用搜索引擎服务时，搜索引擎服务的响应时间异常，进一步调查可以了解到有一系列特定的参数减慢了响应。然后，我们能够快速处理该案件，并使其在合理的时间内再次返回结果。
我们计划将其与我们的持续集成系统集成，这样，当我们创建一个新服务时，JSON将自动生成，Grafana将对其进行抓取，仪表板将更新，而无需进行任何手动操作。
我们下一个与监控相关的改进将是关于应用程序监控，尤其是对于遗留代码。
你会用不同的方式做事吗？可以在下方评论让我们知道
原文链接： https://medium.com/thron-tech/how-we-implemented-red-and-use-metrics-for-monitoring-9a7db29382af
原文关注公众号：“云原生SRE”