使用仪表和度量标准使站可靠性与业务目标保持一致的7个技巧

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，加?关注?，你的?支持?是我?最大?的?动力?。

在现代 DevOps 实践加速之前，软件工程师主要编写代码。现在的工作要多得多ーー从让应用程序做好生产准备，快速迭代以扩展新服务，到设计系统兼容性并确保遵从性和可靠性ーー这提高了对特殊设备的需求。但是伟大的仪器包括什么? 你应该从哪里开始？

我在一本关于可观测性的新书中找到了这个问题的答案，这本书是我和 ChronSphere 的联合创始人兼首席执行官 Martin Mao 以及云本地专家 Kenichi Shibata 合著的ーー O’Reilly 的《云本地监测: 现代架构的实际挑战和解决方案》。

构建伟大的仪表和度量函数的7种方法

优秀工具的诀窍是构建一个优秀的度量函数，帮助您的组织在信息过多和信息不足之间找到正确的平衡。我们的书解释了实现这一目标的七种方法。

1. 从开箱即用的标准仪表和仪表板开始

SRE 团队和使用开源工具的软件工程师可以立即启用标准化的度量标准和仪表板。让他们马上开始。

他们可以，例如:

给出任何基于 HTTP 的或RPC service RPC 服务。一个自动提供的仪表板，包括基础设施和计算指标，如果收集指标与普罗米修斯从 Kubernetes/特使/nginx/服务格

使用特定的 API，然后为任何为组织特定指标(即销售数据)实现 API 的团队构建一个仪表板

创建一个请求速率，请求错误，请求持续时间(又名 RED)指标仪表板，供软件工程师观察和监视定制的预构建应用程序

2. 招募内部软件工程师和 SRE/可观测性团队来交付标准仪表板

与任何供应商相比，内部软件工程师或 SRE/可观测性团队是构建和创建标准化仪表板的更好选择，因为他们最了解您的业务上下文。这使得他们能够最好地定位于实现期望的业务结果。

在实践中，他们会知道如何:

如果您的组织严重依赖远程过程调用(RPC) ，则创建 RPC 仪表板和警

(例如，Java 或 Go Prometheus gRPC 中间件库或 RPC 代理公开的度量)

创建监视关键基础设施的仪表板和警，如Kafka topics 如果您的主要事件总线管理系统是Kafka的每个应用程序

3. 将业务上下文添加到标准化度量中

有了标准化的指标和仪表板，您就可以开始添加业务上下文了:

Traffic patterns ー通过向标准的开箱即用工具添加新标签(例如 rent _ id 和 rent _ name)来丰富您的度量。然后，您可以使用该标签来了解不同租户/客户之间的通信是如何提供服务的。如果您发现一个组织向您的服务创建更多的请求，您可以扩展宿主服务器并通知客户。例如，查看 rent _ name ACMECorp 是否向您的服务创建了更多请求，然后扩展托管 ACMECorp 的服务器，并可能向 ACME Corp 发送关于增加的使用的电子邮件

通知路由自定义ー通过添加应用程序和拥有警的团队的名称来更快地解决问题，这样警总是被路由到正确的人。还要添加依赖应用程序，这样警也会发送到应用程序的下游团队(使用配置作为代码或者在 HTTP/RPC 指标上使用带有标签连接的查询)。这允许您检测级联故障并确定故障的起始位置

分层申请ーー通过添加带有层次的标签来区分它们，防止永远不应该停止运行的系统停机，然后根据层次以不同的方式路由警。例如，第一级警不仅会发给技术人员，还会发给其他团队，促使更多的人采取行动，以提前发现潜在的问题

4. 从标准化仪表创建 SLO

服务水平指标(SLI)ーー对所提供服务水平的某些方面进行精心定义的定量度量(简而言之，一个度量)

服务水平目标(SLO)-服务水平的目标值或价值范围，由 SLI 度量，或者您希望您的度量值是什么

服务水平协议(SLA)——向用户承诺其 SLOs 的特定价值(例如某个可用性百分比)的协议，并列出了如果不能达到这些目标(SLOs)的后果

下面是实践中这三个概念的一个例子:

