有方法论提导，在技战术方面才不会偏离目录。html
使用服务级别做为关键语，召示着承诺和责任。框架
https://www.circonus.com/2018/06/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/工具
服务级别目标
这个服务级别目标的简要概述将为咱们如何衡量咱们的服务健康情况奠基基础。服务级别协议（SLA）的概念已经存在了至少十年。但就在最近，与服务级别目标（SLO）和服务级别指标（SLI）相关的在线内容数量迅速增长。url
除了著名的 Google SRE书之外，两本关于 SLO 的新书即将发布。“站点可靠性工做手册”有关于 SLO 的专门章节，Seeking SRE 有关于由 Circonus 创始人兼首席执行官 Theo Schlossnagle 定义 SLO 目标的章节。咱们还建议观看Seth Vargo 和 Liz Fong Jones 的 YouTube 视频 “SLI，SLO，SLA，哦，个人！”，以深刻了解 SLI，SLO 和 SLA 之间的差别。spa
总结一下：SLI 驱动 SLO，通知 SLA。.net
服务级别指标（SLI）是衡量服务健康情况的指标。例如，我能够有一个 SLI，它表示在过去 5 分钟内，个人第95 个百分点的主页请求延迟应小于 300 毫秒。视频
服务级别目标（SLO）是 SLI 的目标或指标。咱们采用 SLI，并扩展其范围以量化咱们指望咱们的服务在战略时间间隔内执行的状况。使用前面例子中的 SLI，咱们能够说，咱们但愿知足 SLI 为后续年份窗口的 99.9％ 设置的标准。htm
服务级别协议（SLA）是企业与客户之间的协议，定义了未能知足 SLO 的后果。通常来讲，您的 SLA 所依据的SLO 将比您的内部 SLO 更宽松，由于咱们但愿咱们的内部面向的目标比咱们的外部目标更为严格。blog
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 还向咱们提供每一个请求的请求延迟，所以咱们能够记录每一个服务请求完成的时间。