👎🏻 👨🏾‍🏫 🙃 SRE可观察性：命名空间和度量标准结构 🐳 🍴 🤴

Shorai-san的Spyglass

结构化的度量标准名称空间对于在事件发生期间快速访问信息非常重要。仔细计划名称和度量标准维度，以支持各种查询和扩展名。创建灵活的度量模型的一种有效方法是将它们视为一棵树。

这具有几个优点：查看数据的某些子集，根据子项定义度量并在度量之间建立关系。 Mail.ru云解决方案

团队翻译文章，其中讨论了指标名称空间的属性，使您可以逐步增加查询的详细信息并移至数据的子集，并从其所组成的指标的角度查看该指标。您已经熟悉了许多这些概念，因为它们是在Prometheus和DogStatsD等本机云监视解决方案中实现的。

度量名称空间及其结构

度量标准名称空间是度量标准所在的概念空间。它们通常仅限于数据库或帐户：

度量标准名称空间也是名称空间内度量标准的结构。适当的名称和结构具有许多巨大的优势。

上图中的名称空间没有明确的结构。每个指标是独立的。度量标准没有其他共同点，只是它们存在于同一名称空间中。在这种无关的结构中，每个指标将被单独使用。要查看对服务的http请求的频率，必须直接访问服务指标-service_N_http_requests_total。

假设我们要查看对所有服务的请求总数。如果我们创建一个新服务，在上面的示例中会发生什么？

如果请求总数是通过将对service_1和service_2的请求求和得出的，则添加service_3不会更改请求的总数。要计算正确的请求总数，您需要通过添加service_3_http_requests_total来更改计数规则。查看下面的请求数量图表：

指标树

无结构名称空间的替代方法是使用度量标准名称作为名称空间来接受显式结构。在下图中，您将这种结构看作一棵树：

在Prometheus和Datadog中，使用标签和标签创建度量结构。标签使您可以动态地构建树：添加新服务时，它指的是根指标。

在Prometheus中，可以通过构建请求来查看所有服务的每秒请求数，如下图所示：

使用结构化的名称空间，您可以动态计算整个节点上的查询总数。在这种情况下，Prometheus将每个服务的每秒请求数计算为一个单独的指标。

定义继承指标

使用度量树时，每个度量维度（标记为“服务”）都包含对特定服务的请求的单独频率。使用度量名称空间，您不仅可以获取总请求频率，还可以获取每个服务的请求频率：

使用名称空间，您不仅可以选择和可视化常规指标数据，还可以选择并可视化常规指标部分的数据（按某些属性分组）。因此，在上图中可以看到对单个服务的请求频率，它们的总和给出了对节点的请求频率。

缩小样本范围-数据子集

命名空间还支持查询范围缩小以检索特定的数据子集。例如，让我们问一个问题：“对于具有Canary部署的服务器，所有成功的HTTP请求中的p99延迟（99％的请求比指定的延迟快）是多少？”

上面的树对名称空间的概念进行建模，并可以选择对度量如何存储在磁盘上进行建模。使用定义良好的度量标准名称空间，您可以将度量标准扩展到任何参数。

下图显示了以上指标树中的p99和p50图：

如果您提出更具体的请求，则可以回答以下问题：“对于在每台服务器上下文中都进行了金丝雀部署的服务器，所有成功的HTTP请求中的延迟p99是多少？”

以下是根据Machine_id进行选择的指标的可视化：

由于该指标具有定义明确的结构，因此我们可以通过指定必要的选择条件（在本例中为machine_id）从顶级指标中选择所需的数据。

赔率规则

系数是构成数据（相关性）的另一种方法。这是一种非常强大的机制，是计算SLO的可用性和错误率的基础（这些指标已由Google SRE专家推广）。

系数允许最终用户显式关联度量标准，从而建立度量标准结构。这些关系通常以百分比表示，即，可访问性可以计算为“成功请求/请求总数”的比率，错误率表示为“错误数量/请求总数”。系数的另一个示例是一个状态从多个状态出现的频率。

让我们对此进行说明，并假设有一个应用程序执行了该请求，该请求可能会导致以下两种状态之一：从缓存中获取的数据（cache_hit：true）或从主源获取的数据（cache_hit：false）。要查看缓存命中率，数据的结构应如下：

下图显示了命中和未命中缓存的频率。每个请求进入或不进入缓存。总共每秒大约有160个请求：

下图显示了缓存命中率相对于请求总数的比率。命中系数为0.5（50％）：

因此，您可以关联任何两个指标。在Datadog和Prometheus中，这种关系通过简单的算术运算来表达。

数据回答的问题

思考数据应该回答的问题很重要。在第一个示例中，数据采样无法准确回答以下问题：“所有实例每秒处理多少个查询？”，但是名称空间树将有助于获得答案。

另一个常见情况是带有服务名称而不是客户端库名称的客户端度量标准的名称空间。将客户端库的名称添加到名称空间将回答以下问题：“来自所有客户端的请求总数？”。

一般有用的问题回答了Google的四个黄金信号。每个问题都以一般方式提出，然后指定：

所有客户总共提出多少个请求？
每个客户提出多少个请求？
每个客户端对每个节点发出多少个请求？
每个RPC成功的服务器请求的百分比是多少？

相同的策略适用于延迟，错误率和资源饱和。

通用标记指标

这是我在Datadog和Prometheus的查询优化和数据存储最佳实践中阅读的内容。

要获得支持详细描述特定细分的全局视图，请从通用的顶级命名空间开始，并添加标签和标签（从通用的名称空间开始，然后添加更多的特定名称和标签）。这样做时，请考虑以下建议。

当心基数

Datadog和Prometheus都建议限制标签数量。引用Prometheus手册：

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

如果您为每个用户添加FS配额，则每10,000个节点10,000个用户将迅速达到数千万个时间序列。对于Prometheus的当前实现而言，这太多了。即使数量较少，在此监视中也将不再具有其他可能更有用的指示符。

从没有标签开始，然后根据需要随时间添加更多标签。

通过分布式跟踪通常可以更好地实现方便的用户级别监视。分布式跟踪具有其自己的指标空间和最佳实践。

结论

重要的是要了解通过构建度量标准可以回答哪些问题。错误的结构会导致难以获得答案。尽管构造度量空间并不复杂，但需要事先计划以充分利用数据。

当出现问题时，手动扩展度量以查看所有状态的能力至关重要，并且重要的是名称空间不要对此造成干扰。

祝好运！

还有什么要读的：

SRE可观察性：命名空间和度量标准结构