如果虚构的fictitious Felin公司构建了一个 API，为应用程序开发人员提供cat memes，那么它的 SLI 就是所有下游外部客户可以使用 API 的时间百分比。如果它的 SLO 是99% 的可用性，它承诺客户每年停机时间不超过3.65天。这是由一个误差率公式来衡量的。如果停机时间错误超过了 SLO 规定的限制，SLA 声明公司同意每多停机一分钟向动物收容所捐赠1美元。

谷歌的 Steven Thurgood 在《站可靠性工作手册》中写道，错误预算“是 SRE 用来平衡服务可靠性和创新步伐的工具。”[2]

如果您的公司的 SLI 是可用的，那么您可能已经测试了一组标准化指标，比如普罗米修斯 RED 指标。在这种情况下，您可以使用这些标准化指标来构建一个仪表板，这将使得基于性能创建现实的 SLO 变得相当简单。但是您还必须标准化每个 SLI 在整个组织中的意义。例如，什么是99% 可用性？这里的经验法则是整个组织的一致性。

5、一定要监视监视器

了解监控的两件事很重要: 谁来监控监控系统? 当系统瘫痪时会发生什么？

这三条规则有助于确保可靠性:

规则一 — 不要在运行基础设施的同一区域运行监视，以避免在基础设施退化期间监视可访问性中断

规则二 — 使用与运行生产工作负载的云提供商不同的云提供商。这确保了即使整个云供应商或 SaaS 服务部分出现故障，您仍然可以访问您的监控系统

6. 建立写和读的限制

度量基数从根本上说是可乘的。一个工程师可以编写一个查询，该查询可以读取10到100万个时间序列的基数度量。因为不能安全地保证系统不会因为回答此查询而超载，所以最好构建一个检测系统，以了解您的查询或写操作之一是否会导致停机。

为开发人员和用户阅读和写作:

用于写用例 ー通过允许开发人员监视其发布速度，向开发人员显示他们添加的每个指标的成本。通过这个视图，他们可以看到它们相对于其他应用程序和团队的使用情况，并且知道什么时候它们使用的资源超过了公平分享的资源

用于读取用例 —允许用户在查询大量数据时只查询他们需要的数据，从而快速、公平地共享查询资源。另外，确保基数与它们的适当使用相匹配(使用自动化或其他方式) ，因为查询经常使用数万个实时警共享的相同存储资源集

(七)建立安全的实验和迭代方式，推动创新

如果您高度依赖于当今的监控系统，并且担心对其进行重大更改，那么您正在创建一组不同的挑战。你没有办法进行实验和迭代。您还无法在不破坏当前系统可观测性技术栈的情况下学习新技术和工具。

您可以通过在另一个可观测性系统中创建新的监视数据集(或子集)来避免这种情况。尝试将所有生产可观测性数据的10% 添加到新系统中，而不需要开发人员做更多的工作。不同的可观测性系统可以让 SRE 安全地进行实验(无需开发人员更改或重新部署代码) ，例如:

新的重新标签规则

升级你的Prometheus版本

创建跨不同类型度量的新聚合

从一个完全不同类型的技术堆栈中获取一组新的数据

测量每日公制大小

在现有任务上进行安全迭代，比如向现有度量标准添加新的基数

销毁/重建可观测性堆栈，以教会新的 SRE 系统如何工作

像Prometheus这样的可观测性系统可以每10秒(而不是每秒)从/度量端点获取数据。

云-本地可观测性提高仪器成功率

现代的可观测性平台使您和您的团队能够在一个粒度级别上了解更多关于系统和应用程序的信息，而这在历史上是很难建立规模的。加入各行各业的组织，选择可观测性平台，建立一个伟大的可观测性功能，让您控制您的遥测和增加业务信心和有效性。

[1] Stavros Foteinopoulos, “How We Use Sloth to Do SLO Monitoring and Alerting with Prometheus,” Mattermost, October 26, 2021, https://oreil.ly/e35u8.

[2] Steven Thurgood, “Example Error Budget Policy,” in The Site Reliability Workbook (O’Reilly Media, 2018), https://oreil.ly/yEg2b.

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

使用仪表和度量标准使 站可靠性与业务目标保持一致的7个技巧