使用 MinIO 與 Grafana Mimir 實現指標持久化存儲
Grafana Mimir 是 Grafana Labs 開發的一個 AGPLv3 許可的開源軟件項目，與對象存儲結合使用時，可為 Prometheus 指標提供可擴展的長期存儲。Mimir 使用基于微服務的可水平擴展的架構構建。每個微服務被稱為一個組件，Mimir 作為由這些組件組成的單個二進制文件運行。大多數組件都是無狀態的，不需要在重新啟動之間保留任何數據。這里我們結合 MinIO 來使用 Grafana Mimir。
Mimir 特性
當您將 Mimir 和 MinIO 結合起來時，您將生成一個特別適合滿足企業云原生可觀察性需求的基礎架構，其中包括：
- 性能：MinIO 將可擴展性和高性能相結合，使每個工作負載（無論要求有多高）都觸手可及。MinIO 具有驚人的性能，最近的基準測試在 GET 上實現了 325 GiB/s (349 GB/s)，在 PUT 上實現了 165 GiB/s (177 GB/s)，僅使用 32 個現成 NVMe SSD 節點。
- 規模：MinIO 沒有任何限制，因為它可以通過服務器池水平擴展。每個服務器池都是一組獨立的節點，擁有自己的計算、網絡和存儲資源。在多租戶配置中，每個租戶都是單個命名空間中的服務器池集群，與其他租戶的服務器池完全隔離。通過將 MinIO 指向新的服務器池，可以輕松地將容量添加到現有系統，MinIO 會自動為其做好準備并將其投入使用。
- 簡單性：如果您寧愿使用 Mimir 而不是花幾個小時擺弄對象存儲，那么您找不到比 MinIO 更簡單的解決方案了。MinIO 只服務于對象——這就是我們所做的一切，并且我們執著于成為最好的。其他產品將對象和文件存儲相結合，這會產生多個存儲層，從而導致 Mimir 的查詢響應時間出現延遲，并創建更復雜的架構，從而導致失敗的可能性更大。
- 多云：MinIO 誕生于云端，可以在任何硬件和軟件組合上運行。豐富的集成意味著 MinIO 可以透明地插入現有的安全和管理工具及服務，以集中身份管理、加密密鑰管理等。MinIO 在裸機或任何版本的 Kubernetes（包括 GKE、EKS、AKS、Red Hat OpenShift、VMware Tanzu）上提供 S3 API 兼容的對象存儲，并使用主動-主動復制高效同步數據。
Grafana Mimir 的一些核心優勢包括：
- 易于安裝和維護：Grafana Mimir 豐富的文檔、教程和部署工具使其能夠快速上手。您只需一個二進制文件即可啟動并運行 Grafana Mimir，無需任何其他依賴項。部署后，使用 Grafana Mimir 打包的最佳實踐儀表板、警報和操作手冊可以輕松監控系統的運行狀況。
- 大規模可擴展性：您可以在多臺機器上運行 Grafana Mimir 的水平可擴展架構，從而能夠比單個 Prometheus 實例處理更多數量級的時間序列。內部測試表明 Grafana Mimir 可處理多達 10 億個活動時間序列。
- 指標的全局視圖：Grafana Mimir 使您能夠運行聚合來自多個 Prometheus 實例的系列的查詢，為您提供系統的全局視圖。它的查詢引擎廣泛地并行化查詢執行，因此即使是最高基數的查詢也能以極快的速度完成。
- 廉價、耐用的指標存儲：Grafana Mimir 使用對象存儲進行長期數據存儲，使其能夠利用這種無處不在、經濟高效、高耐用性的技術。它與多種對象存儲實現兼容，包括 AWS S3、Google Cloud Storage、Azure Blob Storage、OpenStack Swift 以及任何與 S3 兼容的對象存儲。
- 高可用性：Grafana Mimir 復制傳入指標，確保在機器故障時不會丟失數據。其水平可擴展架構還意味著它可以在零停機的情況下重新啟動、升級或降級，這意味著指標提取或查詢不會中斷。
- 原生多租戶：Grafana Mimir 的多租戶架構使您能夠將數據和查詢與獨立團隊或業務部門隔離，從而使這些組可以共享同一集群。高級限制和服務質量控制可確保容量在租戶之間公平共享。
Mimir 可以輕松擴展到 10 億個指標甚至更多，其查詢性能比 Cortex 快 40 倍，TSDB Mimir 就是為了取代 Cortex 而構建的。Cortex 自 2018 年以來一直是 CNCF 項目，廣泛用于存儲 Prometheus 指標。在創建 Mimir 時，Grafana Labs 通過 AGPLv3 許可、訪問控制以及改進的性能、可擴展性和可用性為企業級可觀測性奠定了基礎。
Grafana Labs 對 Mimir 的目標是：成為最佳可擴展時間序列數據庫，無論指標格式如何。企業應該能夠在不修改現有代碼的情況下使用 Prometheus 指標（以及其他供應商協作的其他指標）。它給自己的定位是成為可觀測性中 metrics 后端存儲的終極方案，能夠兼容各種 metrics 協議，如圖：
Mimir 架構
整體上 Grafana Mimir 有兩種部署模式：
- 單體模式
- 微服務模式
部署模式由 -target 參數確定，可以通過 CLI 標志或 YAML 配置來設置該參數。
單體模式
整體模式在單個進程中運行所有必需的組件，并且是默認的操作模式，你可以通過指定 -target=all 來設置。單體模式是部署 Grafana Mimir 的最簡單方法，如果您想快速入門或想在開發環境中使用 Grafana Mimir，該模式非常有用。要查看 -target 設置為 all 時運行的組件列表，請使用 ./mimir -modules 查看：
通過使用 -target=all 部署多個 Grafana Mimir 二進制文件，可以水平擴展整體模式。這種方法提供了高可用性和更大的規模，而沒有完整的微服務部署的配置復雜性。
微服務模式
在微服務模式下，組件部署在不同的進程中。擴展是按組件進行的，這使得擴展具有更大的靈活性和更細粒度的故障域。微服務模式是生產部署的首選方法，但也是最復雜的。
在微服務模式下，每個 Grafana Mimir 進程都會被調用，其 -target 參數設置為特定的 Grafana Mimir 組件（例如，-target=ingester 或 -target=distributor）。要獲得有效的 Grafana Mimir 實例，您必須部署每個必需的組件。
如果您有興趣以微服務模式部署 Grafana Mimir，我們建議您使用 Kubernetes 和 mimir 分布式 Helm Chart。
讀寫分離模式
讀寫分離部署模式目前還處于實驗階段。
讀寫分離模式提供了單體和微服務模式的替代方案。在讀寫分離模式下，組件被分為三個服務，以減輕操作開銷，同時仍然允許在讀取和寫入路徑上單獨調整規模。這些服務將組件分組如下：
- read
- query-frontend
- querier
- backend
store-gateway
compactor
ruler
alertmanager
query-scheduler
overrides-exporter
write
distributor
ingester
與其他模式類似，每個 Grafana Mimir 進程都是通過將其 -target 參數設置為特定服務來調用的：-target=read、-target=write 或 -target=backend。
Mimir 組件
上面的不同架構中都提到了 Mimir 的組件，這里我們來看一下 Mimir 的組件。
Compactor(必備)
- 對數據進行清洗合并，會將 ingester 上傳到 S3 的數據，下載然后重新進行壓縮去重，最終再次上傳 S3，同時也負責刪除。
- 壓縮過程支持高級特性 split-and-merge。
Distributor(必備)
- 相當于整個流量的入口, HTTP 流量會先到達 distributor，distributor 持有 ingester 的 hash ring，然后通過 gRPC 并行發送給多個 ingester。
Ingester(必備)
- 必備組件，而且是最核心組件
- 如果部署，推薦還是一臺主機部署一個，不要混布。
- 接收來自 distributer 的數據，并不會立刻寫入到存儲里，而是保存在內存，然后定期的刷新到后端存儲。當查詢時，會有部分請求來到 ingester。
Querier(必備)
- 查詢真正的核心組件，支持 cache，可以作為最外層的查詢服務，暴露 HTTP。
- Querier 里使用的查詢引擎還是 PromQL，直接引用的 Prometheus 的源碼。
- Querier 將會從 ingester 和 store-gateway 分別查數據。
Query-frontend(可選)
- 能加速查詢效率（主要是切割成 N 個小范圍的 query）, 最終將結果做數據聚合，最終結果可以 cache。
Query-scheduler(可選)
- 主要解決 query-frontend 擴縮問題，簡單來說，就是 query-frontend 維護著任務隊列還有數據聚合等操作，不想擴容 query-frontend 而引起內部 queue 增加。因為每增加 query-frontend 就會導致 querier 內部產生新的 worker 去拉取 queue，會導致同時處理查詢的數量很大，會超過 -querier.max-concurrent。
Store-gateway(必備)
- Querier、Ruler 需要用，主要是加速查詢效率，減少查詢對象存儲的請求數量。
- 注意：生產環境還是需要加一層 memcached，效率會提升很多，如果不使用 cache，每次都會下載 chunks。
Ruler(可選)
- 用于評估記錄和警報規則中定義的 PromQL 表達式。
- 每個租戶都有一組記錄和警報規則，并且可以將這些規則分組到命名空間中。
Alertmanager(可選)
- Mimir Alertmanager 為 Prometheus Alertmanager 添加了多租戶支持和水平可擴展性。
- Mimir Alertmanager 是一個可選組件，用于接受來自 Mimir ruler 的警報通知。
- Alertmanager 對警報通知進行重復數據刪除和分組，并將它們路由到通知渠道，例如電子郵件、PagerDuty 或 OpsGenie。
overrides-exporter(可選)
- Grafana Mimir 支持在每個租戶的基礎上應用覆蓋。許多替代配置限制可防止單個租戶使用過多資源。overrides-exporter 組件將限制暴露 Prometheus 指標，以便運維人員可以了解租戶與限制的接近程度。
安裝 Mimir
為了和大家說明 Mimir 的使用，這里我們將通過 Docker 來使用 Mimir。
首先使用下面命令獲取 Mimir 代碼：
git clone https://github.com/grafana/mimir.git導航到教程目錄：
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 的三個實例以實現高可用性。已啟用多租戶（租戶 ID 為 demo）。
- Prometheus - 抓取 Mimir 指標，然后將它們寫回到 Mimir 以便它們可用。
- MinIO - 與 S3 兼容的軟件定義的塊、規則和警報的持久存儲。
- Grafana - 包括用于查詢 Mimir 的預安裝數據源和用于監控 Mimir 的預安裝儀表板。
- Nginx - 基于 NGINX 的負載均衡器，公開 Mimir 實例。
啟動后可以使用以下端口訪問：
- Grafana：http://localhost:9000
- Mimir：http://localhost:9009
上面啟動的服務整體架構如下所示：
我們這里啟動的 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 各個組件的狀態：
使用 Mimir
要訪問 Grafana，請啟動瀏覽器并打開 http://localhost:9000。您將使用 Grafana 查看顯示 Mimir 集群狀態的儀表板。儀表板向 Mimir 查詢它們顯示的指標。從左上角的菜單中，單擊儀表板，然后單擊瀏覽以查看已為本教程預加載的儀表板。這些儀表板來自 Grafana Mimir mixin，它將 Grafana Labs 的最佳實踐儀表板、記錄規則和用于監控 Mimir 的警報打包在一起。
啟動容器后，指標通常需要 3-5 分鐘才能顯示在 Grafana 儀表板中。我們還在沒有入口網關、查詢調度程序或內存緩存的情況下運行 Mimir，因此相關儀表板將為空。
我們可以先瀏覽儀表板以進行寫入、讀取、查詢和對象存儲。例如，對象存儲儀表板顯示了自從我們啟動 Mimir 以來發生的操作。
配置記錄規則
記錄規則是一種預先計算經常需要的或計算成本較高的表達式并將結果保存為一組新的時間序列的機制。按照以下說明我們可以使用 Grafana 在 Mimir 中配置記錄規則。
比如 sum:up 記錄規則將顯示已啟動且可進行抓取的 Mimir 實例的數量。創建規則后，即可將其查詢并包含在儀表板中。
從左側工具欄打開報警菜單頁，然后點擊 Create alert rule 按鈕新建報警規則：
按照以下步驟配置記錄規則：
- 選擇 Mimir or Loki recording rule。
- 填寫規則名稱 sum:up。
- 在選擇數據源字段中選擇 Mimir。
- Namespace: example-namespace。
- Group: example-group。
- 查詢表達式: sum(up)。
- 選擇右上角的“保存并退出”。
要驗證新的記錄規則是否正確運行，請從左側菜單中打開 Explore 頁面：
在 Metric 下拉列表中，選擇 sum:up ，然后單擊右上角的 Run query，然后單擊 Inspector 按鈕。在下面，單擊 Data 可查看時間列表和查詢結果。結果應該是3，表明 Mimir 的三個本地實例正在運行。
配置報警規則
基于 Mimir 構建的報警規則遵循與基于 Prometheus 和 Loki 構建的報警規則相同的 PromQL 格式。Grafana 評估表達式，并在必要時使用 Alertmanager 發出警報。
這里我們將創建一個報警，當 Mimir 實例的數量降至三個以下時觸發。同樣在左側菜單中，點擊 Alerting，然后切換到 Alert rules 頁面，然后單擊 Create alert rule。
現在我們需要選擇 Mimir or Loki alert，然后按照以下步驟配置報警規則：
- 規則名稱: MimirNotRunning。
- 在選擇數據源字段中選擇 Mimir。
- Namespace: example-namespace。
- Group: example-group。
- 查詢表達式: up == 0。
- 選擇右上角的“保存并退出”。
創建完成后我們將看到我們的 Mimir 記錄規則和警報規則。請注意，警報旁邊顯示了一個漂亮、大、舒適的綠色正常狀態，因為我們所有的 Mimir 容器仍在運行。
現在我們通過終止三個 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 在查詢規則時會短暫顯示錯誤。一旦 Mimir 的內部運行狀況檢查檢測到已終止的實例運行狀況不佳，此問題就會自動解決。
大約一分鐘后，報警將很快顯示黃色 Pending 待處理狀態：
再過一分鐘，警報將變為紅色 Firing 觸發狀態：
如果我們為 Alertmanager 配置了通知通道，報警就會向適當的機制和聯系人發出。
在我們恢復終止的 Mimir 實例之前，請返回 Grafana 中的 Explorer 頁面并查詢我們的 sum:up 記錄規則。我們可以看到，即使 Mimir 實例已關閉，Mimir 仍繼續正確記錄指標。
最后，我們恢復 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)返回報警頁面，您會發現我們的報警狀態很快會恢復正常。
這里我們使用 Mimir 本身的 Prometheus 指標，然后在 Grafana 中查詢和可視化它們。我們還配置了記錄規則和警報，并驗證了滿足條件時警報是否按預期觸發。您還可以配置 Mimir 和 Grafana 從 MinIO 中抓取 Prometheus 指標，并通過 AlertManager 發出警報。Mimir 將數據存儲在對象存儲中以實現持久性，從而使其能夠利用無處不在、經濟高效且高耐用性的 MinIO。
