云原生報(bào)警背景現(xiàn)狀

在云原生的生態(tài)下，kubernetes 已經(jīng)被越來(lái)越多地應(yīng)用到公司實(shí)際生產(chǎn)環(huán)境中。在這樣的生態(tài)環(huán)境下系統(tǒng)監(jiān)控、業(yè)務(wù)監(jiān)控和數(shù)據(jù)庫(kù)監(jiān)控指標(biāo)都需要在第一時(shí)間獲取到，目前用的最多的也是prometheus、exporter、grafana、alertmanager這幾個(gè)軟件組建起來(lái)構(gòu)建自己的監(jiān)控系統(tǒng)。以上這幾款軟件組建監(jiān)控系統(tǒng)比較容易?？墒窃诟婢@一環(huán)節(jié)，只能依靠終端vim來(lái)編輯規(guī)則文件。今天給大家推薦一款可以可視化操作的告警軟件，這個(gè)軟件是將prometheus和alertmanager進(jìn)行了結(jié)合可以把數(shù)據(jù)分散存儲(chǔ)起來(lái)，通過(guò)可視化的操作添加 prometheus 告警規(guī)則，這個(gè)軟件就是 grafana 公司開(kāi)發(fā)的mimir。

Mimir 是做什么的

Mimir 為 prometheus 提供水平可擴(kuò)展、高度可用、多租戶(hù)的長(zhǎng)期存儲(chǔ)。它的工作架構(gòu)如下圖展示：

Mimir 架構(gòu)

存儲(chǔ) Prometheus metrics 使用 Prometheus 從應(yīng)用程序中提取指標(biāo)，并將這些指標(biāo)遠(yuǎn)程寫(xiě)入 Mimir，或者使用 Grafana Agent、PrometheusAgent 或其他 Prometheus 遠(yuǎn)程寫(xiě)入兼容軟件直接發(fā)送數(shù)據(jù)。

擴(kuò)展性強(qiáng) Mimir 群集不需要手動(dòng)進(jìn)行切分、復(fù)制或重新平衡。要增加容量，只需向集群添加新實(shí)例。

在 grafana 中可視化 Mimir 允許用戶(hù)運(yùn)行查詢(xún)，通過(guò)記錄規(guī)則創(chuàng)建新數(shù)據(jù)，并利用租戶(hù)聯(lián)合在多個(gè)租戶(hù)之間設(shè)置警報(bào)規(guī)則。所有這一切都可以與 Grafana 儀表盤(pán)聯(lián)系在一起。

Mimir 組件都有哪些，它們是做什么的？

以上列舉出了 Mimir 的一些組件，下面介紹一下它們分別是做什么的

Compactor（數(shù)據(jù)壓縮器，無(wú)狀態(tài)應(yīng)用）

compactor 通過(guò)組合塊提高查詢(xún)性能并減少長(zhǎng)期存儲(chǔ)使用。負(fù)責(zé)以下工作：

將給定租戶(hù)的多個(gè)數(shù)據(jù)塊壓縮為單個(gè)優(yōu)化的較大數(shù)據(jù)塊。這可以消除數(shù)據(jù)塊并減小索引的大小，從而降低存儲(chǔ)成本。查詢(xún)更少的塊更快，因此也提高了查詢(xún)速度。

保持每租戶(hù)的數(shù)據(jù)存儲(chǔ)桶索引更新，存儲(chǔ)桶索引被queriers、store-gateway和rulers使用，用來(lái)發(fā)現(xiàn)數(shù)據(jù)中新增加的數(shù)據(jù)塊和刪除數(shù)據(jù)塊

刪除那些不再在可配置保留期內(nèi)的數(shù)據(jù)塊。

工作原理

按租戶(hù)以固定、可配置時(shí)間間隔進(jìn)行數(shù)據(jù)塊壓縮。垂直壓縮將接收器在同一時(shí)間范圍（默認(rèn)情況下為 2 小時(shí)內(nèi)）上傳的租戶(hù)的所有塊合并到單個(gè)塊中。它還對(duì)最初由于復(fù)制而寫(xiě)入 N 個(gè)塊的樣本執(zhí)行重復(fù)數(shù)據(jù)消除。垂直壓縮減少了單個(gè)時(shí)間范圍內(nèi)的塊數(shù)。垂直壓縮后觸發(fā)水平壓縮。它將幾個(gè)具有相鄰范圍周期的塊壓縮為一個(gè)較大的塊。水平壓縮后，關(guān)聯(lián)塊塊的總大小不變。水平壓縮可以顯著減小存儲(chǔ)網(wǎng)關(guān)保存在內(nèi)存中的索引和索引頭的大小。如下圖：

