有方法论提导，在技战术方面才不会偏离目录。
使用服务级别作为关键语，召示着承诺和责任。
==================================
服务级别目标
这个服务级别目标的简要概述将为我们如何衡量我们的服务健康状况奠定基础。服务级别协议（SLA）的概念已经存在了至少十年。但就在最近，与服务级别目标（SLO）和服务级别指标（SLI）相关的在线内容数量迅速增加。
除了著名的 Google SRE书以外，两本关于 SLO 的新书即将发布。“站点可靠性工作手册”有关于 SLO 的专门章节，Seeking SRE 有关于由 Circonus 创始人兼首席执行官 Theo Schlossnagle 定义 SLO 目标的章节。我们还建议观看Seth Vargo 和 Liz Fong Jones 的 YouTube 视频 “SLI，SLO，SLA，哦，我的！”，以深入了解 SLI，SLO 和 SLA 之间的差异。
总结一下：SLI 驱动 SLO，通知 SLA。
服务级别指标（SLI）是衡量服务健康状况的指标。例如，我可以有一个 SLI，它表示在过去 5 分钟内，我的第95 个百分点的主页请求延迟应小于 300 毫秒。
服务级别目标（SLO）是 SLI 的目标或指标。我们采用 SLI，并扩展其范围以量化我们期望我们的服务在战略时间间隔内执行的情况。使用前面例子中的 SLI，我们可以说，我们希望满足 SLI 为后续年份窗口的 99.9％ 设置的标准。
服务级别协议（SLA）是企业与客户之间的协议，定义了未能满足 SLO 的后果。一般来说，您的 SLA 所依据的SLO 将比您的内部 SLO 更宽松，因为我们希望我们的内部面向的目标比我们的外部目标更为严格。
RED 仪表板
SLI 的哪些组合最适合量化主机和服务健康？在过去几年中，出现了一些新兴的标准。最高标准是 USE 方法，RED方法和 Google SRE 手册中讨论的“四个金色信号”。
Brendan Gregg 介绍了USE 方法，该方法旨在根据利用率，饱和度和错误指标量化系统主机的健康状况。对于像CPU 这样的产品，我们可以为用户，系统和闲置百分比使用常见的利用率指标。我们可以使用平均负载量和运行队列进行饱和度的判定。UNIX perf 分析器是测量 CPU 错误事件的好工具。
Tom Wilkie 几年前介绍了 RED方法。用 RED。我们监控请求率，请求错误和请求持续时间。Google SRE 手册讨论了如何使用延迟，流量，错误和饱和度指标。这些“ 四个金色信号 ”以服务健康为目标，与 RED 方法类似，但他添加了饱和度指标。在实践中，可能难以量化服务饱和度。
那么，我们如何监控容器？容器是短期实体。直接监视它们以辨别我们的服务健康状况会出现许多复杂的问题，例如高基数问题。综合监控这些容器的服务输出会更容易和更有效。如果服务是健康的，我们不在乎一个容器是异常。有可能我们的编排框架无论如何都会收获这个容器，并用新的框架取而代之。
让我们考虑如何最好地将 Istio 的 SLI 作为 RED 仪表板的一部分进行集成。为了组成我们的 RED 仪表板，我们来看看 Istio 提供的遥测记录：
- 请求按响应代码计数
- 请求时长
- 请求大小
- 响应大小
- 连接收到的字节
- 连接发送字节
- 连接时间
- 基于模板的元数据（度量标签）
Istio 提供了有关它收到的请求，产生响应的延迟和连接级别数据的几个指标。请注意上面列表中的前两项; 我们希望将它们包含在我们的 RED 仪表板中。
Istio 还赋予我们添加度量标签的能力，这就是所谓的尺寸。因此，我们可以通过主机，集群等来分解遥测 。我们可以通过获取请求计数的一阶导数来获得每秒请求的速率。我们可以通过请求不成功的请求计数的派生来获得错误率。Istio 还向我们提供每个请求的请求延迟，因此我们可以记录每个服务请求完成的时间。
