问题很关键

为了帮助大家思考数据需要能回答什么问题？在第一个例子里数据不能回答“在所有实例里每秒处理多少请求？”，但命名空间树可以。客户端库提供命名空间可以回答： 所有客户端生成的所有请求是多少？ 另外一个常见的方法是通过命名空间客户端度量消费服务的名称而不是使用客户端类库本身。我发现对问题有用的是 follow 谷歌的黄金四指标。

• 所有客户端产生了多少请求？
• 每个客户端产生了多少请求？
• 每个客户端的每个机器产生多少请求？
• 每个机器，每个 RPC 请求成功的比率是多少？

这个策略同样适用于延迟，错误率，资源饱和情况。

使用标签的度量指标

我读了 datadog 与 prometheus 的查询与存储的最佳实践指南。想得到一个宏观视角并支持能下钻到从上层命名空间到特定指标可以使用 tag 和 label(从宏观开始到特定维度)，但是。。

小心基数

datadog 与 prometheus 都推荐限制基数。

以下直接引用：

不要过度使用 label
每一个标签都会对 RAM,CPU, 磁盘与网络产生时间序列的损耗。通常可以忽略不计，但在有很多指标与上百个标签通过上百服务器的场景下，这会快速产生影响。

一个通用的指导原则，把你的指标限制在 10 个，对于超过的，想办法在你的整个系统中限制他们。你的主要度量指标不应该有 label。

如果你有一个指标有超过 100 的基数或可能成长到那个级别，调研下能限制维度的数量或将分析部分从监控系统移到一个通用处理系统。

可以给你一个对下层数字更好的理解，让我们看下 node_exporter. node_exporter 从每个对接的文件系统导出度量指标。每个 node 都有巨量的时序数据写入 node_filesystem_avail，如果你有 10000 个 node，你会为 node_filesystem_avail 产生大约 100000 的时序数据，Prometheus 可以处理上面这些数据

如果你现在为每个用户加配额，你会很快从 10000 个用户在 10000 个 node 上达到翻倍的百万级数字。这对于目前的 Prometheus 的实现来说太大了。就算是小一点的数量，还会有一个潜在的问题是你在这台机器上不能使用其他的更有用的度量。

如果你不确定，可以开始不使用标签，稍后有具体场景时增加更多的标签。

对于用户级别的可观察性一般可以通过分布式追踪来解决。其有它自己的度量空间和最佳实践。

结论

当结构化一个度量空间时最重要的是考虑数据可以回答什么问题。错误的结构可能导致回答问题更困难，或者根本答不出。虽然结构化度量空间不困难但要达到最大的效果需要顶层规划。 在应急场景时需要度量指标能进行扩展，因为需要看到所有的状态及其状态或维度，重要的是度量空间不会在开始阶段就产生影响。

引用

• https://prometheus.io/docs/pr…
• https://prometheus.io/docs/pr…