别再乱用 Prometheus 联邦了，分享一个 Prometheus 高可用新方案

2021年6月12日 361点热度 0人点赞 0条评论

作者 | 浪子燕青燕小乙

来源 | https://zhuanlan.zhihu.com/p/368868988

前言

我看到很多人会这样使用联邦：联邦 prometheus 收集多个采集器的数据
实在看不下下去了，很多小白还在乱用prometheus的联邦
其实很多人是想实现 prometheus 数据的可用性，数据分片保存，有个统一的查询地方(小白中的联邦 prometheus)
而且引入 m3db 等支持集群的 tsdb 可能比较重
具体问题可以看我之前写的文章 m3db 资源开销，聚合降采样，查询限制等注意事项[1]

m3db-node oom 追踪和内存分配器代码查看[2]

今天写篇文章分析下联邦的问题，并给出一个基于全部是 prometheus 的multi_remote_read方案

架构图

腾讯试点强制6点下班！标志着反996、反内卷的第一枪吗？

联邦问题

联邦文档地址[3]

联邦使用样例

本质上就是采集级联
说白了就是 a 从 b,c,d 那里再采集数据过来
可以搭配 match 指定只拉取某些指标
下面就是官方文档给出的样例

scrape_configs:
  - job_name: 'federate'
    scrape_interval: 15s

    honor_labels: true
    metrics_path: '/federate'

    params:
      'match[]':
        - '{job="prometheus"}'
        - '{__name__=~"job:.*"}'

    static_configs:
      - targets:
        - 'source-prometheus-1:9090'
        - 'source-prometheus-2:9090'
        - 'source-prometheus-3:9090'

看上面的样例配置怎么感觉是采集的配置呢

不用怀疑就是，下面看看代码分析一下从上述配置可以看到采集的 path 是 /federate

// web.go 的 federate Handler
    router.Get("/federate", readyf(httputil.CompressionHandler{
        Handler: http.HandlerFunc(h.federation),
    }.ServeHTTP))

分析下联邦函数说白了就是读取本地存储数据处理

func (h *Handler) federation(w http.ResponseWriter, req *http.Request) {

    // localstorage 的query
    q, err := h.localStorage.Querier(req.Context(), mint, maxt)

    defer q.Close()
    // 最终发送的Vector 数组
    vec := make(promql.Vector, 0, 8000)

    hints := &storage.SelectHints{Start: mint, End: maxt}

    var sets []storage.SeriesSet

    set := storage.NewMergeSeriesSet(sets, storage.ChainedSeriesMerge)
    // 遍历存储中的full series
    for set.Next() {
        s := set.At()


        vec = append(vec, promql.Sample{
            Metric: s.Labels(),
            Point:  promql.Point{T: t, V: v},
        })

    for _, s := range vec {
        nameSeen := false
        globalUsed := map[string]struct{}{}
        protMetric := &dto.Metric{
            Untyped: &dto.Untyped{},
        }
        // Encode方法根据请求类型编码
                if protMetricFam != nil {
                    if err := enc.Encode(protMetricFam); err != nil {
                        federationErrors.Inc()
                        level.Error(h.logger).Log("msg", "federation failed", "err", err)
                        return
                    }
                }

        }

        protMetric.TimestampMs = proto.Int64(s.T)
        protMetric.Untyped.Value = proto.Float64(s.V)

        protMetricFam.Metric = append(protMetricFam.Metric, protMetric)
    }
    //
    if protMetricFam != nil {
        if err := enc.Encode(protMetricFam); err != nil {
            federationErrors.Inc()
            level.Error(h.logger).Log("msg", "federation failed", "err", err)
        }
    }
}

最终调用压缩函数压缩

type CompressionHandler struct {
    Handler http.Handler
}

// ServeHTTP adds compression to the original http.Handler's ServeHTTP() method.
func (c CompressionHandler) ServeHTTP(writer http.ResponseWriter, req *http.Request) {
    compWriter := newCompressedResponseWriter(writer, req)
    c.Handler.ServeHTTP(compWriter, req)
    compWriter.Close()
}

如果没有过滤那么只是一股脑把分片的数据集中到了一起，没意义。很多时候是因为数据量太大了，分散在多个采集器的数据是不能被一个联邦消化的。

正确使用联邦的姿势

使用 match 加过滤，将采集数据分位两类
第一类需要再聚合的数据，通过联邦收集在一起

只收集中间件的数据的联邦只收集业务数据的联邦
举个例子
其余数据保留在采集器本地即可

这样可以在各个联邦上执行预聚合和alert，使得查询速度提升

默认 prometheus 不支持降采样

可以在联邦配置 scrape_interval 的时候设置的大一点来达到模拟降采样的目的
真实的降采样需要 agg 算法支持的，比如 5 分钟的数据算平均值、最大值、最小值保留，而不是这种把采集间隔调大到 5 分钟的随机选点逻辑

正确实现统一查询的姿势

什么是 remote_read

简单说就是 prometheus 意识到自己本地存储不具备高可用性，所以通过支持第三方存储来补足这点的手段
配置文档地址[4]

读写都支持的存储

AWS Timestream
Azure Data Explorer
Cortex
CrateDB
Google BigQuery
Google Cloud Spanner
InfluxDB[5]
IRONdb
M3DB[6]
PostgreSQL/TimescaleDB
QuasarDB
Splunk
Thanos
TiKV

但是这个和我们今天聊的问题关联在哪里?，往下看你就知道了

multi_remote_read

如果我们配置了多个 remote_read 接口的话即可实现 multi

remote_read:
  - url: "http://172.20.70.205:9090/api/v1/read"
    read_recent: true
  - url: "http://172.20.70.215:9090/api/v1/read"
    read_recent: true

上述配置代表并发查询两个后端存储，并可以对查询的结果进行 merge

merge 有啥用：你们的查询 promql 或者 alert 配置文件就无需关心数据到底存储在哪个存储里面，可以直接使用全局的聚合函数