Grafana Mimir 是 Grafana Labs 開發(fā)的一個 AGPLv3 許可的開源軟件項目，與對象存儲結(jié)合使用時，可為 Prometheus 指標提供可擴展的長期存儲。Mimir 使用基于微服務(wù)的可水平擴展的架構(gòu)構(gòu)建。每個微服務(wù)被稱為一個組件，Mimir 作為由這些組件組成的單個二進制文件運行。大多數(shù)組件都是無狀態(tài)的，不需要在重新啟動之間保留任何數(shù)據(jù)。這里我們結(jié)合 MinIO 來使用 Grafana Mimir。

Mimir 特性

當您將 Mimir 和 MinIO 結(jié)合起來時，您將生成一個特別適合滿足企業(yè)云原生可觀察性需求的基礎(chǔ)架構(gòu)，其中包括：

• 性能：MinIO 將可擴展性和高性能相結(jié)合，使每個工作負載（無論要求有多高）都觸手可及。MinIO 具有驚人的性能，最近的基準測試在 GET 上實現(xiàn)了 325 GiB/s (349 GB/s)，在 PUT 上實現(xiàn)了 165 GiB/s (177 GB/s)，僅使用 32 個現(xiàn)成 NVMe SSD 節(jié)點。
• 規(guī)模：MinIO 沒有任何限制，因為它可以通過服務(wù)器池水平擴展。每個服務(wù)器池都是一組獨立的節(jié)點，擁有自己的計算、網(wǎng)絡(luò)和存儲資源。在多租戶配置中，每個租戶都是單個命名空間中的服務(wù)器池集群，與其他租戶的服務(wù)器池完全隔離。通過將 MinIO 指向新的服務(wù)器池，可以輕松地將容量添加到現(xiàn)有系統(tǒng)，MinIO 會自動為其做好準備并將其投入使用。
• 簡單性：如果您寧愿使用 Mimir 而不是花幾個小時擺弄對象存儲，那么您找不到比 MinIO 更簡單的解決方案了。MinIO 只服務(wù)于對象——這就是我們所做的一切，并且我們執(zhí)著于成為最好的。其他產(chǎn)品將對象和文件存儲相結(jié)合，這會產(chǎn)生多個存儲層，從而導(dǎo)致 Mimir 的查詢響應(yīng)時間出現(xiàn)延遲，并創(chuàng)建更復(fù)雜的架構(gòu)，從而導(dǎo)致失敗的可能性更大。
• 多云：MinIO 誕生于云端，可以在任何硬件和軟件組合上運行。豐富的集成意味著 MinIO 可以透明地插入現(xiàn)有的安全和管理工具及服務(wù)，以集中身份管理、加密密鑰管理等。MinIO 在裸機或任何版本的 Kubernetes（包括 GKE、EKS、AKS、Red Hat OpenShift、VMware Tanzu）上提供 S3 API 兼容的對象存儲，并使用主動-主動復(fù)制高效同步數(shù)據(jù)。

Grafana Mimir 的一些核心優(yōu)勢包括：

• 易于安裝和維護：Grafana Mimir 豐富的文檔、教程和部署工具使其能夠快速上手。您只需一個二進制文件即可啟動并運行 Grafana Mimir，無需任何其他依賴項。部署后，使用 Grafana Mimir 打包的最佳實踐儀表板、警報和操作手冊可以輕松監(jiān)控系統(tǒng)的運行狀況。
• 大規(guī)?？蓴U展性：您可以在多臺機器上運行 Grafana Mimir 的水平可擴展架構(gòu)，從而能夠比單個 Prometheus 實例處理更多數(shù)量級的時間序列。內(nèi)部測試表明 Grafana Mimir 可處理多達 10 億個活動時間序列。
• 指標的全局視圖：Grafana Mimir 使您能夠運行聚合來自多個 Prometheus 實例的系列的查詢，為您提供系統(tǒng)的全局視圖。它的查詢引擎廣泛地并行化查詢執(zhí)行，因此即使是最高基數(shù)的查詢也能以極快的速度完成。
• 廉價、耐用的指標存儲：Grafana Mimir 使用對象存儲進行長期數(shù)據(jù)存儲，使其能夠利用這種無處不在、經(jīng)濟高效、高耐用性的技術(shù)。它與多種對象存儲實現(xiàn)兼容，包括 AWS S3、Google Cloud Storage、Azure Blob Storage、OpenStack Swift 以及任何與 S3 兼容的對象存儲。
• 高可用性：Grafana Mimir 復(fù)制傳入指標，確保在機器故障時不會丟失數(shù)據(jù)。其水平可擴展架構(gòu)還意味著它可以在零停機的情況下重新啟動、升級或降級，這意味著指標提取或查詢不會中斷。
• 原生多租戶：Grafana Mimir 的多租戶架構(gòu)使您能夠?qū)?shù)據(jù)和查詢與獨立團隊或業(yè)務(wù)部門隔離，從而使這些組可以共享同一集群。高級限制和服務(wù)質(zhì)量控制可確保容量在租戶之間公平共享。

