Prometheus hashmod 配置引數詳解

smallfish1發表於2018-03-08
Prometheus

今天有朋友在群裡問了一段關於 Prometheus hashmod 配置的問題，如圖：

config01.png

此配置出自 Brian 的部落格 scaling-and-federating-prometheus。

那這段配置到底是什麼意思？因為以前沒用過這個配置，所以只好去翻看原始碼。

核心原始碼解讀

閱讀的過程中，發現 relabel.go#L41 的程式碼與配置非常相關：

func relabel(lset labels.Labels, cfg *config.RelabelConfig) labels.Labels {
    values := make([]string, 0, len(cfg.SourceLabels))
    for _, ln := range cfg.SourceLabels {
        values = append(values, lset.Get(string(ln)))
    }
    val := strings.Join(values, cfg.Separator)

    lb := labels.NewBuilder(lset)

    switch cfg.Action {
    // 此處省略程式碼
    // 判斷值是否匹配，如果不匹配那麼將放棄此 target
    case config.RelabelKeep:
        if !cfg.Regex.MatchString(val) {
            return nil
        }
    // 對欄位 source_labels 的值進行 md5 和取餘，並將結果存到自定義目標欄位中
    case config.RelabelHashMod:
        mod := sum64(md5.Sum([]byte(val))) % cfg.Modulus
        lb.Set(cfg.TargetLabel, fmt.Sprintf("%d", mod))
    // 此處省略程式碼
    default:
        panic(fmt.Errorf("relabel: unknown relabel action type %q", cfg.Action))
    }

    return lb.Labels()
}

有了程式碼參考，一開始的配置就容易理解了，它的邏輯為：

  1. 配置的第一個 souce_labels 是對同一個任務抓取目標的 LabelSet 進行預處理，具體而言就是將抓取目標地址進行 hashmod, 並將 hashmod 的值存到一個自定義欄位 __tmp_hash 中。
  2. 配置的第二個 souce_labels 對預處理後的抓取目標進行篩選，只選取 __tmp_hash 值滿足正則匹配的，例子中 hashmod != 1 將全部被忽略。

通過以上兩步，就非常容易對相同 job 的抓取目標進行雜湊，從而抓取命中的部分。

雜湊均衡性測試

抓取目標的雜湊是否足夠均衡呢？

下面是根據 Prometheus 的 mod 計算方法編寫的一段測試程式碼：

package main

import (
    "crypto/md5"
    "fmt"
)

func main() {
    nodes := []string{
        "192.168.1.1:9090", "192.168.1.2:9090", "192.168.1.3:9090", "192.168.1.4:9090", "192.168.1.5:9090",
        "192.168.1.6:9090", "192.168.1.7:9090", "192.168.1.8:9090", "192.168.1.9:9090", "192.168.1.10:9090",        
    }

    for _, ip := range nodes {
       mod := sum64(md5.Sum([]byte(ip))) % 3
       fmt.Printf("%s mode is %d \n", ip, mod)
    }

}

func sum64(hash [md5.Size]byte) uint64 {
    var s uint64

    for i, b := range hash {
        shift := uint64((md5.Size - i - 1) * 8)

        s |= uint64(b) << shift
    }
    return s
}

輸出結果為：

192.168.1.1:9090 mode is 3
192.168.1.2:9090 mode is 1
192.168.1.3:9090 mode is 0
192.168.1.4:9090 mode is 0
192.168.1.5:9090 mode is 1
192.168.1.6:9090 mode is 2
192.168.1.7:9090 mode is 3
192.168.1.8:9090 mode is 1
192.168.1.9:9090 mode is 1
192.168.1.10:9090 mode is 1

可以看到，當目標地址足夠多的時候，還是能夠滿足均勻雜湊。

配置的意義

以前在文章 Prometheus 叢集方案之 remote read 實戰 中已經介紹過按照業務將 Prometheus server 拆分成的思路，即便如此，有些資料（比如一個機房的所有機器資訊）還是特別大，超過了單機承載能力。

此時我們可以採用 hashmod 配置，使用同樣的配置列表，將抓取目標雜湊到不同的 Prometheus server 中去, 從而很好實現 Prometheus 資料收集的橫向擴充套件。

更多閱讀，請關注

相關文章