原文：https://medium.com/dm03514-te…

结构化的 metric 命名空间对于需要快速获取信息的故障场景非常重要。为了能支持广泛的查询和扩展场景，需要仔细考虑 metric 名称和维度。我发现其中一种为灵活 metric 建模的方式就是将他们认为是树。将 metric 想象成树可以有以下好处：查看特定子集的数据，根据其子集定义度量基准与设定阈值。这些度量命名空间的属性可以进一步回答更多具体的问题并可以下钻到数据的子集并像看度量指标一样观察度量指标的组成部分。这些概念很熟悉，因为他们是想 Prometheus 与 DogStatsD 这种云原生监控解决方案的第一级想法。

什么

度量空间是概念意义上的度量指标活着的空间。他们的边界通常是一个数据库或一个账号：

度量空间不只是度量指标存活的地方，也包含度量空间的结构。正确的命名与结构可以有很大的好处。以上图的度量命名空间没有明显的结构。每个度量指标都是浮在这个空间上的。他们除了表示他们存在相同的度量空间中外，没有任何其他内容。在没有结构化的设置里每个度量指标都要单独使用。如果要看一个服务的 http 请求的频率需要直接单独访问 service_N_http_requests_total。

假设看到请求通过服务所有实例的总量很有用。在以下的例子中如果建了一个新服务会怎么样？

如果加和是在 service_1 和 service_2 计算的，当增加 service_3 时，他们之间没有什么联系；没有可度量的结构。请求总数没有反应真实的请求总量，只有 service_3_http_requests_total 被手工加上去后才行。下图表示了这个过程：

度量树

一个对于无结构空间的可用方式是用 metric 命名空间组成一种显式的结构，以下图标说明了这种树的结构：

在 Prometheus 和 Datadog 度量结构可以使用 Label 和 tags 创建。使用 tag，可以动态扩展总请求量；当一个新的 service 增加时，他可以通过树指向到主度量指标。

在 prometheus，得到通过所有服务的每秒的频率可以看下图：

通过结构化的命名空间可以动态计算通过树根节点的总量（在这个例子计算了每个单独服务作为一个度量指标）。

用它的子指标来定义度量指标

用一个树，每一个度量的维度 (比如 ”service” 标签) 包含了节点独立的请求频率。使用一个度量命名空间，不只是它的总频率可以观察，每个子服务实例都可以被可视化：

对命名空间的数据建模，可以通过对所选维度的组合来组合父数据。

增加数据的子集

命名空间也支持将数据的特定子集的明细。树可以回答这种问题：在灰度机器上所有成功 http 请求的 p99(译者: p99, p95 都是术语，p99 表示过去的 10 秒内最慢的 1% 请求)延迟是多少？

上面这个树对概念空间进行了建模同时没有对度量指标如何存储在磁盘上建模。使用一种良好定义的度量空间可以对任何维度进行扩展。

以下图展示了这个树的 p99 与 p50 的图形化：

通过以上技术可以拿到任意度量维度更具体的数据：在灰度部署的每一个机器上所有成功 http 请求的 p99 延迟是多少？

以下展示了 prometheus 对于扩展这个机器指标 machine_id 的支持：

由于这个指标在顶层指标上有结构化的定义所以可以使用 machine_id 进行动态扩展。

比例 (Ratio) 规则

比例是另一种在一个非结构化空间中将数据建立联系的方式。这十分有用，并且是由于 google SRE 而备受欢迎的计算 SLO 可用率与错误率的基础。比例让用户可以显式的关联指标，完成一个度量指标结构。这些连接经常被表示为百分比，例如可用性可以被计算成 成功请求数 / 总请求书 ，而错误率可以计算成 错误请求数 / 总请求数。其他重要的比率是多种状态中的一种状态出现了多少。

为了解释这个，我们假设一个应用执行的一个请求可以产生多种状态，例如 cache_hit:true 与 cache_miss:false。要看缓存的命中率我们按如下方式结构化数据：

这个图标示了缓存命中率与失败率的例子。每个请求要么命中要么失败。而每秒大约有 160 个请求：

下图关联了总请求频率与缓存命中频率，展示了 50% 的缓存命中率：

这建立了一种逻辑关系，而他么不是直接或者有具体关系的，在 datadog 与 prometheus 可以表示为算术运算。用这种方式在查询级别任何两种度量都可以被关联上。

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流 Email: zhukunrong@yeah.net