Mimir 可以輕松擴展到 10 億個指標甚至更多，其查詢性能比 Cortex 快 40 倍，TSDB Mimir 就是為了取代 Cortex 而構(gòu)建的。Cortex 自 2018 年以來一直是 CNCF 項目，廣泛用于存儲 Prometheus 指標。在創(chuàng)建 Mimir 時，Grafana Labs 通過 AGPLv3 許可、訪問控制以及改進的性能、可擴展性和可用性為企業(yè)級可觀測性奠定了基礎(chǔ)。

Grafana Labs 對 Mimir 的目標是：成為最佳可擴展時間序列數(shù)據(jù)庫，無論指標格式如何。企業(yè)應(yīng)該能夠在不修改現(xiàn)有代碼的情況下使用 Prometheus 指標（以及其他供應(yīng)商協(xié)作的其他指標）。它給自己的定位是成為可觀測性中 metrics 后端存儲的終極方案，能夠兼容各種 metrics 協(xié)議，如圖：

Mimir 架構(gòu)

整體上 Grafana Mimir 有兩種部署模式：

• 單體模式
• 微服務(wù)模式

部署模式由 -target 參數(shù)確定，可以通過 CLI 標志或 YAML 配置來設(shè)置該參數(shù)。

單體模式

整體模式在單個進程中運行所有必需的組件，并且是默認的操作模式，你可以通過指定 -target=all 來設(shè)置。單體模式是部署 Grafana Mimir 的最簡單方法，如果您想快速入門或想在開發(fā)環(huán)境中使用 Grafana Mimir，該模式非常有用。要查看 -target 設(shè)置為 all 時運行的組件列表，請使用 ./mimir -modules 查看：

通過使用 -target=all 部署多個 Grafana Mimir 二進制文件，可以水平擴展整體模式。這種方法提供了高可用性和更大的規(guī)模，而沒有完整的微服務(wù)部署的配置復(fù)雜性。

微服務(wù)模式

在微服務(wù)模式下，組件部署在不同的進程中。擴展是按組件進行的，這使得擴展具有更大的靈活性和更細粒度的故障域。微服務(wù)模式是生產(chǎn)部署的首選方法，但也是最復(fù)雜的。

在微服務(wù)模式下，每個 Grafana Mimir 進程都會被調(diào)用，其 -target 參數(shù)設(shè)置為特定的 Grafana Mimir 組件（例如，-target=ingester 或 -target=distributor）。要獲得有效的 Grafana Mimir 實例，您必須部署每個必需的組件。

如果您有興趣以微服務(wù)模式部署 Grafana Mimir，我們建議您使用 Kubernetes 和 mimir 分布式 Helm Chart。

讀寫分離模式

讀寫分離部署模式目前還處于實驗階段。

讀寫分離模式提供了單體和微服務(wù)模式的替代方案。在讀寫分離模式下，組件被分為三個服務(wù)，以減輕操作開銷，同時仍然允許在讀取和寫入路徑上單獨調(diào)整規(guī)模。這些服務(wù)將組件分組如下：

• read

• query-frontend
• querier

• backend

• store-gateway

• compactor

• ruler

