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

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

Mimir 是做什么的

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

Mimir 架構(gòu)

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

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

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

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

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

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

compactor 通過組合塊提高查詢性能并減少長期存儲使用。負(fù)責(zé)以下工作：

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

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

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

工作原理

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

壓縮器

縮放

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

壓縮算法

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

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

壓縮共享

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

阻止刪除

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

1.原始塊標(biāo)記為刪除；這是軟刪除

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

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

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

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

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

工作原理

驗(yàn)證

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

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

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

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

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

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

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

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

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

速率限制

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

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

接受速率每個(gè)租戶在 Grafana Mimir 集群中每秒可接收的最大樣本數(shù)。如果超過其中任何一個(gè)速率，分發(fā)服務(wù)器將丟棄請求并返回 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ù)器會自動調(diào)整請求和接收速率限制。因?yàn)檫@些速率限制是使用每個(gè)分發(fā)服務(wù)器的本地速率限制器實(shí)現(xiàn)的，所以它們要求寫入請求在分發(fā)服務(wù)器池中均勻分布。可以通過下面的這幾個(gè)參數(shù)進(jìn)行限制：

-distributor.request-rate-limit

-distributor.request-burst-size

-distributor.ingestion-rate-limit

-distributor.ingestion-burst-size

高可用跟蹤器

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

切分和復(fù)制

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

仲裁一致性

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

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

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

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

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

工作原理

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

pending

joining

active

leaving

unhealthy

寫放大

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

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

如果接收程序進(jìn)程崩潰或突然退出，則所有尚未上載到長期存儲的內(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ù)中斷。

無序切分

亂序切分可以用來減少多個(gè)租戶對彼此的影響。

無序樣本接收

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

querier（查詢器）

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

工作原理

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

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

定期掃描 bucket

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

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

Bucket 索引已禁用

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

查詢請求解析

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

連接到接收器

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

query-frontend

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

工作原理

隊(duì)列

查詢前端使用排隊(duì)機(jī)制來：

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

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

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

拆分

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

緩存

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

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

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

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

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

定期掃描 bucket

工作原理

bucket 索引啟用

bucket 索引禁用

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

分片策略

自動忘記

區(qū)域意識

塊索引頭

索引頭懶加載

索引緩存

inmemory

memcached

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

區(qū)塊緩存

Alertmanager

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

Override-exporter

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

query-scheduler

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

工作原理

ruler

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

安裝

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

注意事項(xiàng)：

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

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

裸機(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

啟動服務(wù)

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

查看狀態(tài)

服務(wù)啟動后可通過瀏覽器打開查看首頁

mimir_status

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

running_status

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

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

查看多租戶

配置 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 啟動后 alertmanager 的配置信息是空的，報(bào)警器無法啟動，需要修改配置后才能啟動

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

配置 grafana 的 alertmanager

配置 grafana 的 prometheus

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

配置多租戶

更改配置文件中multitenancy_enabled: true

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

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