目录
在当今以用户为中心的IT环境中，越来越多的组织正在实施站点可靠性工程师 (SRE) 功能，以此来定义衡量系统的可用性和正常运行时间、提高发布效率和降低故障成本。用户需求也在不断推动系统频繁的变更。基于此，传统的监控方法根本无法满足SRE的监控期望和要求。
从本质上讲，监控是观察系统的行为。它的目的是：我的系统是否在做他们应该做的事情？
现在，越来越多的组织开始采用微服务系统架构模式，微服务中的各个服务具有很高的自由度，弹性和安全性要求，因此我们需要一种新的方法来进行监控。
成功监控策略的5个特征
要使SRE取得成功，组织需要一种全新的现代方式，来管理和监控快速扩展和快速变化的IT基础设施，其中监控是保障服务稳定的关键组成部分。
那么SRE世界中的监控应该是什么样的呢？成功的监控策略具有什么特征？
1. 衡量性能以满足服务质量要求
现在，仅仅一个Ping命令，来查看系统它是正常运行还是停机了，已经是不够了。Ping 命令很有用，但它不能了解服务运行情况。知道一台机器正在运行并提供给客户的服务，才是真正的商业价值。
那么，我们如何才能最有效地衡量这些服务的性能。答案是测量系统中每个组件之间每次交互的延迟。在这个以客户为中心的世界中，高延迟就是新的“故障”。
Web用户体验的质量受到众多微服务性能的影响。如果要完全了解性能，就需要检查该系统中每个组件和微服务的延迟。所有这些延迟加起来决定了客户体验的成败，从而决定了你的服务质量。
如果每100次数据库查询中就有1次运行缓慢，你的服务质量会受到影响吗？如果每100个客户中就有5个客户对你的服务感到不愉快，你的业务会受到影响吗？
但是，传统的监视方法使SRE对这些情况并不知情。每个用户都很重要，每个用户的交互也很重要。而，他们的体验直接受到每一次组件交互、每一次磁盘交互、每一次云服务交互、每一次微服务交互和每一次API 查询的直接影响，所以它们都应该被衡量。
想象一下，如果不衡量用户请求的总延迟，并在子组件和微服务中出现不可接受的延迟时提醒SRE，那么SRE就无法了解导致Web 应用程序失败的原因。
因此，SRE需要能够可靠且经济高效地测量所有数据，需要全面了解所有基础设施和所有服务指标。这不仅有助于问题的快速解决，而且一旦你收集了这些指标，你的团队就有可能在这海量数据中发掘出额外的商业价值（如：用户偏好）。
2. 集中式监控平台
传统监控，往往拥有不同的监控工具，每个工具都有特定的目的并创建数据孤岛。这是一个缺乏一致标准和流程的环境。因此，常常无法在组织内的不同团队之间以清晰且标准的方式共享信息。
拥有不同的监控工具通常需要更多额外的成本和资源，而且通常只有少数人知道如何使用它们。在战略层面，无法全面、统一地了解支撑业务的系统的运行状况和性能。
通过将你的所有指标（应用程序、基础设施、云平台、网络、容器）集中到一个可观察性平台中，你的组织将拥有一个跨团队和服务的一致的标准性的监控指标。
一个统一实时呈现和关联所有数据的集中式监控平台，整合了组织内所有团队的监控工作，并使企业能够从其监控工作中获取最大价值。
3.Metrics 2.0的监控解决方案
如果使用传统的监控流程，今天的SRE如果要从数百万个数据流中确定性能问题的根源，可能需要数小时的工程时间。为了快速解决性能问题，SRE需要系统更多的上下文内容。
带有上下文的指标，可以帮助SRE关联事件，减少识别服务故障的根本原因所需的时间。
这就是为什么SRE需要拥有符合Metrics 2.0的监控解决方案的原因。Metrics 2.0 是一组围绕时间序列指标元数据的约定、标准和概念，其目标是以自我描述和标准化的格式生成指标。
Metrics 2.0 的基本前提是没有上下文的指标，没有多大价值。Metrics 2.0 要求使用有关正在收集的指标的关联元数据或上下文标记指标。例如，在没有上下文的情况下从一百台服务器收集CPU利用率并不是特别有用。但是使用Metrics 2.0标签，你会知道这个特定的CPU指标来自这个特定的服务器。
当所有指标都以这种方式标记时，查询和分析变得非常强大。你可以根据这些标签进行搜索，并且能够以多种方式对数据进行切片和切块，以收集有关你的运营的分析见解和情报。
4.SLO要具有灵活性
服务级别目标 (SLO) ，最近已经成为描述应用程序可靠性的流行工具。正如谷歌SRE书中所描述的，SLO是应用程序开发人员和SRE团队明确捕获应用程序风险容忍度的一种方法，通过定义可接受的失败级别，然后根据该决策做出风险vs回报的决策。
用于创建 SLO 的基本步骤包括以下部分：
- 要测量的内容 - 请求数、存储检查、操作，就是要测量什么。
- 所需比率 - 例如“50% 的成功时间”、“99.9% 的时间可以读取”、“90% 的时间在 10ms 内返回”。
- 时间范围 - 要为目标使用的时间段：最后 10 分钟、上个季度期间、30 天的滚动时间内。 SLO 多半使用滚动时间段或者日历单位（如“一个月”）来指定，使我们可以比较不同时间段的数据。
将这些部分组合在一起，并在其中包含重要的“位置”信息，示例 SLO 如下所示：
“据负载均衡器报告，最近 30 天内，90% 的 HTTP 请求成功。”
同样，衡量延迟的基本 SLO 可能如下所示：
据客户端报告，最近 30 天内，90% 的 HTTP 请求在 20 毫秒内返回。
将这种做法引入组织时，从这种简单的基本 SLO 开始。 之后可以根据需要创建更复杂的 SLO。
因为SLO是一种可用性和性能保证，所以它不应该围绕识别何时出现问题而设置。相反，SLO 应该围绕客户感知价值设置，因为这会直接影响你取得成功的能力。
许多组织花费大量精力尝试正确设置他们的SLO。不幸的是，这是白费力气。因为，很难第一次就让你的SLO完美，这是不可能的。相反，SLO应该是一个迭代过程。你应该有一个反馈循环，根据你每天得到的信息，及时更新。因此，你的SLO要具有灵活性，需要定期重新评估它们，以确保它们不会太松也不会太紧。
5. 保留你的监测数据以降低未来风险
以前，监测数据通常被认为价值低且成本高。时代变了，与所有计算资源一样，数据存储的成本已经大幅下降。
更重要的是，SRE提高了长期保留这些数据的价值。当系统出错时，SRE需要能回到过去并了解过去有关问题的原因，了解失败是如何发生的。
数据保留，通常可以带来有价值的学习，从而降低未来的风险。
总结
与过去相比，在当今以客户为中心的IT环境中，SRE越来越需要更高级的监控。
当组织接受这些监控特性时，将获得许多好处，例如更快地识别和解决问题、全面了解所有指标、更好的性能、降低成本以及对决策的准确性更有信心。
译文链接：https://thenewstack.io/5-monitoring-characteristics-sres-must-embrace/