壓縮器

縮放

可以針對(duì)具有大型租戶(hù)的集群調(diào)整壓縮。配置指定了壓縮程序在按租戶(hù)壓縮時(shí)如何運(yùn)行的垂直和水平縮放。垂直縮放：-compactor.compaction-concurrency選項(xiàng)配置了單個(gè)壓縮實(shí)例中運(yùn)行的最大并發(fā)壓縮數(shù)。每次壓縮使用一個(gè) CPU 內(nèi)核。水平縮放：默認(rèn)情況下，租戶(hù)區(qū)塊可以使用任何 Mimir 進(jìn)行數(shù)據(jù)壓縮。當(dāng)通過(guò)將-compactor.compactor-tenant-shard-size(或其相應(yīng)的 YAML 配置選項(xiàng)）設(shè)置為大于 0 且小于可用 compactors 實(shí)例數(shù)量的值來(lái)啟用壓縮隨機(jī)分片時(shí)，僅指定 compactor 的數(shù)量才有資格為給定的租戶(hù)壓縮數(shù)據(jù)塊。

壓縮算法

Mimir 使用了一種稱(chēng)為拆分和合并的復(fù)雜壓縮算法。通過(guò)設(shè)計(jì)，拆分和合并算法克服了時(shí)間序列數(shù)據(jù)庫(kù)（TSDB）索引的局限性，并且它避免了壓縮塊在任何壓縮階段對(duì)一個(gè)非常大的租戶(hù)無(wú)限期增長(zhǎng)的情況。這種壓縮策略是一個(gè)兩階段的過(guò)程：拆分和合并，默認(rèn)配置禁用拆分階段。

拆分階段第一級(jí)是壓縮。例如：2 小時(shí)內(nèi) compactor 將所有源數(shù)據(jù)庫(kù)分割成 N 個(gè)組（通過(guò)-compactor.split-groups設(shè)置）。對(duì)待每一個(gè)組 compactor 壓縮數(shù)據(jù)塊而不是生成單個(gè)的結(jié)果塊，輸出 M 個(gè)分割塊（通過(guò)-compactor.split-and-merge-shards設(shè)置）。每個(gè)分割塊只包含了屬于 M 碎片中給定碎片的序列子集。在分割階段結(jié)束時(shí)，compactor 會(huì)參考?jí)K文件（meta.json）中各自碎片信息的引用來(lái)產(chǎn)生N*M個(gè)數(shù)據(jù)塊。Compactor 合并每個(gè)碎片的分割塊，將壓縮給定碎片的所有 N 個(gè)分割塊。合并將塊數(shù)從N*M減少到M。對(duì)于給定的壓縮時(shí)間范圍，每個(gè) M 碎片都將有一個(gè)壓縮塊。如下圖所展示的說(shuō)明

壓縮共享

Compactor 將來(lái)自單租戶(hù)或者多租戶(hù)的壓縮作業(yè)進(jìn)行碎片化處理。單個(gè)租戶(hù)的壓縮可以由多個(gè)壓縮器實(shí)例分割和處理。無(wú)論壓縮器實(shí)例的數(shù)量何時(shí)增加或減少，租戶(hù)和任務(wù)崗位都會(huì)在可用壓縮器實(shí)例中重新分配，而無(wú)需任何手動(dòng)干預(yù)。壓縮器使用哈希環(huán)進(jìn)行分片。在啟動(dòng)時(shí)，壓縮器生成隨機(jī)令牌并將自身注冊(cè)到壓縮器哈希環(huán)。在運(yùn)行時(shí)，它每隔一段時(shí)間（通過(guò)-compactor.compaction-interval-compactor.compaction-interval設(shè)置）定期掃描存儲(chǔ)桶，以發(fā)現(xiàn)每個(gè)租戶(hù)的存儲(chǔ)和壓縮塊中的租戶(hù)列表，這些租戶(hù)的哈希與哈希環(huán)中分配給實(shí)例本身的令牌范圍相匹配。

