MinIO と Grafana Mimir を使用してインジケーターの永続ストレージを実装する

Grafana Mimir は、Grafana Labs によって開発された AGPLv3 ライセンスのオープン ソース ソフトウェア プロジェクトであり、オブジェクト ストレージと組み合わせて使用​​することで、Prometheus メトリック用のスケーラブルな長期ストレージを提供します。 Mimir は、マイクロサービス ベースの水平スケーラブルなアーキテクチャを使用して構築されています。各マイクロサービスはコンポーネントと呼ばれ、Mimir はこれらのコンポーネントで構成される単一のバイナリとして実行されます。ほとんどのコンポーネントはステートレスであり、再起動間でデータを保持する必要はありません。ここでは、Grafana Mimir を MinIO と組み合わせて使用​​します。

ミミールの特徴

MimirとMinIOを組み合わせると、次のようなエンタープライズ クラウド ネイティブの可観測性ニーズに対応するのに特に適したインフラストラクチャが作成されます。

• パフォーマンス: MinIO はスケーラビリティと高パフォーマンスを兼ね備えており、どんなに要求が厳しいワークロードでも対応可能です。 MinIO は驚異的なパフォーマンスを誇り、最近のベンチマークでは、市販の NVMe SSD をわずか 32 ノード使用して、GET で 325 GiB/秒 (349 GB/秒)、PUT で 165 GiB/秒 (177 GB/秒) を達成しました。
• スケール: MinIO は、サーバー プールを介して水平方向に拡張できるため、制限はありません。各サーバー プールは、独自のコンピューティング、ネットワーク、およびストレージ リソースを備えた独立したノードのグループです。マルチテナント構成では、各テナントは単一の名前空間内のサーバー プールのクラスターであり、他のテナントのサーバー プールからは完全に分離されています。 MinIO を新しいサーバー プールに向けると、既存のシステムに簡単に容量を追加できます。MinIO は自動的にサーバー プールを準備して使用可能にします。
• シンプルさ: オブジェクト ストレージをいじるのに何時間も費やすよりも Mimir を使いたい場合、MinIO よりもシンプルなソリューションは見つかりません。 MinIO はオブジェクトのみを提供します。それが私たちの仕事のすべてであり、私たちは最高であることにこだわっています。他の製品では、オブジェクト ストレージとファイル ストレージが結合され、複数のストレージ層が生成されるため、Mimir のクエリ応答時間が遅くなり、障害が発生する可能性がより高い、より複雑なアーキテクチャが作成されます。
• マルチクラウド: MinIO はクラウドで生まれ、ハードウェアとソフトウェアのあらゆる組み合わせで実行できます。豊富な統合により、MinIO は既存のセキュリティおよび管理ツールやサービスに透過的にプラグインして、ID 管理、暗号化キー管理などを一元化できます。 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 メトリックの保存に広く使用されています。 Grafana Labs は、Mimir の作成において、AGPLv3 ライセンス、アクセス制御、パフォーマンス、スケーラビリティ、使いやすさの向上を通じて、エンタープライズ グレードの可観測性の基盤を築きました。

Grafana Labs の Mimir の目標は、メトリック形式に関係なく、最もスケーラブルな時系列データベースになることです。企業は、既存のコードを変更することなく、Prometheus メトリック (および連携している他のベンダーのメトリック) を使用できる必要があります。これは、可観測性におけるメトリック バックエンド ストレージの究極のソリューションとして位置付けられており、図に示すように、さまざまなメトリック プロトコルと互換性があります。

ミミール建築

全体として、Grafana Mimir には 2 つのデプロイメント モードがあります。

• シングルモード
• マイクロサービスパターン

デプロイメント モードは -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 の使用をお勧めします。

読み取り書き込み分離モード

読み取り/書き込み分離展開モードはまだ実験段階です。

読み取り/書き込み分離パターンは、モノリシック パターンとマイクロサービス パターンの代替手段を提供します。読み取り/書き込み分割モードでは、コンポーネントが 3 つのサービスに分割され、読み取りパスと書き込みパスの独立したスケーリングを可能にしながら、運用オーバーヘッドを削減します。これらのサービスは、コンポーネントを次のようにグループ化します。

