我们有许多Prometheus服务器，每个服务器监视自己的区域（实际上每个区域监视2个），还有thanos服务器可以查询多个区域，并且我们还使用alertmanager进行警报。
最近，我们遇到了一个问题，即几乎没有停止报告的指标，只有在需要指标时才发现它。 我们正在尝试找出如何监视可伸缩系统中报告的指标数量变化的情况，该变化会根据需要而增加和缩小。
我很高兴收到您的建议。
答案 0 :(得分：0)
您可以计算起始数据块中的时间序列数（最近0-2小时），也可以计算摄取样本的速率：
prometheus_tsdb_head_series
或
rate(prometheus_tsdb_head_samples_appended_total[5m])
然后，您在几分钟/几小时前将所述值与自身进行比较，例如
prometheus_tsdb_head_series / prometheus_tsdb_head_series offset 5m
查看其是否在预期范围内（例如90-110％），否则发出警报。
或者您也可以只查看基数最高的指标：
topk(100, count({__name__=~".+"}) by (__name__))
但是请注意，最后一个表达式的计算成本可能很高，因此您可能要避免使用它。再加上与5分钟前的比较并不是那么简单：
label_replace(topk(100, count({__name__=~".+"}) by (__name__)), "metric", "$1", "__name__", "(.*)")
/
label_replace(count({__name__=~".+"} offset 5m) by (__name__), "metric", "$1", "__name__", "(.*)")
您需要在那里的label_replace，因为除法匹配是在__name__以外的标签上完成的。在我的150k系列Prometheus实例上，计算此最新表达式需要10秒钟左右，因此速度很快。
最后，无论您选择哪种方法，您都可能会得到很多误报（无论开始或撤消一项繁重的工作），以至于用处不大。我个人不会尝试。