阻止刪除

成功壓縮后，將從存儲(chǔ)中刪除原始?jí)K。塊刪除不是立即進(jìn)行的；它遵循兩步過(guò)程：

1.原始?jí)K標(biāo)記為刪除；這是軟刪除

2.一旦一個(gè)塊被標(biāo)記為刪除的時(shí)間超過(guò)了可配置壓實(shí)機(jī)的時(shí)間。刪除延遲，從存儲(chǔ)器中刪除塊；這是一個(gè)硬刪除。

壓縮器負(fù)責(zé)標(biāo)記塊和硬刪除。軟刪除基于存儲(chǔ)在 bucket 中塊位置中的一個(gè)小文件（deletion-mark.json）。成功壓縮后，將從存儲(chǔ)中刪除原始?jí)K。塊刪除不是立即進(jìn)行的；它遵循兩步過(guò)程：1.原始?jí)K標(biāo)記為刪除；這是軟刪除 2.一旦一個(gè)塊被標(biāo)記為刪除的時(shí)間超過(guò)了可配置壓實(shí)機(jī)的時(shí)間。刪除延遲，從存儲(chǔ)器中刪除塊；這是一個(gè)硬刪除。

壓實(shí)機(jī)負(fù)責(zé)標(biāo)記塊和硬刪除。軟刪除基于存儲(chǔ)在 bucket 中塊位置中的一個(gè)小文件。軟刪除機(jī)制為queriers,rulers和store-gateways提供了時(shí)間，以便在刪除原始?jí)K之前發(fā)現(xiàn)新的壓縮塊。如果這些原始?jí)K被立即硬刪除，則涉及壓縮塊的某些查詢(xún)可能會(huì)暫時(shí)失敗或返回部分結(jié)果。

distributor（數(shù)據(jù)分發(fā)器）

分發(fā)服務(wù)器是一個(gè)無(wú)狀態(tài)組件，從 Prometheus 或 Grafana 代理接收時(shí)間序列數(shù)據(jù)。分發(fā)服務(wù)器驗(yàn)證數(shù)據(jù)的正確性，并確保數(shù)據(jù)在給定租戶(hù)的配置限制內(nèi)。然后，分發(fā)服務(wù)器將數(shù)據(jù)分為多個(gè)批次，并將其并行發(fā)送給多個(gè)接收程序，在接收程序之間切分序列，并通過(guò)配置的復(fù)制因子復(fù)制每個(gè)序列。默認(rèn)情況下，配置的復(fù)制因子為 3。

工作原理

驗(yàn)證

分發(fā)服務(wù)器在將數(shù)據(jù)寫(xiě)入 ingester 之前驗(yàn)證其接收的數(shù)據(jù)。因?yàn)閱蝹€(gè)請(qǐng)求可以包含有效和無(wú)效的度量、樣本、元數(shù)據(jù)和樣本，所以分發(fā)服務(wù)器只將有效數(shù)據(jù)傳遞給 ingester。分發(fā)服務(wù)器在其對(duì)接收程序的請(qǐng)求中不包含無(wú)效數(shù)據(jù)。如果請(qǐng)求包含無(wú)效數(shù)據(jù)，分發(fā)服務(wù)器將返回 400 HTTP 狀態(tài)代碼，詳細(xì)信息將顯示在響應(yīng)正文中。關(guān)于第一個(gè)無(wú)效數(shù)據(jù)的詳細(xì)信息無(wú)論是普羅米修斯還是格拉夫納代理通常由發(fā)送方記錄。分發(fā)器驗(yàn)證包括以下檢查：

度量元數(shù)據(jù)和標(biāo)簽符合普羅米修斯公開(kāi)格式。

度量元數(shù)據(jù)（名稱(chēng)、幫助和單位）的長(zhǎng)度不超過(guò)通過(guò)validation.max-metadata-length定義的長(zhǎng)度

每個(gè)度量的標(biāo)簽數(shù)不高于-validation.max-label-names-per-series