• alertmanager

• query-scheduler

• overrides-exporter

• write

• distributor

• ingester

與其他模式類似，每個 Grafana Mimir 進程都是通過將其 -target 參數(shù)設(shè)置為特定服務(wù)來調(diào)用的：-target=read、-target=write 或 -target=backend。

Mimir 組件

上面的不同架構(gòu)中都提到了 Mimir 的組件，這里我們來看一下 Mimir 的組件。

Compactor(必備)

• 對數(shù)據(jù)進行清洗合并，會將 ingester 上傳到 S3 的數(shù)據(jù)，下載然后重新進行壓縮去重，最終再次上傳 S3，同時也負責刪除。
• 壓縮過程支持高級特性 split-and-merge。

Distributor(必備)

• 相當于整個流量的入口, HTTP 流量會先到達 distributor，distributor 持有 ingester 的 hash ring，然后通過 gRPC 并行發(fā)送給多個 ingester。

Ingester(必備)

• 必備組件，而且是最核心組件
• 如果部署，推薦還是一臺主機部署一個，不要混布。
• 接收來自 distributer 的數(shù)據(jù)，并不會立刻寫入到存儲里，而是保存在內(nèi)存，然后定期的刷新到后端存儲。當查詢時，會有部分請求來到 ingester。

Querier(必備)

• 查詢真正的核心組件，支持 cache，可以作為最外層的查詢服務(wù)，暴露 HTTP。
• Querier 里使用的查詢引擎還是 PromQL，直接引用的 Prometheus 的源碼。
• Querier 將會從 ingester 和 store-gateway 分別查數(shù)據(jù)。

Query-frontend(可選)

• 能加速查詢效率（主要是切割成 N 個小范圍的 query）, 最終將結(jié)果做數(shù)據(jù)聚合，最終結(jié)果可以 cache。

Query-scheduler(可選)

• 主要解決 query-frontend 擴縮問題，簡單來說，就是 query-frontend 維護著任務(wù)隊列還有數(shù)據(jù)聚合等操作，不想擴容 query-frontend 而引起內(nèi)部 queue 增加。因為每增加 query-frontend 就會導(dǎo)致 querier 內(nèi)部產(chǎn)生新的 worker 去拉取 queue，會導(dǎo)致同時處理查詢的數(shù)量很大，會超過 -querier.max-concurrent。

Store-gateway(必備)

• Querier、Ruler 需要用，主要是加速查詢效率，減少查詢對象存儲的請求數(shù)量。
• 注意：生產(chǎn)環(huán)境還是需要加一層 memcached，效率會提升很多，如果不使用 cache，每次都會下載 chunks。

Ruler(可選)

• 用于評估記錄和警報規(guī)則中定義的 PromQL 表達式。
• 每個租戶都有一組記錄和警報規(guī)則，并且可以將這些規(guī)則分組到命名空間中。

Alertmanager(可選)

• Mimir Alertmanager 為 Prometheus Alertmanager 添加了多租戶支持和水平可擴展性。
• Mimir Alertmanager 是一個可選組件，用于接受來自 Mimir ruler 的警報通知。
• Alertmanager 對警報通知進行重復(fù)數(shù)據(jù)刪除和分組，并將它們路由到通知渠道，例如電子郵件、PagerDuty 或 OpsGenie。

overrides-exporter(可選)

• Grafana Mimir 支持在每個租戶的基礎(chǔ)上應(yīng)用覆蓋。許多替代配置限制可防止單個租戶使用過多資源。overrides-exporter 組件將限制暴露 Prometheus 指標，以便運維人員可以了解租戶與限制的接近程度。

安裝 Mimir

為了和大家說明 Mimir 的使用，這里我們將通過 Docker 來使用 Mimir。

首先使用下面命令獲取 Mimir 代碼：

git clone https://github.com/grafana/mimir.git

導(dǎo)航到教程目錄：

cd mimir
cd docs/sources/mimir/get-started/play-with-grafana-mimir/

該目錄下面包含一個 docker-compose.yml 文件，我們可以直接使用 docker-compose 來啟動 MinIO、Mimir、Prometheus、Grafana 和 NGINX：

