如果看下Prometheus给的例子，Use Labels

To give you a better idea of the underlying numbers, let's look at node_exporter. node_exporter exposes 
metrics for every mounted filesystem. Every node will have in the tens of timeseries for, say, 
node_filesystem_avail. If you have 10,000 nodes, you will end up with roughly 100,000 timeseries for 
node_filesystem_avail, which is fine for Prometheus to handle.

If you were to now add quota per user, you would quickly reach a double digit number of millions with 
10,000 users on 10,000 nodes. This is too much for the current implementation of Prometheus. Even 
with smaller numbers, there's an opportunity cost as you can't have other, potentially more useful 
metrics on this machine any more.

他说，对于指标 node_filesystem_avail ，一万台机器，每个机器会有10个数据点，总共10万个点，Prometheus完全能处理。但是如果要采集每个人的配额，1万个人，在1万台机器上的配合，那么就会有1亿个数据点，这个量级就搞不定了。

当然了，他说的是用label，而不是每个流一个metric指标，一般指标也就几十个，不能成百上千个：

As a general guideline, try to keep the cardinality of your metrics below 10, and for metrics that exceed 
that, aim to limit them to a handful across your whole system. The vast majority of your metrics should 
have no labels.

For example, rather than http_responses_500_total and http_responses_403_total, create a single metric 
called http_responses_total with a code label for the HTTP response code. You can then process the entire 
metric as one in rules and graphs.

如果要对metric指标分类，应该用label标签。比如不应该定义 http_responses_500_total 和 http_responses_403_total 两个指标，而应该是一个指标 http_responses_total ，加上一个 code 标签。

不知道你Prometheus有性能问题，有多少机器？多少路流？指标(metric)如何定义的？标签(label)如何定义的？

这种场景：

1. 几千路的流，10 秒钟采集一次数据
2. 对每个正在播放的流采集 metric， 同时对每个流，增加几个不同的 label。
   label 1 这个流的stream id
   label 2 这个流的 播放的开始时间
   label 3 这个流的 结束时间
   label 4 这个流的其他指标。。。
3. prometheus 单机部署，保存 15天的数据，通过 grafana 进行展示

在这种场景下， 最后通过 grafana 进行汇聚， 需要通过不同的 label 进行匹配和过滤（例如 通过streamid 的label 查询某个流所有的数据， 查询所有某个时间段的流，查询 所有网络不好的的流，查询推流端有频繁重连的流），是否会遇到性能问题 ？

Prometheus的指标一般是可聚合的比较合适，比如开始时间和结束时间就不太适合存在Prometheus，这些适合存储在 ELK 等日志系统中，或者 APM/Trace ，使用这些系统进行处理和过滤后也可通过Grafana展示，具体可以看这个文章 Metrics, tracing, and logging 。

一般来说，Prometheus属于Metrics，也就是告警，会对很多指标进行聚合，这样存储的数据会比较少。比如流出现问题的告警，应该是采集流的错误数这个指标，聚合成全网的正常的流和异常的流。

查询某个时间段的流，或者是网络不好的流，这些更多是数据分析(ELK或APM)做的事情。也就是运维系统，不能只有一个告警/Prometheus/Metrics，会导致过度使用，也必然会导致它负载过高，查询起来很慢。

加我微信聊下？我们正在设计SRS官方的Exporter，欢迎一起参与。