每個(gè)度量標(biāo)簽名稱(chēng)不得長(zhǎng)于-validation.max-length-label-name

每個(gè)公制標(biāo)簽值不長(zhǎng)于-validation.max-length-label-value

每個(gè)樣本時(shí)間戳都不晚于-validation.create-grace-period

每個(gè)示例都有一個(gè)時(shí)間戳和至少一個(gè)非空標(biāo)簽名稱(chēng)和值對(duì)。

每個(gè)樣本不超過(guò) 128 個(gè)標(biāo)簽。

速率限制

分發(fā)器包括適用于每個(gè)租戶(hù)的兩種不同類(lèi)型的費(fèi)率限制。

請(qǐng)求速率每個(gè)租戶(hù)每秒可以跨 Grafana Mimir 集群處理的最大請(qǐng)求數(shù)。

接受速率每個(gè)租戶(hù)在 Grafana Mimir 集群中每秒可接收的最大樣本數(shù)。如果超過(guò)其中任何一個(gè)速率，分發(fā)服務(wù)器將丟棄請(qǐng)求并返回 HTTP 429 響應(yīng)代碼。

在內(nèi)部，這些限制是使用每個(gè)分發(fā)器的本地速率限制器實(shí)現(xiàn)的。每個(gè)分發(fā)服務(wù)器的本地速率限制器都配置了limit/N，其中 N 是正常分發(fā)服務(wù)器副本的數(shù)量。如果分發(fā)服務(wù)器副本的數(shù)量發(fā)生變化，分發(fā)服務(wù)器會(huì)自動(dòng)調(diào)整請(qǐng)求和接收速率限制。因?yàn)檫@些速率限制是使用每個(gè)分發(fā)服務(wù)器的本地速率限制器實(shí)現(xiàn)的，所以它們要求寫(xiě)入請(qǐng)求在分發(fā)服務(wù)器池中均勻分布。可以通過(guò)下面的這幾個(gè)參數(shù)進(jìn)行限制：

-distributor.request-rate-limit

-distributor.request-burst-size

-distributor.ingestion-rate-limit

-distributor.ingestion-burst-size

高可用跟蹤器

遠(yuǎn)程寫(xiě)發(fā)送器（如 Prometheus）可以成對(duì)配置，這意味著即使其中一個(gè)遠(yuǎn)程寫(xiě)發(fā)送機(jī)停機(jī)進(jìn)行維護(hù)或由于故障而不可用，度量也會(huì)繼續(xù)被擦除并寫(xiě)入 Grafana Mimir。我們將此配置稱(chēng)為高可用性（HA）對(duì)。分發(fā)服務(wù)器包括一個(gè) HA 跟蹤器。啟用 HA 跟蹤器后，分發(fā)服務(wù)器會(huì)對(duì)來(lái)自 Prometheus HA 對(duì)的傳入序列進(jìn)行重復(fù)數(shù)據(jù)消除。這使您能夠擁有同一 Prometheus 服務(wù)器的多個(gè) HA 副本，將同一系列寫(xiě)入 Mimir，然后在 Mimir 分發(fā)服務(wù)器中對(duì)該系列進(jìn)行重復(fù)數(shù)據(jù)消除。

切分和復(fù)制

分發(fā)服務(wù)器在 ingester 之間切分和復(fù)制傳入序列。您可以通過(guò)-ingester.ring.replication-factor配置每個(gè)系列寫(xiě)入的攝取器副本的數(shù)量。復(fù)制因子默認(rèn)為 3。分發(fā)者使用一致哈希和可配置的復(fù)制因子來(lái)確定哪些接收者接收給定序列。切分和復(fù)制使用 ingester 的哈希環(huán)。對(duì)于每個(gè)傳入的序列，分發(fā)服務(wù)器使用度量名稱(chēng)、標(biāo)簽和租戶(hù) ID 計(jì)算哈希。計(jì)算的哈希稱(chēng)為令牌。分發(fā)服務(wù)器在哈希環(huán)中查找令牌，以確定向哪個(gè)接收程序?qū)懭胄蛄小?/p>

仲裁一致性

