RabbitMQ監視の極意：クラスターがダウンしてから慌てないための秘策 – ITFROMZERO

Table of Contents

午前2時の出来事：キューの滞留でシステムが沈黙した時

深夜に鳴り響くPagerDutyの通知音は、すべての運用エンジニアにとって悪夢です。ある時、私たちの決済システムが突然フリーズしました。注文データはデータベースに登録されず、ログには Gateway Timeout のエラーが並ぶばかり。冷や汗をかきながら30分かけて各ノードにSSHで入り、 rabbitmqctl list_queues を叩いてようやく原因を突き止めました。一つのキューに150万件以上のメッセージが滞留していたのです。この大量েরメッセージが8GBのRAMを使い果たし、クラスター全体がハングアップしていました。

適切な監視システムを構築する前は、このようにトラブルが起きてから手動でコマンドを叩いて調査する「その場しのぎ」の対応ばかりでした。しかし今では、Grafanaのダッシュボードを見るだけで、どのワーカーが遅延しているか、どのキューが膨れ上がっているかが一目でわかります。枕を高くして眠りたいなら、PrometheusとGrafanaを導入して、RabbitMQをプロアクティブに管理しましょう。

5分で完了するクイックデプロイ

RabbitMQ バージョン3.8以降、Prometheus用のエンドポイントが標準統合されました。以前のようにサードパーティのexporterをインストールする必要がなくなり、エラーの原因になりやすい中間レイヤーを削減できます。

ステップ1：内蔵プラグインの有効化

RabbitMQサーバー上で、以下のコマンドを実行して監視プラグインを有効にします。

rabbitmq-plugins enable rabbitmq_prometheus

有効化すると、RabbitMQはポート15692を開放します。 curl コマンドを使用して、データが出力されているか確認してください。

curl http://localhost:15692/metrics

画面に rabbitmq_queue_messages_ready といった行と具体的な数値が表示されれば、最初のステップは成功です。

ステップ2：Prometheusへの登録

prometheus.yml ファイルに以下の設定を追加し、システムの定期的なデータ収集（スクレイピング）を開始します。

scrape_configs:
  - job_name: 'rabbitmq-production'
    scrape_interval: 15s # 間隔が短すぎるとリソースを消費し、長すぎると予兆を見逃します
    static_configs:
      - targets: ['10.0.1.50:15692'] # サーバーのIPアドレスに置き換えてください

ステップ3：Grafanaダッシュボードの設定

グラフを一つずつ手動で作成する代わりに、RabbitMQ公式チームが提供している標準テンプレートを使用しましょう。

Grafanaにアクセスし、 Dashboards > Import を選択します。
ID 10991 を入力します（これが現在最も標準的なテンプレートです）。
データソースとして先ほど設定したPrometheusを選択し、 Import をクリックします。

特に注意すべき4つの「死活」メトリクス

ダッシュボードには多くの情報が表示されますが、高負荷時には以下の重要指標に集中してください。

1. メッセージの状態：Ready vs Unacknowledged

Ready: 待機中のメッセージ。この数値が100,000（RAM構成による）を超えると、コンシューマーの処理が追いついていない兆候です。
Unacknowledged: 送信済みだが処理完了の確認が取れていないメッセージ。この数値が高い場合、ワーカーのコードがフリーズしているか、ロジックエラーでタスクを完了できていない可能性が高いです。

2. メッセージ流量（Publish vs Deliver Rate）

システムの均衡状態を示すグラフです。 Publish （投入）速度が Deliver （配信）速度を10〜15分間上回り続けると、キューは確実に溢れます。健全なシステムでは、この2つのラインが近い数値で推移します。

3. ファイルディスクリプタ (FD)

アプリケーションからRabbitMQへの接続ごとに、ファイルディスクリプタが一つ開かれます。Linuxのデフォルト制限（通常1024）はメッセージングシステムとしては低すぎます。ダッシュボードでFD使用率が80%以下に保たれていることを確認し、突然の接続拒否を防ぎましょう。

4. Erlang Memory Alarm

RAM使用率が40%（デフォルト）に達すると、RabbitMQは「メモリアラーム」を発動してメッセージの受信を停止し、システムを保護します。アプリケーションで500エラーが多発する事態を避けるため、このグラフが閾値に達しないよう注意してください。

Telegramへの自動アラート通知設定

ダッシュボードは画面を見ている時しか役に立ちません。真の自動化にはAlertmanagerが必要です。以下は、キューの滞留が50,000件を超えた際のアラートルールの例です。

- alert: RabbitMQQueueBacklog
  expr: rabbitmq_queue_messages_ready > 50000
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "キュー {{ $labels.queue }} で滞留が発生しています！"
    description: "vhost {{ $labels.vhost }} にて、現在 {{ $value }} 件の未処理メッセージがあります。"

実戦での教訓：ディスク容量の不足に注意

RabbitMQには非常に厳格な Disk Alarm というメカニズムがあります。ディスクの空き容量が50MBを下回ると、すべてのデータ流入を遮断します。以前、コードにバグはなくRAMも余裕があるのに、ログファイルがディスクを圧迫したせいでメッセージが送信できなくなったケースがありました。

アドバイス： RabbitMQサーバーのディスク容量も必ず監視対象に含めてください。また、数千の動的キューが存在するシステムでは、メトリクスのスクレイピングを制限してPrometheusの過負荷（High Cardinality問題）を避けるべきです。ビジネス的に重要なキューに絞って監視することをお勧めします。

監視体制を整えることは、トラブルシューティングを迅速化するだけでなく、トラフィックの成長傾向を把握することにも繋がります。これにより、システムが「悲鳴」を上げる前に、先回りしてワーカーをスケールさせることができます。安定したRabbitMQ運用で、安眠できる夜を手に入れましょう！