背景
目前子业务处于打磨期，规模不大，因此监控由一个Prometheus节点管理。架构如下：
由于以下原因，目前可能不考虑高可用存储方案
业务短期不会扩量，单点基本够用
学习和运维成本，自建存储需要有专人学习和维护
使用第三方进行管理，这个经济成本比较高
基于上述背景，面对磁盘持续的增长，问题依然要解决，主要思路有以下几个方面
降低采集频率。提高Prometheus采集间隔。缺点是可能丢失故障信息，数据精度不够。
减少数据保留时间。缺点是无法分析更长时间的历史趋势。
进行指标优化。去除无效Metric或者减少高频的Metrci。
由于前两个思路有明显缺点，因此本文围绕“指标优化”的思路描述问题分析和解决的过程，问题解决主要采用自顶向下、层层分解，最终确定我们要优化的指标，当然也少不了想象力和同事的启发。
指标分析
面对百万级的Metric，应该如何快速分析出问题指标，思路如下
使用Prometheus内置的统计
使用count进行计算
进行抽样调查
Prometheus 内置统计
在Prometheus主页 -> Status -> TSDB Status 可以看到当前Prometheus的概要统计
这里会有label数量、Metric数量、Label内存占用、最多Label键值对的统计。如上图所示，排名前几的数据远大于后续的，这里我们找到了第一批可以优化的Metric和Label。
count计算
在Prometheus主页 -> Targets 可以看到我们当前所有配置的Job，使用PromQL count可以快速对采集Job有个整体的分析
count({job="xxxJob_name"})
以个人实际优化案例来看，有以下排名前几的Metric值得关注
node-exporter 977955条
kubernetes-pods 661032条
kubernetes-istio 187544条
这样进一步缩小了Metric的排查范围，确定出了大范围覆盖的采集指标后，还可以进一步编写脚本，从CMDB获取实例和采集端口，一次性批量获取各采集Target的文件大小，然后进行排序。
这里我们基本完成了覆盖范围比较大的采集指标分析。
抽样调查
由于基础资源、中间件等通用基础设施能够进行一次性分析和优化，但是业务是动态增长和变化的，因此我们需要对核心业务进行抽查。
基于对业务的理解，对重点服务的指标进行抽查，果然快速发现了异常指标，如下图所示
业务指标在分桶的设置上不合理，而且这类指标几乎出现在各个微服务上，导致大量的空间浪费，以此类推我们找到了更多这样的指标。
指标优化
Relabeling机制
指标优化主要采用了Relabeling的方式，因此先对该机制进行解析。发生在采集样本数据之前，对Target实例的标签进行重写的机制在Prometheus被称为Relabeling。
relabel有几种配置类别，需要进行重点区分
relabel_configs 针对target指标采集前和采集中的数据进行筛选。
metric_relabel_configs 针对指标采集后的数据进行筛选。
alert_relabel_configs 发送到alert manager的数据进行筛选。
注意：以drop为例，relabel_configs匹配到的数据会直接丢弃不会采集，而metric_relabel_configs是先采集过来，然后进行匹配确定丢弃的内容。
Prometheus relabel具体的语法，请参考官方文档
优化方式
通过上述分析，我们基本确定了占比最大的待优化的指标，接下来就是如何进行指标优化，结合Relabel，方式如下：
1、labeldrop
metric_relabel_configs:
- action: labeldrop
regex: "source_workload|destination_workload"
通过示例，我们用labeldrop方式将所有正则匹配到的label丢弃，减少无效label，降低存储空间
2、指标keep
relabel_configs:
- source_labels: [ '__meta_consul_service' ]
action: keep
regex: 'prometheus-postgres.*|prometheus-pgbouncer.*|prometheus-node-exporter.*'
keep的方式是只保留正则匹配的metric，其余全部丢弃，这种方式适合非常确定要保留的指标，仅保留部分指标。
3、指标drop
metric_relabel_configs:
- source_labels: [ __name__ ]
action: drop
regex: 'mtail_log_lines_total'
keep的方式是丢弃正则匹配的metric，保留其余指标，这种方式适合确定要优化的指标，仅优化部分指标。
4、业务针对优化
如上文所述的“业务对于桶的设置不合理”的现象，通过与研发沟通，调整common库的Prometheus部分初始化逻辑，快速减少了无效指标。
总结
关于指标分析，以后会朝着“自动化采集管理分析”方向演进，前期重点集中于以下几个方面
Prometheus 内部统计所展示的异常指标
机器资源或者k8s这类大范围覆盖的指标
重点业务指标抽查
关于指标优化主要采用官方的Relabel方式进行优化。Prometheus后续架构可演进的建议如下：
采集和报警的Prometheus进行分离，采集需要保存更长周期的数据进行展示，报警则更关注精度和实时性，分离后能节省更多的空间。
采用固定Hash的方式管理Prometheus集群。这种方式管理成本比较低，仅用少量的开发就能支持集群的配置管理，并且支持大规模的业务采集，缺点是故障处理和扩展性不足。
采用一致性Hash和采集配置自动迁移。这种方式开发成本比较高，不过可靠性和可维护性有了比较大的提升。
使用第三方进行管理，比如TimescaleDB、M3DB、TiKV、Thanos、Kvass、Victoria，不过个人更倾向来自同一个公司下的解决方案Cortex
不管用什么方案，总之指标的持续治理是不可避免的，有其他方式的欢迎多多交流。