因?yàn)榉职l(fā)服務(wù)器共享對(duì)同一哈希環(huán)的訪問(wèn)，所以可以向任何分發(fā)服務(wù)器發(fā)送寫(xiě)請(qǐng)求。您還可以在它前面設(shè)置一個(gè)無(wú)狀態(tài)負(fù)載平衡器。為了確保一致的查詢(xún)結(jié)果，Mimir 在讀寫(xiě)操作上使用了 Dynamo 風(fēng)格的仲裁一致性。分發(fā)服務(wù)器等待 n/2+1 接收程序的成功響應(yīng)，其中 n 是配置的復(fù)制因子，然后發(fā)送對(duì) Prometheus 寫(xiě)入請(qǐng)求的成功響應(yīng)。

分發(fā)器之間的負(fù)載平衡

在分發(fā)服務(wù)器實(shí)例之間隨機(jī)進(jìn)行負(fù)載平衡寫(xiě)入請(qǐng)求。如果在 Kubernetes 集群中運(yùn)行 Mimir，可以將 KubernetesService 定義為分發(fā)器的入口。

ingester（數(shù)據(jù)接收器）

接收程序是一個(gè)有狀態(tài)組件，它將傳入序列寫(xiě)入長(zhǎng)期存儲(chǔ)的寫(xiě)路徑，并返回讀取路徑上查詢(xún)的序列樣本。

工作原理

來(lái)自分發(fā)服務(wù)器的傳入序列不會(huì)立即寫(xiě)入長(zhǎng)期存儲(chǔ)，而是保存在接收服務(wù)器內(nèi)存中或卸載到接收服務(wù)器磁盤(pán)。最終，所有系列都會(huì)寫(xiě)入磁盤(pán)，并定期（默認(rèn)情況下每?jī)尚r(shí)）上傳到長(zhǎng)期存儲(chǔ)。因此，查詢(xún)器可能需要在讀取路徑上執(zhí)行查詢(xún)時(shí)，從接收器和長(zhǎng)期存儲(chǔ)中獲取樣本。任何調(diào)用接收器的 Mimir 組件都首先查找哈希環(huán)中注冊(cè)的接收器，以確定哪些接收器可用。每個(gè)接收器可能處于以下?tīng)顟B(tài)之一：

pending

joining

active

leaving

unhealthy

寫(xiě)放大

Ingers 將最近收到的樣本存儲(chǔ)在內(nèi)存中，以便執(zhí)行寫(xiě)放大。如果接收器立即將收到的樣本寫(xiě)入長(zhǎng)期存儲(chǔ)，由于長(zhǎng)期存儲(chǔ)的高壓，系統(tǒng)將很難縮放。由于這個(gè)原因，接收器在內(nèi)存中對(duì)樣本進(jìn)行批處理和壓縮，并定期將它們上傳到長(zhǎng)期存儲(chǔ)。寫(xiě)反放大是 Mimir 低總體擁有成本（TCO）的主要來(lái)源。

接收失敗和數(shù)據(jù)丟失

如果接收程序進(jìn)程崩潰或突然退出，則所有尚未上載到長(zhǎng)期存儲(chǔ)的內(nèi)存中序列都可能丟失。有以下方法可以緩解這種故障模式：

Replication

Write-ahead log (WAL)

Write-behind log (WBL), out-of-order 啟用時(shí)

區(qū)域感知復(fù)制

區(qū)域感知復(fù)制可確保給定時(shí)間序列的接收副本跨不同的區(qū)域進(jìn)行劃分。分區(qū)可以表示邏輯或物理故障域，例如，不同的數(shù)據(jù)中心?？缍鄠€(gè)區(qū)域劃分副本可防止在整個(gè)區(qū)域發(fā)生停機(jī)時(shí)發(fā)生數(shù)據(jù)丟失和服務(wù)中斷。

無(wú)序切分

亂序切分可以用來(lái)減少多個(gè)租戶(hù)對(duì)彼此的影響。

無(wú)序樣本接收

默認(rèn)情況下會(huì)丟棄無(wú)序樣本。如果將樣本寫(xiě)入 Mimir 的系統(tǒng)產(chǎn)生無(wú)序樣本，您可以啟用此類(lèi)樣本的接收。

querier（查詢(xún)器）

