SRE:可观察性:Metric命名空间与结构(二)

问题很关键

为了帮助你们思考数据须要能回答什么问题？在第一个例子里数据不能回答“在全部实例里每秒处理多少请求？”，但命名空间树能够。 客户端库提供命名空间能够回答：全部客户端生成的全部请求是多少？ 另一个常见的方法是经过命名空间客户端度量消费服务的名称而不是使用客户端类库自己。我发现对问题有用的是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...