• 読む

• クエリフロントエンド
• 質問者

• バックエンド

• ストアゲートウェイ

• 圧縮機

• ルーラー

• アラートマネージャー

• クエリスケジューラ

• オーバーライドエクスポーター

• 書く

• 卸売業者

• 摂取する

他のモードと同様に、各 Grafana Mimir プロセスは、-target パラメータを特定のサービス (-target=read、-target=write、または -target=backend) に設定することによって呼び出されます。

ミミールコンポーネント

Mimir のコンポーネントは、上記のさまざまなアーキテクチャで説明されています。ここでは、Mimir のコンポーネントについて見ていきます。

圧縮機（必須）

• データをクリーンアップしてマージします。インジェスターは、S3 にアップロードされたデータをダウンロードし、再度圧縮して重複を排除し、最後に再度 S3 にアップロードします。削除も担当します。
• 圧縮プロセスでは、高度な機能である分割と結合がサポートされます。

販売代理店（必須）

• トラフィック全体の入り口と同様に、HTTP トラフィックは最初にディストリビューターに到達します。ディストリビューターはインジェスターのハッシュ リングを保持し、次に gRPC を介して複数のインジェスターに並列に送信します。

インジェスター（必須）

• 必須コンポーネントと最も重要なコンポーネント
• デプロイする場合は、ホストごとに 1 つずつデプロイし、混在させないことをお勧めします。
• ディストリビュータから受信したデータはすぐにストレージに書き込まれるのではなく、メモリに保存され、その後定期的にバックエンド ストレージに更新されます。クエリが実行されると、リクエストの一部がインジェスターに送信されます。

クエリー（必須）

• クエリの実際のコア コンポーネントはキャッシュをサポートしており、HTTP を公開する最も外側のクエリ サービスとして使用できます。
• Querier で使用されるクエリ エンジンは引き続き PromQL であり、Prometheus のソース コードを直接参照します。
• Querier は、それぞれ ingester と store-gateway からデータを照会します。

クエリフロントエンド（オプション）

• クエリの効率を高速化できます (主にクエリを N 個の小さな範囲に分割することによって)。最終的に結果を集約し、最終結果をキャッシュできます。

クエリスケジューラ（オプション）

• 主な目的は、クエリフロントエンドのスケーリング問題を解決することです。簡単に言えば、クエリ フロントエンドはタスク キューを維持し、データ集約などの操作を実行します。クエリフロントエンドを拡張して内部キューの増加を引き起こすことは望ましくありません。 query-frontend が増加するたびに、querier 内にキューをプルするための新しいワーカーが生成され、多数のクエリが同時に処理され、-querier.max-concurrent を超えることになります。

ストアゲートウェイ（必須）

• クエリ効率を高速化し、クエリ オブジェクト ストレージの要求数を減らすには、Querier と Ruler が必要です。
• 注: 実稼働環境では、memcached のレイヤーを追加する必要があります。これにより、効率が大幅に向上します。キャッシュを使用しない場合、チャンクは毎回ダウンロードされます。

定規（オプション）

• ログ記録およびアラート ルールで定義された PromQL 式を評価するために使用されます。
• 各テナントには一連のログ記録およびアラート ルールがあり、これらのルールは名前空間にグループ化できます。

アラートマネージャー (オプション)

• Mimir Alertmanager は、Prometheus Alertmanager にマルチテナント サポートと水平スケーラビリティを追加します。
• Mimir Alertmanager は、Mimir ルーラーからのアラート通知を受け入れるために使用されるオプションのコンポーネントです。
• 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 の 3 つのインスタンス。マルチテナントが有効になっています (テナント ID は demo です)。
• Prometheus - Mimir メトリックをスクレイピングし、それを Mimir に書き戻して利用できるようにします。
• MinIO - ブロック、ルール、アラート用の S3 互換のソフトウェア定義の永続ストレージ。
• Grafana - Mimir をクエリするためのデータ ソースがプリインストールされており、Mimir を監視するためのダッシュボードもプリインストールされています。
• Nginx - Mimir インスタンスを公開する NGINX ベースのロード バランサー。