查詢(xún)器是一個(gè)無(wú)狀態(tài)組件，它通過(guò)在讀取路徑上獲取時(shí)間序列和標(biāo)簽來(lái)評(píng)估 PromQL 表達(dá)式，使用存儲(chǔ)網(wǎng)關(guān)組件查詢(xún)長(zhǎng)期存儲(chǔ)，使用接收組件查詢(xún)最近寫(xiě)入的數(shù)據(jù)。

工作原理

為了在查詢(xún)時(shí)查找正確的塊，查詢(xún)器需要一個(gè)關(guān)于長(zhǎng)期存儲(chǔ)中存儲(chǔ)桶的最新視圖。查詢(xún)器只需要來(lái)自 bucket 的元數(shù)據(jù)信息的，元數(shù)據(jù)包括塊內(nèi)樣本的最小和最大時(shí)間戳。查詢(xún)器執(zhí)行以下操作之一，以確保更新 bucket 視圖：

定期下載 bucket 索引（默認(rèn)）

定期掃描 bucket

Bucket 索引已啟用（默認(rèn)）

當(dāng)查詢(xún)器收到給定租戶(hù)的第一個(gè)查詢(xún)時(shí)，它會(huì)對(duì) bucket 索引進(jìn)行懶下載。查詢(xún)器將 bucket 索引緩存在內(nèi)存中，并定期更新。bucket 索引包含租戶(hù)的塊列表和塊刪除標(biāo)記。查詢(xún)器稍后使用塊列表和塊刪除標(biāo)記來(lái)定位給定查詢(xún)需要查詢(xún)的塊集。當(dāng)查詢(xún)器在啟用 bucket 索引的情況下運(yùn)行時(shí)，查詢(xún)器的啟動(dòng)時(shí)間和對(duì)對(duì)象存儲(chǔ)的 API 調(diào)用量都會(huì)減少。我們建議您保持啟用 bucket 索引。

Bucket 索引已禁用

當(dāng)禁用 bucket 索引時(shí)，查詢(xún)器會(huì)迭代存儲(chǔ) bucket 以發(fā)現(xiàn)所有租戶(hù)的塊，并下載每個(gè)塊的 meta.json 文件。在這個(gè)初始 bucket 掃描階段，查詢(xún)器無(wú)法處理傳入的查詢(xún)，其/ready ready 探測(cè)端點(diǎn)將不會(huì)返回 HTTP 狀態(tài)代碼 200。運(yùn)行時(shí)，查詢(xún)器定期迭代存儲(chǔ)桶以發(fā)現(xiàn)新的租戶(hù)和最近上載的塊。

查詢(xún)請(qǐng)求解析

連接到存儲(chǔ)網(wǎng)關(guān)

連接到接收器

支持元數(shù)據(jù)緩存

query-frontend

查詢(xún)前端是一個(gè)無(wú)狀態(tài)組件，它提供與查詢(xún)器相同的 API，并可用于加快讀取路徑。盡管查詢(xún)前端不是必需的，但我們建議您部署它。部署查詢(xún)前端時(shí)，應(yīng)該向查詢(xún)前端而不是查詢(xún)器發(fā)出查詢(xún)請(qǐng)求。集群中需要查詢(xún)器來(lái)執(zhí)行查詢(xún)，在內(nèi)部隊(duì)列中保存查詢(xún)。在這種情況下，查詢(xún)器充當(dāng)從隊(duì)列中提取作業(yè)、執(zhí)行作業(yè)并將結(jié)果返回到查詢(xún)前端進(jìn)行聚合的工作者。要將查詢(xún)器與查詢(xún)前端連接，通過(guò)-querier.frontend-address配置，在使用高可用情況下建議部署至少 2 個(gè)查詢(xún)前端。

工作原理

隊(duì)列

查詢(xún)前端使用排隊(duì)機(jī)制來(lái)：

如果查詢(xún)失敗，請(qǐng)確保重試可能導(dǎo)致查詢(xún)器內(nèi)存不足（OOM）錯(cuò)誤的大型查詢(xún)。這使管理員能夠?yàn)椴樵?xún)提供不足的內(nèi)存，或并行運(yùn)行更多的小型查詢(xún)，這有助于降低總體擁有成本。

