HAProxy は今日最も高速かつ広く使われているロードバランシングソリューションの一つです。すでに HAProxy を使っている、あるいはこれから使おうと考えているなら、 HAProxy のロギングも理解は必須です。
HAProxy のロギングがロードバランサーの実装に不可欠な理由、HAProxy が提供するロギング、そして独自のニーズに合わせて HAProxy のログを管理・設定する方法をご説明しましょう。
ロードバランサーのロギングが重要な理由
ロードバランサー はアプリケーションを外部に接続する際に必要不可欠です。すべてのインバウンドリクエストを分析、検証し、適切なバックエンドサーバーに渡します。しかし、ロードバランサーは単にトラフィックのルーティングだけではありません。アプリケーションの健全なインスタンスにリクエストを分散し不健全なインスタンスにリクエストが到達しないようにし、 高い可用性を保証します。
ロードバランサは全てのリクエストを扱うので、接続性の問題が発生すると、しばしば調査の焦点になります。だから、HAProxyのロギングが重要なのです。リクエストフロー、パフォーマンスメトリクス、そして潜在的な障害を詳細に可視化します。HAProxyのログを解析し、異常を検知し、スムーズな運用を実現します。
HAProxy のログモニタリングが重要なのか？
HAProxyログはミリ秒単位の精度を提供し、マクロとミクロのレベルでインフラストラクチャに関する実用的なデータを提供できｍす。HAProxy のログから得られる情報と、それぞれのログエントリがアプリケーションの包括的なオブザーバビリティを提供するのにどのように役立つかを見てみましょう。
トラフィックメトリクス
アプリケーションを通過するトラフィック量を追跡することで、リソース配分の必要性を理解し、障害の発生方法、理由と発生時期に関する重要な洞察を得られます。
リクエストとレスポンスの詳細
対象のユーザーまたは地域に影響を及ぼすエラー状況を調査している場合、リクエストヘッダ、レスポンスヘッダ、ペイロード、およびステータスコードを検査することで、問題の正確な原因を切り分けられます。また、クライアントが経験する可能性のある動作についての詳細な情報も提供します。
ルーティングの決定
HAProxy のログには、リクエストがどのようにルーティングされたか、どのバックエンドに割り当てられたか、フィルタや永続化ルールが適用されたか、などの情報も含まれます。このデータは、効率的なトラフィック配分とセキュリティコンプライアンス確保に役立ちます。
エラートレース
最後に、HAProxyのログはエンジニアがリクエストのライフサイクルの失敗の特定に使用できる情報を含んでいます。これらのログには、アクティブなセッションとその終了ステータスに関する情報を含められます。
HAProxy ロギング：デフォルトと設定済みのロギング形式
HAProxyはHAProxy設定ファイル内の設定からロギング形式を派生させます。 オプション ディレクティブを設定から除外するか、2 つの設定済みフォーマットのうちの 1 つを設定することで、デフォルトのロギングフォーマットを使えます。
HAProxyの2つの主要なロギングオプションは以下の通りです：
- TCP またはレイヤ 4 動作モードの場合、含めるディレクティブは option tcplog
- HTTP またはレイヤ 7 操作モードの場合、設定ディレクティブは option httplog
それぞれのログフォーマットがどのように機能し、どのようなデータを提供するのか、詳しく見てみましょう。
以下のログの例は、AWS Linux 4.14を実行するAWSインスタンスにインストールされたHAProxyバージョン2.4.2のインスタンスからのもので、同じサブネット内の2つのHTTPサーバ間のトラフィックを管理するよう設定されています。ログはRSyslogによりキャプチャされ、ホストサーバーのローカルに保存されました。
デフォルトのログ形式 (オプションの設定なし)
Jul 12 06:32:30 localhost haproxy[2679]：67.171.183.156:50871 から 172.31.30.201:80 (http_front/TCP) に接続
| Jul 12 06:32:30 | ログタイムスタンプ |
| ローカルホスト | HAProxy ホストのホスト名または IP アドレス |
| haproxy[2679]： | HAProxy プロセスのプロセス IDです。 |
| 67.171.183.156:50871 から 172.31.30.201:80 に接続 | 接続元IP:接続元ポート宛先IP:宛先ポート |
| (http_front/TCP) | フロントエンド名 / フロントエンドモード |
TCP / レイヤー 4 ログフォーマット (オプション tcplog)
Jul 12 06:24:02 localhost haproxy[2590]: 67.171.183.156:54500 [12/Jul/2021:06:23:21.058] http_front http_back/webserver1 1/0/40996 383 -- 2/2/1/0/0 0/0
| Jul 12 06:24:02 | ログタイムスタンプ |
| ローカルホスト | HAProxy ホストのホスト名または IP アドレス |
| haproxy[2590]： | HAProxy プロセスのプロセス IDです。 |
| 67.171.183.156:54500 | 送信元 IP:送信元ポート |
| [12/Jul/2021:06:23:21.058] | ミリ秒の精度でタイムスタンプ要求を受理 |
| http_front | フロントエンド名 |
| http_back/webserver1 | ターゲット要求はにルーティングされました |
| 1/0/40996 | キューでの待ち時間(ms) / 宛先サーバーへの接続確立時間(ms) / リクエスト受信から最終クローズまでの合計時間(ms) |
| 383 | バイト読み取り |
| — | –に続く終了ステータス |
| 2/2/1/0/0 | アクティブな接続 /フロントエンド接続 /バックエンド接続 /サーバー接続 /リトライ |
| 0/0 | サーバキュー /バックエンドキュー |
HTTP / レイヤー 7 (オプション httplog)
7/12 05:54:55 localhost haproxy[1060]: 67.171.183.156:64978 [12/Jul/2021:05:54:55.077] http_front http_back/webserver1 0/0/0/1/1 200 288 - - ---- 2/2/0/0 0/0 "GET / HTTP/1.1"
| 7/12 05:54:55 | ログタイムスタンプ |
| ローカルホスト | HAProxy ホストのホスト名または IP アドレス |
| haproxy[1060]： | HAProxy プロセスのプロセス IDです。 |
| 67.171.183.156:64978 | 送信元 IP:送信元ポート |
| [12/Jul/2021:05:54:55.077] | ミリ秒の精度でタイムスタンプ要求を受理 |
| http_front | フロントエンド名 |
| http_back/webserver1 | ターゲット要求はにルーティングされました |
| 0/0/0/1/1 | クライアントからのフルリクエストの待ち時間(ms) / キューでの待ち時間(ms) / 送信先サーバーへの接続確立までの時間(ms) / 送信先サーバーからのレスポンス送信までの時間(ms) / HAProxyでアクティブなリクエストの合計時間(ms) |
| 200 | HTTP レスポンスコード |
| 288 | バイト読み取り |
| – – | オプション値：キャプチャされたリクエスト Cookieキャプチャされたレスポンス Cookie |
| —- | –に続く終了ステータス |
| 2/2/0/0/0 | アクティブな接続 /フロントエンド接続 /バックエンド接続 /サーバー接続 /リトライ |
| 0/0 | サーバキューサイズ / バックエンドキューサイズ |
| “get / http/1.1” | HTTP リクエスト |
HAProxy ログ形式のカスタマイズ
デフォルトおよび設定済みのHAProxyのログフォーマットは実質的な洞察を提供しますが、SSL暗号化をサポートするアクティビティ、ヘッダ、およびペイロード自体に関連する重要なメトリクスやログ要素が欠けている可能性があります。これらの要素は、ログのデータ量を大幅に増やし、問題解決に役立ちます。
カスタマイズされたログ書式を使いたい場合は、 option ディレクティブを log-format ディレクティブで置き換え、その後に希望するログメッセージの内容や形式を示す文字列を指定します。上で説明した HTTP ログの書式を再現すると、ディレクティブは次のようになります：
log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"
利用可能なオプションとその正しい使い方の完全なリファレンスは HAProxy ドキュメントにあります。高度なトラブルシューティングのサポートのために、利用可能なオプションをいくつか含めることができます：
- 接続ハンドシェイク時間 (%Th)
- SSL 暗号とバージョン (%sslc / %sslv)
- リクエスト・ヘッダ (CLF フォーマットの場合は %hr または %hrl)
- レスポンス・ヘッダ (CLF フォーマットの場合は %hs または %hsl)
- 完全な HTTP リクエスト (%r)
スケールでの HAProxy ログボリュームの管理
HAProxy は現在利用可能な最も効率的なロードバランシングソリューションの一つで、毎秒数千のリクエストを処理できます。HAProxy は各リクエストに対して簡単にログエントリを作成できますが、 トラフィックがスケールするにつれてログデータの量も増え、 ディスクストレージを圧迫し、手動でのログ解析が非現実的になる可能性があります。
これを効率的に管理するため、Sumo Logic のような集中型ログ管理ソリューション を活用し、自動異常検知を実装して問題が発生したときにチームに警告することを検討してください。リアルタイムのログ集計と自動化されたアラートにより、チームは問題を積極的に検出し、大量のログデータを処理し、パフォーマンスを最適化します。
HAProxyとSumo Logicの 統合の詳細 と、 無料トライアルにサインアップ してログ管理の効率化をご確認ください。
