虽然每个应用程序都不同，但粗略了解应该有多少指标会很有用。

当开始使用指标度量程序时，通常不确定需要有多少指标和时序，不清楚会不会太少或太多，这里想给出一些经验法则来帮助判断度量数据量是否适合给定类型的应用程序。

对于只做一件事的逻辑很少的非常简单的应用程序，预计大约100个时序

缓存是通常属于这一类的系统的一个例子，而在Prometheus生态中，Pushgateway是另一个。除了客户端库和使用的任何依赖项提供的开箱即用的各种指标之外，通常只会添加少量指标。例如Pushgateway有大约120个时序。

对于具有大量组件的复杂应用程序，预计大约1000个时序

例如，Prometheus 服务器本身目前公开了大约 700 个时序，具体取决于您使用的版本和功能。这是因为有开箱即用的时间序列，以及为各种子系统添加的所有指标。

当应用程序公开的数量超过此数量，甚至接近10,000个时序时，这表明可能存在基数问题并且需要稍微减少标签。然而，有时这在某些情况下是不可避免的，例如有很多后端服务的反向代理，或者有很多表并且您需要每个表的信息的数据库。

尽量不要超过10,000，Prometheus是为许多小抓取而设计的

说了这么多，以上内容并不意味着您应该添加新指标只是为了达到上述数字。这只是我个人对各种类型的检测良好的服务倾向于暴露的经验，因此多或少不会自动表明存在问题。这是一个参考，而不是一个目标。

设计指标的原则

可以参考如下方法，根据不同的场景设计不同的指标。

Google 四个黄金指标，更适用应用监控

1. 延迟
2. 流量
3. 错误
4. 饱和度

Netflix USE，更适用主机监控

1. 使用率
2. 饱和度
3. 错误

RED，偏重微服务应用用户体验

1. Rate，每秒请求数
2. Errors，每秒失败的请求数
3. Duration，每个请求的时长