通過(guò)使用先進(jìn)先出隊(duì)列在所有查詢(xún)器之間分發(fā)查詢(xún)，防止在單個(gè)查詢(xún)器上保護(hù)多個(gè)大型請(qǐng)求。

通過(guò)在租戶(hù)之間公平地安排查詢(xún)，防止單個(gè)租戶(hù)拒絕為其他租戶(hù)提供服務(wù)。

拆分

查詢(xún)前端可以將遠(yuǎn)程查詢(xún)拆分為多個(gè)查詢(xún)。默認(rèn)情況下，分割間隔為 24 小時(shí)。查詢(xún)前端在下游查詢(xún)器中并行執(zhí)行這些查詢(xún)，并將結(jié)果組合在一起。拆分可防止大型多天或多月查詢(xún)導(dǎo)致查詢(xún)器內(nèi)存不足錯(cuò)誤，并加快查詢(xún)執(zhí)行速度。

緩存

查詢(xún)前端緩存查詢(xún)結(jié)果并在后續(xù)查詢(xún)中重用它們。如果緩存的結(jié)果不完整，查詢(xún)前端將計(jì)算所需的部分查詢(xún)，并在下游查詢(xún)器上并行執(zhí)行它們。查詢(xún)前端可以選擇將查詢(xún)與其步驟參數(shù)對(duì)齊，以提高查詢(xún)結(jié)果的可緩存性。結(jié)果緩存由 Memcached 支持。

盡管將 step 參數(shù)與查詢(xún)時(shí)間范圍對(duì)齊可以提高 Mimir 的性能，但它違反了 Mimir 對(duì) PromQL 的一致性。如果 PromQL 一致性不是優(yōu)先事項(xiàng)，可以設(shè)置-query-frontend.align-queries-with-step=true。

store-gateway（數(shù)據(jù)存儲(chǔ)網(wǎng)關(guān)）

存儲(chǔ)網(wǎng)關(guān)組件是有狀態(tài)的，它查詢(xún)來(lái)自長(zhǎng)期存儲(chǔ)的塊。在讀取路徑上，querier和ruler在處理查詢(xún)時(shí)使用存儲(chǔ)網(wǎng)關(guān)，無(wú)論查詢(xún)來(lái)自用戶(hù)還是來(lái)自正在評(píng)估的規(guī)則。為了在查詢(xún)時(shí)找到要查找的正確塊，存儲(chǔ)網(wǎng)關(guān)需要一個(gè)關(guān)于長(zhǎng)期存儲(chǔ)中存儲(chǔ)桶的最新視圖。存儲(chǔ)網(wǎng)關(guān)使用以下選項(xiàng)之一更新存儲(chǔ)段視圖：

定期下載 bucket 索引（默認(rèn)）

定期掃描 bucket

工作原理

bucket 索引啟用

bucket 索引禁用

數(shù)據(jù)塊分片和復(fù)制

分片策略

自動(dòng)忘記

區(qū)域意識(shí)

塊索引頭

索引頭懶加載

索引緩存

inmemory

memcached

元數(shù)據(jù)緩存

區(qū)塊緩存

Alertmanager

Mimir Alertmanager 為 Prometheus Alertmanagers 添加了多租戶(hù)支持和水平伸縮性。Mimir Alertmanager 是一個(gè)可選組件，它接受來(lái)自 Mimir 標(biāo)尺的警報(bào)通知。Alertmanager 對(duì)警報(bào)通知進(jìn)行重復(fù)數(shù)據(jù)消除和分組，并將其路由到通知通道，如電子郵件、PagerDuty 或 OpsGenie。

Override-exporter

Mimir 支持按租戶(hù)應(yīng)用覆蓋。許多覆蓋配置了限制，以防止單個(gè)租戶(hù)使用過(guò)多資源。覆蓋導(dǎo)出器組件將限制公開(kāi)為普羅米修斯度量，以便運(yùn)營(yíng)商了解租戶(hù)與其限制的接近程度。

query-scheduler

查詢(xún)調(diào)度程序是一個(gè)可選的無(wú)狀態(tài)組件，它保留要執(zhí)行的查詢(xún)隊(duì)列，并將工作負(fù)載分配給可用的查詢(xún)器。

工作原理

ruler

