Posted inMonitoring

Prometheus & GrafanaによるHAProxy監視：障害が起きてからでは遅すぎる

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

ロードバランサーを監視なしで運用するのが「自殺行為」である理由

午前2時、携帯電話が激しく震える。上司からの連絡だ。「ウェブサイトが落ちている。すぐに確認してくれ！」。慌てて各バックエンドのクラスターにSSHでログインしたが、サービスは正常に動いている。HAProxyのログを詳しく調べてようやく、1台のサーバー의メモリがハングアップしており、そこへのリクエストがすべて504 Gateway Timeoutになっていたことが判明した。適切なダッシュボードがなかったために、原因特定までに1時間以上も費やしてしまったのだ。

監視なしでHAProxyを運用することは、夜間にヘッドライトを消してトラックを運転するようなものです。車が動いていることはわかっても、エンジンが100度に達しているのか、タイヤがパンクしそうなのかはわかりません。私たちに必要なのは「語る数字」です。1秒あたりのリクエスト数（RPS）はどのくらいか？どのサーバーが「息絶え絶え」の状態か？レスポンスタイムは50msで安定しているのか、それとも5sまで跳ね上がっているのか？

この記事では、トラブル時に「暗闇で針を探す」ような事態を避けるため、HAProxy – Prometheus – Grafanaの3点セットを構築する方法を解説します。

動作モデル：Exporter – Prometheus – Grafana

HAProxyはstatsページを通じて生データを提供しますが、履歴を保存することはできません。時系列グラフを作成するには、以下の標準的なプロセスが必要です。

  • HAProxy Exporter: 「通訳者」の役割を果たします。HAProxyからデータを取得し、Prometheusが読み取れる形式に変換します。
  • Prometheus: 中央の「脳」です。15秒ごとにExporterにアクセスして最新データを取得し、データベースに保存します。
  • Grafana: 表示レイヤーです。Prometheusからデータをクエリし、直感的なグラフとして描画します。これにより、異常を3秒で発見できるようになります。

ステップバイステップの設定ガイド

ステップ1：HAProxyでメトリクスを有効にする

バージョン2.0以降、HAProxyにはPrometheus向けのデータ出力機能が組み込まれています。/etc/haproxy/haproxy.cfgファイルを開き、以下の設定を追加するだけです。

frontend stats-monitoring
    bind *:8404
    http-request use-service prometheus-exporter if { path /metrics }
    stats enable
    stats uri /stats
    stats refresh 10s

構文をチェックして新しい設定を適用します：

haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

次に、http://<IP-Server>:8404/metricsにアクセスしてください。haproxy_frontend_bytes_in_totalのような長いリストが表示されれば、最も難しいステップは完了です。

ステップ2：PrometheusをHAProxyに接続する

prometheus.yml設定ファイルを開きます。Prometheusにデータの取得先を教える必要があります。scrape_configsセクションに以下の設定を追加します。

scrape_configs:
  - job_name: 'haproxy_production'
    scrape_interval: 15s
    static_configs:
      - targets: ['<IP-HAProxy>:8404']

Prometheusを再起動した後、**Status -> Targets**に移動します。haproxy_productionのステータスが緑色の**UP**になっていれば、データがストレージに蓄積され始めています。

ステップ3：プロフェッショナルなGrafanaダッシュボードをセットアップする

ゼロからグラフを描く時間は無駄にしないでください。コミュニティが非常に優れたダッシュボードを既に用意しています。ダッシュボードID **12633**（組み込み版用）または**367**をお勧めします。

  1. Grafanaのインターフェースで、プラス記号（+）アイコンをクリックし、**Import**を選択します。
  2. “Import via grafana.com”の欄にID 12633 を入力します。
  3. Data Sourceで、設定済みのPrometheusを選択します。
  4. **Import**をクリックします。CPU、メモリからLatencyまで、完全なグラフシステムが即座に表示されます。

監視すべき4つの「死活」指標

ダッシュボードを見る際は、細かい数字は無視して以下の4つのパラメータに集中してください。

1. Backend Status: この指標は常に「緑」である必要があります。バックエンドサーバーが1台でも「赤」になると、HAProxyは残りのサーバーに全負荷を転送します。迅速に対処しないと、ドミノ倒しのようにシステム全体がダウンしてしまいます。

2. HTTP Error Rate (4xx & 5xx): 通常、5xxエラー率はほぼ0%であるべきです。この数字が1%を超えた場合、アプリケーションコードのバグやデータベースの過負荷の兆候です。4xxエラーの急増は、通常、ブルートフォース攻撃や脆弱性スキャンの兆候です。

3. Maxconn & Session Usage: 各サーバーには負荷の限界があります。Active Sessionsがmaxconnの80%に達すると、リクエストがキュー（待ち行列）に入り、ユーザーはウェブサイトの読み込みが遅いと感じ始めます。

4. Response Time (P99 Latency): 平均値（Average）だけを見ないでください。P99に注目しましょう。P99が2秒であれば、ユーザーの1%がページの読み込みに丸2秒待たされていることを意味します。これは顧客体験を反映する最も現実的な数字です。

結論

監視は単に見栄えを良くしたり、上司に報告したりするためのものではありません。それは、エンジニアが安眠するためのツールです。ユーザーから不満が出るのを待つのではなく、自らトラブルを事前に察知して対処できるようになります。実際のプロジェクトでロードバランサーを運用しているなら、今日15分時間を割いて、このツールセットを導入してください。正確なデータこそが、システムを最も効率的に最適化するための鍵となります。

Share:
Tags: