服务监控和 SLO API 可帮助您管理服务，就像 Google 管理自己的服务一样。服务监控的核心概念包括：
- 选择用作服务等级指标 (SLI) 的指标。
- 使用 SLI 为 SLI 值设置服务等级目标 (SLO)。
- 利用 SLO 隐含的 错误预算 来降低服务风险。
本页面介绍了这些概念并说明了设计 SLO 时需要考虑的一些事项。本部分中的其他页面将这些概念付诸实践。
术语
此处介绍服务监控的一组核心概念：
- 服务等级指标 (SLI)：用于测量性能。
- 服务等级目标 (SLO)：用于说明预期性能。
- 错误预算：从 1 - SLO 开始，如果实际性能未达到 SLO，则会下降。
服务等级指标
Cloud Monitoring 会收集用于衡量服务基础架构性能的指标。性能指标的示例包括：
- 请求计数：例如，每分钟产生 2xx 或 5xx 响应的 HTTP 请求数。
- 响应延迟时间：例如，HTTP 2xx 响应的延迟时间。
系统会根据以下已知服务类型自动识别性能指标：Cloud Service Mesh、Google Kubernetes Engine 上的 Istio 和 App Engine。您也可以定义自己的服务类型并为其选择性能指标。
性能指标是服务的 SLI 的基础。 SLI 描述服务某些方面的性能。对于 Cloud Service Mesh 上的服务、Google Kubernetes Engine 上的 Istio 和 App Engine，我们已经知道了有用的 SLI。例如，如果您的服务具有请求数或响应延迟时间指标，则可以通过创建如下比率来从这些指标中获得标准服务等级指标 (SLI)：
- 可用性 SLI 表示成功响应的数量与所有响应数量的比率。
- 延迟时间 SLI 表示低于延迟时间阈值的调用数量与所有调用数量的比率。
您还可以设置服务专用 SLI 来针对“良好性能”进行其他方面的测量。这些 SLI 通常分为两类：
- 基于请求的 SLI，通过计算服务的原子单位（例如成功的 HTTP 请求的数量）来测量服务性能。
- 基于窗口的 SLI，通过计算性能满足良好标准（例如低于给定阈值的响应延迟时间）的时间段（也称为窗口）来测量服务性能。
基于请求和基于窗口的 SLO 中的合规性 中更详细地介绍了这些 SLI。
如需查看为所选服务创建 SLI 的示例，请参阅根据指标创建 SLI。
服务等级目标
SLO 是在一段时间内测量的 SLI 目标值。服务确定可用的 SLI，然后您根据 SLI 指定 SLO。SLO 定义什么是良好的服务。您可以在 Cloud Monitoring 中为每项服务最多创建 500 个 SLO。
SLO 基于以下类型的信息建立：
- SLI，用于衡量服务性能。
- 性能目标，用于指定所需的性能级别。
- 称为合规期的时间段，在该时间段内衡量 SLI 与性能目标的对比情况。
例如，您可能有如下要求：
- 在一个滚动的 30 天周期内，只有 5% 的请求的延迟时间超过 300 毫秒。
- 在一个日历周内测量的系统可用性达到 99%。
此类要求可以作为 SLO 的基础。如需获取设置良好 SLO 的指南，请参阅 设计和使用 SLO。
SLO 合规性的变化还可能表示故障的开始。监控这些更改能够提供充分的警告，让您可以在问题扩大之前解决它。因此，提醒政策通常用于监控 SLO 合规性。 如需了解详情，请参阅错误预算提醒。
有用的 SLO 目标低于 100%，因为 SLO 决定错误预算。SLO 通常用“几个 9”来描述，例如 99%（2 个 9）和 99.9%（3 个 9）。您可以设置的最大值为 99.9%，但您可以使用适合您服务的任何较小值。
错误预算
SLO 指定了服务在合规期间内的性能水平。在合规期间未完成的部分将成为 错误预算。错误预算量化了服务在合规性期间在满足 SLO 的前提下无法执行的部分。
通过错误预算，您可以跟踪在合规期内违反 SLO 之前允许发生的独立不良事件（例如请求）的数量。您可以使用错误预算来管理维护任务，例如部署新版本。在错误预算接近耗尽时采取有风险的操作（例如推送新的更新）可能会导致您违反 SLO。
您在合规期的错误预算为（1− SLO 目标）×（合规期中符合条件的事件）。例如，如果您的 SLO 是在 7 天的滚动期内 85% 的请求是良好的，则您的错误预算允许 15% 的这些请求是错误的。如果您在过去一周收到了 60480 个请求，则错误预算允许该总数的 15%（即 9072 个请求）是错误请求。如果您提供的错误数超过此上限，则表明您的服务在 7 天合规期内未达到 SLO。
设计和使用 SLO
一个良好的的 SLO 具备什么要素？在进行选择时需要考虑哪些因素？ 本部分简要介绍了设计和使用 SLO 的一些一般概念。《Site Reliability Engineering: How Google Runs Production Systems》 中 关于 SLO 的章节 更详细地介绍了此主题。
SLO 定义了您希望从服务中获得的目标性能。 一般而言，SLO 应该不高于必要标准或有意义的标准。 如果您的用户无法区分服务的 99% 可用性和 99.9% 可用性之间的差异，请使用较低的值作为 SLO。更高的值需要更高的成本来满足，但对用户而言却并没有什么区别。需要满足 100% SLO 的服务没有错误预算。设置这样的 SLO 是不好的做法。
SLO 通常比公开承诺或合同承诺更严格，这也将是您所希望的。这样，如果发生导致违反 SLO 的事件，您就可以在违反承诺或合同之前知悉并解决问题。违反承诺或合同可能会产生声誉、财务或法律方面的影响。SLO 是预警系统的一部分，可以防止这种情况发生。
合规期
SLO 有两种类型的合规期：
- 基于日历的周期（从日期到日期）
- 滚动周期（从 n 天前到现在，其中 n 的范围是 1 到 30 天）
基于日历的合规期
您可以将合规期设置为一周或一个月等日历时间段。
系统会在常见的日历边界上重置合规期和错误预算。
如需了解可能的值，请参阅 CalendarPeriod。
如果使用日历周期，您会在周期结束时获得性能得分。 性能得分是基于性能阈值测量的，可让您了解自己的服务是否合规。使用日历周期时，即使您可以看到整个周期内的性能情况，也只能在每个合规期获得一个合规评分。但是，期末得分为您提供了一个简单易懂的值，它可以轻松匹配您客户的结算周期（如果您有外部付款客户）。
与日历上的月份一样，月度合规期因日历月包括的天数不同而略有不同。
基于窗口的滚动合规期
您还可以测量滚动周期的合规性，以便始终进行评估（例如，过去 30 天）。在滚动周期中，先前计算中最早的数据会从当前计算中退出，并被新数据替换。
如果使用滚动窗口，您可以获得更多合规性测量结果；也就是说，您可以获得过去 30 天测量的合规性，而不是每月一次。由于旧数据点被丢弃，新数据点被添加，SLO 状态会每天发生变化，服务可能会在合规和不合规之间转换。
基于请求和基于窗口的 SLO 中的合规性
确定 SLO 是否合规取决于以下两个因素：
- 合规期是如何确定的。合规期 对此进行了讨论。
- SLO 的类型。SLO 有两种类型：
- 基于请求的 SLO
- 基于窗口的 SLO
合规性 是指在合规期内良好事件占事件总数的比率。SLO 的类型决定了“事件”由什么构成。
如果您的 SLO 为 99.9%，那么当合规性至少达到 99.9% 时就会满足该 SLO。最大值为 100%。
基于请求的 SLO
基于请求的 SLO 基于一个 SLI，该 SLI 定义为良好请求数与请求总数的比率。当该比率达到或超出合规期的目标时，则基于请求的 SLO 得到满足。
例如，考虑以下基于请求的 SLO：“至少 95% 的请求延迟时间低于 100 毫秒。”良好请求是响应时间短于 100 毫秒的请求，因此合规性的测量标准是响应时间不超过 100 毫秒的请求的比例。如果此比例至少为 0.95，则表示该服务合规。
通过基于请求的 SLO，您可以了解服务在整个合规期间正常工作量的百分比（无论负载在整个合规性期间如何分布）。
基于窗口的 SLO
基于窗口的 SLO 基于一个 SLI，该 SLI 定义为满足一定良好标准的测量间隔数与总间隔数的比率。当该比率达到或超过合规期的目标时，基于窗口的 SLO 得到满足。
例如，考虑这样一个 SLO：“在一个 10 分钟窗口至少 99% 的时间内，第 95 百分位的延迟时间指标小于 100 毫秒”。一个良好的测量周期为 10 分钟，其中 95% 的请求的延迟时间小于 100 毫秒。合规性的衡量标准是这种良好周期的比例。如果此比例至少为 0.99，则该服务合规。
在另一个示例中，假设您将合规期配置为滚动的 30 天，测量间隔设为 1 分钟，并将 SLO 目标设为 99%。要满足此 SLO，则在 43200 分钟内，您的服务必须有 42768 个“良好”间隔（30 天内分钟数的 99%）。
基于窗口的 SLO 让您能够了解客户观察到服务性能良好或性能不佳的时间百分比。这种类型的 SLO 可以避免“突发”行为的影响：一个每次调用都失败的测量间隔与一个很少出错的测量间隔对 SLO 的影响是一样的。此外，一个调用次数很少的测量间隔与一个活动频繁的测量间隔对 SLO 的影响是一样的。
错误预算的趋势
错误预算是 100% 良好服务与 SLO（即理想的服务水平）之间的差值。两者之间的差异就是您的回旋空间。
一般而言，错误预算会从最大值开始，随着时间的推移逐渐下降，并在错误预算低于 0 时触发 SLO 违规。
此模式有几个需要注意的例外情况：
如果您有一个在日历合规期内测量的基于请求的 SLO，并且服务在合规期内活动增多，剩余的错误预算实际上会增加。
为什么会这样？SLO 系统无法预先知道服务在每个合规期内的活动量，因此它会推测一个可能的值。此值的计算方式为：到当前时间为止的所有调用数量与从合规期开始流逝的时间内的调用数量的比率，乘以合规期的时长。
随着活动率的提高，该周期的预期流量也会增加，因此错误预算会增加。
如果您在滚动合规期测量 SLO，则实际上您始终处在合规期的末尾。系统会不断删除旧数据点并不断添加新数据点，而不是从头开始。
如果某个合规性不佳的时间段超过合规窗口，并且替代它的当前时间是合规的，则错误预算会增加。在任何时间点，大于或等于 0 的错误预算说明滚动 SLO 窗口是合规的，而小于 0 的错误预算则说明滚动 SLO 窗口不合规。
监控错误预算
您可以创建提醒政策，以便在错误预算的消耗速度快于预期速率时发出警告。如需了解详情，请参阅 错误预算提醒。
后续步骤
- 微服务介绍微服务，以及如何使用 Google Cloud Console 配置、查看和管理您的微服务。
- 消耗率提醒 介绍如何监控 SLI，以便在可能出现问题时发出提醒。
- 使用 SLO API 介绍如何使用 SLO API（Cloud Monitoring API 的子集）创建服务、SLO 及相关结构。