起動後は、次のポートを使用してアクセスできます。

• グラファナ: http://localhost:9000
• ミミル: 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 コンポーネントのステータスを表示できます。

ミミルの使用

Grafana にアクセスするには、ブラウザを起動して http://localhost:9000 を開きます。 Grafana を使用して、Mimir クラスターのステータスを示すダッシュボードを表示します。ダッシュボードは、表示するメトリックについて Mimir にクエリを実行します。左上隅のメニューから [ダッシュボード] をクリックし、[参照] をクリックして、このチュートリアル用にプリロードされているダッシュボードを表示します。これらのダッシュボードは、Grafana Labs のベスト プラクティス ダッシュボード、記録ルール、および Mimir を監視するためのアラートをパッケージ化した Grafana Mimir ミックスインから提供されます。

コンテナを起動した後、メトリックが Grafana ダッシュボードに表示されるまでに通常 3 ～ 5 分かかります。また、Mimir は Ingress ゲートウェイ、クエリ スケジューラ、または memcache なしで実行されるため、関連するダッシュボードは空になります。

まず、書き込み、読み取り、クエリ、およびオブジェクト ストレージのダッシュボードを参照します。たとえば、Object Storage ダッシュボードには、Mimir の起動後に発生した操作が表示されます。

記録ルールの設定

記録ルールは、頻繁に必要となる式やコストのかかる式を事前に計算し、その結果を新しい時系列セットとして保存するメカニズムです。以下の手順に従って、Grafana を使用して Mimir で記録ルールを設定できます。

たとえば、sum:up ログ ルールでは、稼働していてスクレイピング可能な Mimir インスタンスの数が表示されます。ルールを作成したら、それをクエリしてダッシュボードに含めることができます。

左側のツールバーからアラート メニュー ページを開き、[アラート ルールの作成] ボタンをクリックして新しいアラート ルールを作成します。

録画ルールを構成するには、次の手順に従います。

• Mimir または Loki の録画ルールを選択します。
• ルール名 sum:up を入力します。
• データ ソースの選択フィールドで Mimir を選択します。
• 名前空間: example-namespace。
• グループ: example-group。
• クエリ式: sum(up)。
• 右上隅の「保存して終了」を選択します。

新しい録画ルールが正しく機能していることを確認するには、左側のメニューから [探索] ページを開きます。

「メトリック」ドロップダウン リストで sum:up を選択し、右上隅の「クエリの実行」をクリックして、「インスペクター」ボタンをクリックします。下にある「データ」をクリックすると、時間リストとクエリ結果が表示されます。結果は 3 となり、Mimir のローカル インスタンスが 3 つ実行されていることを示します。

アラームルールを設定する

Mimir 上に構築されたアラート ルールは、Prometheus および Loki 上に構築されたアラート ルールと同じ PromQL 形式に従います。 Grafana は式を評価し、必要に応じて Alertmanager を使用してアラートを発します。

ここでは、Mimir インスタンスの数が 3 未満になったときに発生するアラームを作成します。また、左側のメニューで「アラート」をクリックし、「アラート ルール」ページに切り替えて「アラート ルールの作成」をクリックします。

ここで、Mimir または Loki アラートを選択し、アラート ルールを次のように設定する必要があります。

• ルール名: MimirNotRunning。
• データ ソースの選択フィールドで Mimir を選択します。
• 名前空間: example-namespace。
• グループ: example-group。
• クエリ式: up == 0。
• 右上隅の「保存して終了」を選択します。

作成されると、Mimir のログ記録ルールとアラート ルールが表示されます。すべての Mimir コンテナがまだ実行中であるため、アラートの横に大きくてわかりやすい緑色の OK ステータスが表示されていることに注意してください。

次に、3 つの Mimir インスタンスのうちの 1 つを終了して、エラー状況をシミュレートしてみましょう (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 の内部ヘルスチェックによって、終了したインスタンスが正常でないことが検出されると、この問題は自動的に解決されます。

約 1 分後、アラームはすぐに黄色の保留ステータスを表示します。

さらに 1 分後、アラームは赤色の「発火中」状態に変わります。

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 の普遍性、コスト効率、および高い耐久性を活用できるようにします。