8. ロギング

HAProxy はファイル システム アクセスを実行しないため、ロギングに関しては常に syslog サーバーに依存します。標準的な使用方法は、UDP 経由でログ サーバー (デフォルトではポート 514) にログを送信することです。通常、これはローカル syslog デーモンが実行されている 127.0.0.1 に設定されますが、中央サーバーにログを記録するためにネットワーク経由でも使用されます。中央サーバーは、特にログを到着順にマージしておくことが望ましいアクティブ/アクティブ シナリオで追加の利点を提供します。 HAProxy は、UNIX ソケットを使用してログをローカル syslog デーモンに送信することもできますが、HAProxy の実行中に syslog サーバーが再起動されるとソケットが置き換えられ、新しいログが失われるため、これはまったく推奨されません。 HAProxy は chroot ジェイル内に隔離されるため、新しいソケットに再接続する機能はありません。また、UNIX ソケットで使用されているログ バッファが非常に小さいため、負荷が非常に軽い場合でもメッセージが失われる可能性があることが現場で観察されています。ただし、これはテストには問題ありません。

次のディレクティブを「global」セクションに追加して、ファシリティ “local0"を使用して HAProxy ログをローカル デーモンに記録することをお勧めします。

log 127.0.0.1:514 local0

次に、次の行を各"defaults” セクション、または各フロントエンドとバックエンドのセクションに追加します。

log global

このようにして、ログ サーバーの場所のグローバル定義を通じてすべてのログが一元化されます。

一部の syslog デーモンはデフォルトでは UDP トラフィックをリッスンしないため、使用するデーモンに応じて、これを有効にする構文は異なります。

• sysklogd では、デーモンのコマンド ラインで引数「-r」を渡して、「リモート」ログの UDP ソケットをリッスンする必要があります。アドレス 127.0.0.1 に制限する方法はないので、リモート システムからもログを受信することになることに注意してください。

• rsyslogd では、次の行を構成ファイルに追加する必要があります。

$ModLoad imudp
$UDPServerAddress *
$UDPServerRun 514

• syslog-ng では、次の方法で新しいソースを作成できます。その後、「log」ディレクティブの 1 つに有効なソースとして追加する必要があります。

source s_udp {
  udp(ip(127.0.0.1) port(514));
};

詳細については、syslog デーモンのマニュアルを参照してください。システムのログ ファイルにログが見つからない場合は、次のテストを検討してください。

• haproxy を再起動します。各フロントエンドとバックエンドは、開始を示す 1 行をログに記録します。これらのログが受信された場合は、ログが動作していることを意味します。

• 「strace -tt -s100 -etrace=sendmsg -p <haproxy’s pid>」を実行し、ログに記録されると予想されるアクティビティを実行します。 sendmsg() を使用して送信されているログ メッセージが表示されるはずです。表示されない場合は、HAProxy 上で strace を使用して再起動します。それでもログが表示されない場合は、構成に何か問題があることを意味します。

• tcpdump を実行して、ポート 514 を監視します。たとえば、トラフィックがローカルに送信されている場合は、ループバック インターフェイス上で「tcpdump -As0 -ni lo port 514」となります。パケットがそこに見られる場合、それはパケットが送信された証拠であるため、syslogd デーモンのトラブルシューティングが必要です。

トラフィック ログはフロントエンド (受信接続が受け入れられる場所) から送信されますが、ヘルスチェックに続いてサーバー状態の変化を報告するために、バックエンドもログを送信できる必要があります。考えられるすべてのログ設定の詳細については、HAProxy の構成マニュアルを参照してください。

他のデーモンが使用していないファシリティを選択すると便利です。 HAProxy の例では、トラフィック ログには「local0」、管理ログには「local1」が推奨されることがよくあります。これは、これらは実際には表示されないためです。ファシリティは一つでも十分です。個別のログがあるとログ分析には便利ですが、ログには機密情報が含まれる場合があるため、権限のない人に誤って渡される可能性のある他のログと混ぜてはいけないことにも留意することが重要です。

サーバーの容量に大きな影響を与えずに現場でトラブルシューティングを行うには、HAProxy で提供される「halog」ユーティリティを使用することをお勧めします。これは、非常に高速なデータ速度で HAProxy ログ ファイルを処理するように設計された grep に似たユーティリティです。一般的な数値は、1 秒あたり 1 ～ 2 GB のログの範囲です。特定のログのみを抽出し (例: HTTP ステータス コードの一部のクラスの検索、接続終了ステータス、応答時間の範囲による検索、エラーのみの検索)、行数のカウント、出力の行数の制限、および応答時間やエラー数によるサーバーの並べ替え、時間や回数による URL の並べ替え、アクセス数によるクライアント アドレスの並べ替えなどのより高度な統計の実行が可能です。サイト上でループするボットなどの異常をすぐに発見し、ブロックするのは非常に便利です。