原文： https://medium.com/dm03514-tech-blog/sre-observability-metric-namespaces-and-structures-12ffcf5a5bdc
结构化的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可以表示为算术运算。用这种方式在查询级别任何两种度量都可以被关联上。