docker-compose up

該命令會啟動如下幾個容器：

• Mimir - Mimir 的三個實例以實現(xiàn)高可用性。已啟用多租戶（租戶 ID 為 demo）。
• Prometheus - 抓取 Mimir 指標，然后將它們寫回到 Mimir 以便它們可用。
• MinIO - 與 S3 兼容的軟件定義的塊、規(guī)則和警報的持久存儲。
• Grafana - 包括用于查詢 Mimir 的預(yù)安裝數(shù)據(jù)源和用于監(jiān)控 Mimir 的預(yù)安裝儀表板。
• Nginx - 基于 NGINX 的負載均衡器，公開 Mimir 實例。

啟動后可以使用以下端口訪問：

• Grafana：http://localhost:9000
• Mimir：http://localhost:9009

上面啟動的服務(wù)整體架構(gòu)如下所示：

我們這里啟動的 Grafana Mimir 配置文件如下所示：

# Do not use this configuration in production.
# It is for demonstration purposes only.
# Run Mimir in single process mode, with all components running in 1 process.
target: all,alertmanager,overrides-exporter

# Configure Mimir to use Minio as object storage backend.
common:
  storage:
    backend: s3
    s3:
      endpoint: minio:9000
      access_key_id: mimir
      secret_access_key: supersecret
      insecure: true
      bucket_name: mimir

# Blocks storage requires a prefix when using a common object storage bucket.
blocks_storage:
  storage_prefix: blocks
  tsdb:
    dir: /data/ingester

# Use memberlist, a gossip-based protocol, to enable the 3 Mimir replicas to communicate
memberlist:
  join_members: [mimir-1, mimir-2, mimir-3]

ruler:
  rule_path: /data/ruler
  alertmanager_url: http://127.0.0.1:8080/alertmanager
  ring:
    # Quickly detect unhealthy rulers to speed up the tutorial.
    heartbeat_period: 2s
    heartbeat_timeout: 10s

alertmanager:
  data_dir: /data/alertmanager
  fallback_config_file: /etc/alertmanager-fallback-config.yaml
  external_url: http://localhost:9009/alertmanager

server:
  log_level: warn

我們可以通過訪問 http://localhost:9009 來查看 Mimir 各個組件的狀態(tài)：

使用 Mimir

要訪問 Grafana，請啟動瀏覽器并打開 http://localhost:9000。您將使用 Grafana 查看顯示 Mimir 集群狀態(tài)的儀表板。儀表板向 Mimir 查詢它們顯示的指標。從左上角的菜單中，單擊儀表板，然后單擊瀏覽以查看已為本教程預(yù)加載的儀表板。這些儀表板來自 Grafana Mimir mixin，它將 Grafana Labs 的最佳實踐儀表板、記錄規(guī)則和用于監(jiān)控 Mimir 的警報打包在一起。

啟動容器后，指標通常需要 3-5 分鐘才能顯示在 Grafana 儀表板中。我們還在沒有入口網(wǎng)關(guān)、查詢調(diào)度程序或內(nèi)存緩存的情況下運行 Mimir，因此相關(guān)儀表板將為空。

我們可以先瀏覽儀表板以進行寫入、讀取、查詢和對象存儲。例如，對象存儲儀表板顯示了自從我們啟動 Mimir 以來發(fā)生的操作。

配置記錄規(guī)則

記錄規(guī)則是一種預(yù)先計算經(jīng)常需要的或計算成本較高的表達式并將結(jié)果保存為一組新的時間序列的機制。按照以下說明我們可以使用 Grafana 在 Mimir 中配置記錄規(guī)則。

比如 sum:up 記錄規(guī)則將顯示已啟動且可進行抓取的 Mimir 實例的數(shù)量。創(chuàng)建規(guī)則后，即可將其查詢并包含在儀表板中。

從左側(cè)工具欄打開報警菜單頁，然后點擊 Create alert rule 按鈕新建報警規(guī)則：

按照以下步驟配置記錄規(guī)則：