規(guī)則是一個(gè)可選組件，用于評(píng)估記錄和警報(bào)規(guī)則中定義的 PromQL 表達(dá)式。每個(gè)租戶(hù)都有一組記錄和警報(bào)規(guī)則，可以將這些規(guī)則分組到名稱(chēng)空間中。

安裝

說(shuō)明：安裝 mimir 需要在官方下載這個(gè)二進(jìn)制程序或者直接在 k8s 集群里面直接部署即可。在這里以未啟用多租戶(hù)為介紹。

注意事項(xiàng)：

target 默認(rèn)為 all,不包含可選組件.要啟用可選組件需要額外添加

replication_factor 默認(rèn)為 3,如果只有一臺(tái)機(jī)器或者只需要啟動(dòng)一個(gè)實(shí)例,需要改為 1(單需要只要 alertmanager 為 1 的時(shí)候只能發(fā)送 1 條報(bào)警信息,直到 2.3.1 版本官方都沒(méi)有解決)

裸機(jī)部署

準(zhǔn)備配置文件

alertmanager:
external_url:http://127.0.0.1:8080/alertmanager
sharding_ring:
replication_factor:2
ingester:
ring:
replication_factor:1
multitenancy_enabled:false
ruler:
alertmanager_url:http://127.0.0.1:8080/alertmanager
external_url:http://127.0.0.1:8080/ruler
query_frontend:
address:127.0.0.1:9095
query_stats_enabled:true
rule_path:./ruler/
ruler_storage:
filesystem:
dir:./rules-storage
store_gateway:
sharding_ring:
replication_factor:1
target:all,alertmanager,ruler

啟動(dòng)服務(wù)

/usr/local/mimir/mimir-darwin-amd64--config.file/usr/local/mimir/mimir.yaml

查看狀態(tài)

服務(wù)啟動(dòng)后可通過(guò)瀏覽器打開(kāi)查看首頁(yè)

mimir_status

各服務(wù)運(yùn)行狀態(tài)

running_status

查看服務(wù)是否就緒

查看當(dāng)前集群節(jié)點(diǎn)

查看多租戶(hù)

配置 Alertmanager

準(zhǔn)備配置文件

cat./alertmanager.yaml
global:
resolve_timeout:5m
http_config:
follow_redirects:true
enable_http2:true
smtp_from:qiyx1@qq.com
smtp_hello:mimir
smtp_smarthost:smtp.qq.com:587
smtp_auth_username:qiyx1@qq.com
smtp_require_tls:true
route:
receiver:email
group_by:
-alertname
continue:false
routes:
-receiver:email
group_by:
-alertname
matchers:
-severity="info"
mute_time_intervals:
-夜間
continue:true
group_wait:10s
group_interval:5s
repeat_interval:6h
inhibit_rules:
-source_match:
severity:warning
target_match:
severity:warning
equal:
-alertname
-instance
receivers:
-name:email
email_configs:
-send_resolved:true
to:xxxx@xxxx.cn
from:qiyx1@qq.com
hello:mimir
smarthost:smtp.qq.com:587
auth_username:qiyx1@qq.com
headers:
From:qiyx1@qq.com
Subject:'{{template"email.default.subject".}}'
To:qiyongxiao@elion.com.cn
html:'{{template"email.default.html".}}'
text:'{{template"email.default.html".}}'
require_tls:true
templates:
-email.default.html
mute_time_intervals:
-name:夜間
time_intervals:
-times:
-start_time:"00:00"
end_time:"08:45"
-start_time:"21:30"
end_time:"23:59"

將配置文件上傳到 mimir，默認(rèn) mimir 啟動(dòng)后 alertmanager 的配置信息是空的，報(bào)警器無(wú)法啟動(dòng)，需要修改配置后才能啟動(dòng)

mimirtoolalertmanagerload./alertmanager.yaml--addresshttp://127.0.0.1:8080--idannoymous

配置 grafana 的 alertmanager

配置 grafana 的 prometheus

添加報(bào)警規(guī)則

配置多租戶(hù)

更改配置文件中multitenancy_enabled: true

上傳 alertmanager 配置文件(instance_id 一般為配置的 node 名稱(chēng),可以自定義)

mimirtool alertmanager load ./alertmanager.yaml --address http://127.0.0.1:8080 --id instance_id