• 選擇 Mimir or Loki recording rule。
• 填寫規(guī)則名稱 sum:up。
• 在選擇數(shù)據(jù)源字段中選擇 Mimir。
• Namespace: example-namespace。
• Group: example-group。
• 查詢表達式: sum(up)。
• 選擇右上角的“保存并退出”。

要驗證新的記錄規(guī)則是否正確運行，請從左側(cè)菜單中打開 Explore 頁面：

在 Metric 下拉列表中，選擇 sum:up ，然后單擊右上角的 Run query，然后單擊 Inspector 按鈕。在下面，單擊 Data 可查看時間列表和查詢結(jié)果。結(jié)果應(yīng)該是3，表明 Mimir 的三個本地實例正在運行。

配置報警規(guī)則

基于 Mimir 構(gòu)建的報警規(guī)則遵循與基于 Prometheus 和 Loki 構(gòu)建的報警規(guī)則相同的 PromQL 格式。Grafana 評估表達式，并在必要時使用 Alertmanager 發(fā)出警報。

這里我們將創(chuàng)建一個報警，當 Mimir 實例的數(shù)量降至三個以下時觸發(fā)。同樣在左側(cè)菜單中，點擊 Alerting，然后切換到 Alert rules 頁面，然后單擊 Create alert rule。

現(xiàn)在我們需要選擇 Mimir or Loki alert，然后按照以下步驟配置報警規(guī)則：

• 規(guī)則名稱: MimirNotRunning。
• 在選擇數(shù)據(jù)源字段中選擇 Mimir。
• Namespace: example-namespace。
• Group: example-group。
• 查詢表達式: up == 0。
• 選擇右上角的“保存并退出”。

創(chuàng)建完成后我們將看到我們的 Mimir 記錄規(guī)則和警報規(guī)則。請注意，警報旁邊顯示了一個漂亮、大、舒適的綠色正常狀態(tài)，因為我們所有的 Mimir 容器仍在運行。

現(xiàn)在我們通過終止三個 Mimir 實例中的一個來模擬錯誤情況（確保您位于 docs/sources/mimir/get-started/play-with-grafana-mimir/ 目錄中）：

$ docker-compose kill mimir-3
[+] Running 1/1
 ? Container play-with-grafana-mimir-mimir-3-1  Killed                                                                                      0.2s
?  play-with-grafana-mimir git:(main)

由于我們突然終止 Mimir 實例，Grafana 在查詢規(guī)則時會短暫顯示錯誤。一旦 Mimir 的內(nèi)部運行狀況檢查檢測到已終止的實例運行狀況不佳，此問題就會自動解決。

大約一分鐘后，報警將很快顯示黃色 Pending 待處理狀態(tài)：

再過一分鐘，警報將變?yōu)榧t色 Firing 觸發(fā)狀態(tài)：

如果我們?yōu)?Alertmanager 配置了通知通道，報警就會向適當?shù)臋C制和聯(lián)系人發(fā)出。

在我們恢復(fù)終止的 Mimir 實例之前，請返回 Grafana 中的 Explorer 頁面并查詢我們的 sum:up 記錄規(guī)則。我們可以看到，即使 Mimir 實例已關(guān)閉，Mimir 仍繼續(xù)正確記錄指標。

最后，我們恢復(fù) Mimir 實例：

$ docker-compose start mimir-3
[+] Running 1/1
 ? Container play-with-grafana-mimir-mimir-3-1  Started                                                                                     0.2s
?  play-with-grafana-mimir git:(main)

返回報警頁面，您會發(fā)現(xiàn)我們的報警狀態(tài)很快會恢復(fù)正常。

這里我們使用 Mimir 本身的 Prometheus 指標，然后在 Grafana 中查詢和可視化它們。我們還配置了記錄規(guī)則和警報，并驗證了滿足條件時警報是否按預(yù)期觸發(fā)。您還可以配置 Mimir 和 Grafana 從 MinIO 中抓取 Prometheus 指標，并通過 AlertManager 發(fā)出警報。Mimir 將數(shù)據(jù)存儲在對象存儲中以實現(xiàn)持久性，從而使其能夠利用無處不在、經(jīng)濟高效且高耐用性的 MinIO。