HAProxyロギングの概要

Posted on
haproxyでのロギング

ログデータの操作に関しては、HAProxyは豊富な情報を提供します。 このブログ記事では、Haproxyログの設定方法、Syslogサーバーのターゲット設定方法、ログフィールドの理解方法、ログファイルの解析に役立つツールの提案方法を示しま

HAProxyロギングへの深いダイビング

haproxyは、インフラストラクチャのクリティカルパスに位置しています。 Edge load balancer、sidecar、またはKubernetes ingress controllerとして使用されるかどうかにかかわらず、haproxyから意味のあるログを取得することは必須です。

ロギングは、各接続と要求に関する洞察を提供します。 これは、トラブルシューティングに必要な可観測性を可能にし、さらには早期に問題を検出するために使用することができます。 これは、HAProxyから情報を取得する多くの方法の1つです。 その他の方法としては、統計ページまたはランタイムAPIを使用したメトリックの取得、電子メールアラートの設定、さまざまなオープンソース統合を使用して、ログまたは統計データを経時的に保存する方法があります。 HAProxyはミリ秒の精度で非常に詳細なログを提供し、インフラストラクチャに流入するトラフィックに関する豊富な情報を生成します。 これには、

  • トラフィックに関するメトリック:タイミングデータ、接続カウンタ、トラフィックサイズなどが含まれます。
  • HAProxyの決定に関する情報：コンテンツの切り替え、フィルタリング、永続性など
  • 要求と応答に関する情報:ヘッダー、ステータスコード、ペイロードなど。
  • セッションの終了ステータスと障害が発生している場所を追跡する機能（クライアント側、サーバー側？この記事では、HAProxyロギングの設定方法と、HAProxyが生成するログメッセージの読み取り方法について説明します。 次に、ログデータを操作するときに役立つツールをいくつかリストします。Haproxyは、syslogサーバーによる処理のためのログメッセージを出力できます。 これは、Rsyslogのような使い慣れたsyslogツールや、新しいsystemdサービスjournaldと互換性があります。 また、LogstashやFluentdのようなさまざまなログフォワーダを利用して、HaproxyからSyslogメッセージを受信し、中央のログアグリゲータに出荷することもできます。コンテナ環境で作業している場合、HaproxyはCloud Native Loggingをサポートしており、ログメッセージをstdoutおよびstderrに送信できます。 その場合は、どのように表示されます次のセクションにスキップします。HAProxy設定ファイルを使用してロギングを有効にする方法を検討する前に、まずrsyslogなどのSyslogサーバーがログを受信するように構成されていることを確認 Ubuntuでは、aptパッケージマネージャーを使用してrsyslogをインストールします。

    rsyslogがインストールされたら、haproxyログメッセージの取り込みを処理するように設定を 次のいずれかを/etc/rsyslogに追加します。confまたはrsyslog内の新しいファイルに。/etc/rsyslogのようなdディレクトリ。d/haproxy.conf:

    次に、rsyslogサービスを再起動します。 上記の例では、rsyslogはデフォルトのUDPポート514でIPループバックアドレス127.0.0.1をリッスンします。 この特定の設定は、2つのログファイルに書き込みます。 選択されたファイルは、メッセージがログに記録された重大度レベルに基づいています。 これを理解するには、ファイルの最後の2行を詳しく見てください。 彼らはこのように始まります:

    Syslog標準では、ログに記録された各メッセージに施設コードと重大度レベルを割り当てる必要があることが規定されています。 上記のrsyslog設定の例を考えると、すべてのログメッセージをlocal0の機能コードで送信するようにHAProxyを設定すると仮定できます。

    重大度レベルは、施設コードの後にドットで区切られて指定されます。 ここでは、最初の行はすべての重大度レベルでメッセージをキャプチャし、haproxy-trafficと呼ばれるファイルに書き込みます。ログ… 2行目は通知レベル以上のメッセージのみをキャプチャし、haproxy-adminというファイルに記録します。ログ…

    HAProxyは、特定のメッセージを送信するときに特定の重大度レベルを使用するようにハードコードされています。 たとえば、接続およびHTTP要求に関連するログメッセージをinfo重大度レベルで分類します。 他のイベントは、他のより冗長なレベルのいずれかを使用して分類されます。 最も重要なものから最も重要なものまで、重大度レベルは次のとおりです。

    重大度レベル HAProxy Logs
    emerg オペレー
    alert レスポンスをキャッシュできないなど、予期しないことが起こったまれなケースがあります。
    crit 使用されていません。
    err マップファイルを解析できない、HAProxy設定ファイルを解析できない、スティックテーブルに対する操作が失敗したときなどのエラー。
    警告 要求ヘッダーの設定に失敗したり、DNSネームサーバーへの接続に失敗したりするなど、重要ではありますが重要ではないエラーがあります。
    注意 は、アップまたはダウンしているか、サーバーが無効になっているなど、サーバーの状態に変更されます。 プロキシの起動やモジュールの読み込みなど、起動時の他のイベントも含まれています。 ヘルスチェックのログ記録が有効になっている場合は、このレベルも使用されます。
    情報 TCP接続とHTTP要求の詳細とエラー。
    デバッグ デバッグメッセージを記録するカスタムLuaコードを書くことができます

    現代のLinuxディストリビューションは、ログを収集して保存するためのjournaldを導入したservice manager systemdに同梱されています。 JournaldサービスはSyslogの実装ではありませんが、同じ/dev/logソケットでリッスンするため、Syslogと互換性があります。 受信したログを収集し、ユーザーが同等のjournaldフィールド（SYSLOG_FACILITY、PRIORITY）を使用して、施設コードや重大度レベルでそれらをフィルタリングできるようにします。最初は、logglobalセクションでSyslogサーバーを指定することです。

    logglobalセクションでSyslogサーバーを指定することです。

    logディレクティブは、HAProxyに指示します。127.0.0.1:514でリッスンしているsyslogサーバにログを送信します。 メッセージは、標準のユーザ定義のSyslog機能の1つであるfacility local0とともに送信されます。 これは、rsyslog構成が期待している機能でもあります。 複数のlogステートメントを追加して、出力を複数のSyslogサーバーに送信できます。

    行末にSyslogレベルを追加することで、ログに記録される情報の量を制御できます。

    ロギングを設定するための第二のステップは、異なるプロキシ(frontendbackendlistenセクション)を更新して、ログに記録されるSyslogサーバーにメッセージを送信することです。globallog globaldefaultsセクションに追加できます。

    log globalloggloballog globaldefaultsセクションに入れることは、後続のすべてのプロキシセクションに入れることと同じです。 そのため、これによりすべてのプロキシでのログ記録が有効になります。 HAProxy設定ファイルのセクションの詳細については、ブログ記事The Four Essential Sections of an HAProxy Configurationを参照してください。デフォルトでは、HAProxyからの出力は最小限です。 option httplogdefaultsセクションに追加すると、より詳細なHTTPロギングが有効になります。

    典型的なHAProxy設定は次のようになります。

    グローバルロギングルールを使用することが最も一般的なHAProxy設定ですが、代わりにfrontendセクションに直接置くことができます。 一回限りのログ設定として別のログ設定を使用すると便利です。 たとえば、バックエンドアプリケーションのユースケースに応じて、別のターゲットSyslogサーバーをポイントしたり、別のロギング機能を使用したり、別の重大度レベ frontendセクションfe_site1とfe_site2が異なるIPアドレスと重大度レベルを設定する次の例を考えてみましょう。

    ローカルSyslogサービスにログ 一般的に、Linuxシステムでは、SyslogメッセージをリッスンするUNIXソケットは/dev/logで利用できます。これは、GNU cライブラリのsyslog()関数がデフォルトでメッセージを送信している場所であるためです。 次のようにUNIXソケットを対象とします。

    しかし、ロギングにUNIXソケットを使用すると同時に、chrootされた環境内でHAProxyを実行している場合、またはchroot設定ディレクティブを使用してHAProxyにchrootディレクトリを作成させる場合は、そのCHROOTディレクトリ内でUNIXソケットを使用できるようにする必要があることに注意してください。 これは、2つの方法のいずれかで行うことができます。

    まず、rsyslogの起動時に、chrootファイルシステム内に新しいlisteningソケットを作成することができます。 Haproxy rsyslog設定ファイルに以下を追加します。

    第二の方法は、mount--bindオプションを使用して、手動でソケットをchrootフ/etc/fstabファイルまたはsystemdユニットファイルにエントリを追加して、再起動後もマウントが維持されるようにしてください。 ログを設定したら、メッセージの構造を理解する必要があります。 次のセクションでは、TCPおよびHTTPレベルのログを構成するフィールドが表示されます。保存されるデータの量を制限する必要がある場合は、ログメッセージの一部のみをサンプリングする方法があります。

    保存されるデータの量を制限す ランダムな数のリクエストに対してログレベルをsilentに設定します。

    可能であれば、できるだけ多くのデータをキャプチャする方が良いことに注意してください。 そうすれば、あなたが最も必要なときに不足している情報を持っていません。 ACL式を変更して、特定の条件がルールを上書きするようにすることもできます。ログに記録されるメッセージの数を制限する別の方法は、defaultsfrontendoption dontlog-normal このようにして、タイムアウト、再試行、エラーのみがキャプチャされます。 これを常に有効にするのではなく、ベンチマークテストを実行するときなど、特定の時間にのみ有効にすることをお勧めします。Dockerコンテナ内でHAProxyを実行していて、Haproxyバージョン1.9を使用している場合は、ログ出力をSyslogサーバーに送信する代わりに、stdoutおよび/またはstderrに送信できます。 アドレスをそれぞれstdoutstderrrawに設定することもお勧めします。

    HAProxy Log Format

    表示されるログの種類は、HAProxy内で設定したプロキシモード HAProxyは、レイヤ4(TCP)プロキシまたはレイヤ7(HTTP)プロキシのいずれかとして動作できます。 TCPモードがデフォルトです。 このモードでは、クライアントとサーバの間に全二重接続が確立され、レイヤ7検査は実行されません。 最初のセクションの説明に基づいてrsyslog設定を設定した場合は、/var/log/haproxy-trafficにログファイルがあります。ログ…mode tcpを追加することで設定されるTCPモードの場合は、オプションtcplogも追加する必要があります。 このオプションを使用すると、ログ形式は、レイヤ4接続の詳細、タイマー、バイト数などの有用な情報を提供する構造体にデフォルト設定されます。 カスタム形式を設定するために使用されるlog-formatを使用してこの形式を再作成する場合は、次のようになります:

    これらのフィールドの説明は、TCPログ形式のドキュメントにありますが、今後のセクションでいくつか説明します。

    haproxy tcpログ形式

    HAPROXYのTCPログ形式

    HAProxyがmode httpを介してレイヤ7プロキシとして実行される場合は、option httplogディレクティブを追加する必要があります。 これにより、HTTP要求と応答が詳細に分析され、RFC準拠のコンテンツがキャプチャされないようになります。 これは、HAProxyの診断値を実際に強調するモードです。 HTTPログ形式は、TCP形式と同じレベルの情報を提供しますが、HTTPプロトコルに固有の追加データを提供します。 log-formatを使用してこの形式を再作成する場合、次のようになります。

    さまざまなフィールドの詳細な説明は、HTTPログ形式のドキュメントにあります。

    haproxy httpログ形式

    HAPROXYでHTTPログ形式

    また、必要なものだけをキャプチャし、カスタムログ形式を定義することもできます。 defaultsfrontendlog-format（構造化データsyslogの場合はlog-format-sd）ディレクティブを使用します。 詳細といくつかの例を見るために私たちのブログ記事HAProxyログのカスタマイズをお読みください。次のいくつかのセクションでは、option tcplogoption httplogを使用するときに含まれるフィールドに精通しています。

    プロキシ

    生成されるログファイル内で、各行は要求が送信されたフロントエンド、バックエンド、およびサーバーで始まります。 たとえば、次のHAProxy構成がある場合、要求がhttp-inフロントエンドを介して静的バックエンドにルーティングされ、次にsrv1サーバーにルーティングされていると

    これは、サーバーの一部にのみ影響するエラーが表示される場合など、要求が送信された場所を知る必要がある場合に重要な情報になります。

    タイマー

    タイマーはミリ秒単位で提供され、セッション中に発生するイベントをカバーします。 デフォルトのTCPログ形式でキャプチャされるタイマーはTw/Tc/Ttです。 デフォルトのHTTPログ形式で提供されるものは、TR/Tw/Tc/Tr/Taです。 これらは次のように変換されます。

    Timer 意味
    TR クライアント要求を取得する合計時間（HTTPモードのみ）。
    Tw 接続スロットを待機しているキューに費やされた合計時間。
    Tc サーバーへのTCP接続を確立するための合計時間。
    Tr サーバーの応答時間(HTTPモードのみ)。
    Ta HTTPリクエストの合計アクティブ時間(HTTPモードのみ)。
    Tt プロキシがそれを受け入れた瞬間から両端が閉じられた瞬間までの合計TCPセッション期間時間。

    利用可能なすべてのタイマーの詳細な説明は、HAProxyのドキュメントにあります。 次の図は、単一のエンドツーエンドトランザクション中に時間が記録される場所も示しています。 端の紫色の線はタイマーを示していることに注意してください。

    haproxy time recording

    単一のエンドツーエンドトランザクション中の時間記録

    切断時のセッション状態

    TCPログとHTTPログの両方に、TCPまたはHTTPセッションが終了した方法を示す終了状態コードが含まれています。 これは2文字のコードです。 最初の文字はセッションを終了させた最初のイベントを報告し、2番目の文字はセッションが閉じられたときのTCPまたはHTTPセッション状態を報告します。

    終了コードの例をいくつか示します。

    二文字コード 意味
    – 両側の通常の終了。
    cD クライアントはデータを送信も確認もせず、最終的にtimeout client期限切れになりました。
    SC サーバーが明示的にTCP接続を拒否しました。
    PC 接続しようとしている間にプロセスのソケット制限に達したため、プロキシがサーバーへの接続を確立することを拒否しました。

    接続が閉じられた理由はさまざまです。 すべての可能な終了コードに関する詳細情報は、HAProxyのドキュメントで見つけることができます。

    カウンタ

    カウンタは、要求が通過したときのシステムの正常性を示します。 HAProxyは、接続または要求ごとに五つのカウンタを記録します。 これらは、システムにどのくらいの負荷がかかっているか、システムが遅れている場所、制限に達したかどうかを判断する上で非常に貴重です。 ログ内の行を見ると、カウンターがスラッシュで区切られた5つの数字として表示されます：0/0/0/0/0。

    TCPモードまたはHTTPモードのいずれかで、これらは次のように分解されます。

    • セッションがログに記録されたときのHAProxyプロセス上の同時接続の合計数。
    • セッションがログに記録されたときに、このfrontendを介してルーティングされた同時接続の合計数。
    • セッションがログに記録されたときに、このbackendにルーティングされた同時接続の合計数。
    • セッションがログに記録されたときに、このserverでまだアクティブな同時接続の合計数。
    • バックエンドサーバーに接続しようとしたときに試行された再試行の数。haproxyはすぐにすべてを記録するわけではありませんが、必要なものをキャプチャするために微調整することができます。 HTTPリクエストヘッダーは、http-request captureディレクティブを追加することでログに記録することができます。

      ログには、中括弧の間にヘッダーが表示され、パイプシンボルで区切って表示されます。 ここでは、要求のHostヘッダーとUser-Agentヘッダーを確認できます:

      応答ヘッダーは、http-response captureディレクティブを追加することでログに記録できます。

      この場合、declare capture responseディレクティブを追加する必要があります。 追加する各スロットには、ゼロから始まるIDが自動的に割り当てられます。 http-response captureを呼び出すときにこのIDを参照します。 応答ヘッダーは、リクエストヘッダーの後に、中括弧の別のセット内でログに記録されます。クッキーの値は、http-request captureディレクティブと同様の方法で記録できます。

      http-request captureでキャプチャされたものは、HTTPヘッダーとcookieを含め、同じ中括弧のセット内に表示されます。 同じことは、http-response capturehttp-request capturestick-tableで追跡していた場合、次のようにログに記録できます。

      だから、HTMLドキュメントと二つの画像を含むwebページに要求を行:

      使用されたSSL/TLSのバージョンを記録するなど、フェッチメソッドの値を記録することもできます（%sslvという名前の組み込みログ変数があります）。

      http-request set-varで設定された変数もログに記録することができます。ACL式はtrueまたはfalseのいずれかに評価されます。 それらを直接ログに記録することはできませんが、式が真であるかどうかに基づいて変数を設定できます。 たとえば、ユーザーが/apiを訪問した場合、req.is_apiという変数をIs APIの値に設定し、それをログに取り込むことができます。

      HAProxyプロファイリングの有効化

      HAProxy1.9のリリースでは、HAProxy内で要求の処理に費やされたCPU時間を記録できます。 profiling.tasksglobalセクションに追加します。

      プロファイリングメトリックを公開する新しいフェッチメソッドがあります。

      フェッチメソッド 説明/td>
      date_us 日付のマイクロ秒の部分。tr>
      cpu_calls ストリームまたは現在の要求が割り当てられてから処理されているタスクへの呼び出しの数。 これは、同じ接続上の新しい要求ごとにリセットされます。td>
      cpu_ns_avg ストリームまたは現在の要求を処理するタスクへの各呼び出しに費やされた平均ナノ秒数。
      cpu_ns_tot ストリームまたは現在の要求を処理するタスクへの各呼び出しに費やされたナノ秒の合計数。
      lat_ns_avg ストリームを処理するタスクが目覚めた瞬間から効果的に呼び出された瞬間までに費やされたナノ秒の平均数。
      lat_ns_tot ストリームを処理するタスクがウェイクアップされた瞬間から効果的に呼び出された瞬間までのナノ秒の合計数。

      これらを次のようにログメッセージに追加します。

      これは、どの要求が処理に最もコストがかかるかを測定するhaproxyログの解析

      あなたが学んだように、HAProxyには、接続と要求に関する膨大な量の洞察を提供する多くのフィールドがあります。 しかし、それらを直接読むと、情報過多につながる可能性があります。 多くの場合、外部ツールを使用して解析して集計する方が簡単です。 このセクションでは、これらのツールのいくつかと、HAProxyによって提供されるログ情報をどのように活用できるかを説明します。HALogは、haproxyに同梱されている小さくて強力なログ分析ツールです。 これは、ライブの問題に直面したときなど、手動のトラブルシューティングに役立つ運用サーバーに展開するように設計されています。 これは非常に高速で、毎秒1〜2GBでTCPおよびHTTPログを解析できます。 フラグの組み合わせを渡すことで、URLごとの要求やソースIPごとの要求など、ログから統計情報を抽出できます。 次に、応答時間、エラー率、および終了コードで並べ替えることができます。

      たとえば、ログからサーバーごとの統計情報を抽出する場合は、次のコマンドを使用できます:

      これは、ステータスコードごとにログ行を解析し、特定のサーバーが異常であるかどうかをすばやく検出する必要がある場合に便利です（例：5xx応答が多 または、サーバーがあまりにも多くの要求（4xx応答）を拒否している可能性があり、これはブルートフォース攻撃の兆候です。 また、トラブルシューティングに役立つavg_rt列を使用して、サーバーあたりの平均応答時間を取得することもできます。HALogを使用すると、次のコマンドを使用してURLごとの統計情報を取得できます:

      出力には、要求数、エラー数、合計計算時間、平均計算時間、成功した要求の合計計算時間、成功した要求の平均計算時間、送信された平均バイト数、および送信された合計バイト数が表示されます。 サーバーとURLの統計情報の解析に加えて、複数のフィルタを適用して、特定の応答時間、HTTPステータスコード、セッション終了コードなどのログを照合できます。Haproxyからメトリックを取得する唯一の方法は、HALogでログを解析することではありません。 HAProxy Statsページは、stats enablefrontendlistenlistenセクションは、ポート8404でListenする統計ページを開始します。

      統計ページは、HAProxyを流れるトラフィックに関する即時情報を取得するのに ただし、このデータは保存されず、単一のロードバランサーのデータのみが表示されます。

      HAProxy Enterprise Real-Time Dashboard

      HAProxy Enterpriseを使用している場合は、Real-Time Dashboardにアクセスできます。 統計ページにはHAProxyの単一インスタンスの統計が表示されますが、リアルタイムダッシュボードはロードバランサーのクラスター全体で情報を集約して表示し これにより、単一の画面からすべてのサーバーの正常性を簡単に観察できます。 データは30分まで見ることができます。

      ダッシュボードには、サービスの正常性、要求レート、負荷に関する情報が格納され、表示されます。 また、バックエンドの有効化、無効化、排水などの管理タスクの実行も容易になります。 一目で、どのサーバーが稼働しているのか、どのくらいの時間がかかるのかを確認できます。 Stick tableデータは、stick tableが追跡している内容に応じて、エラー率、要求率、およびユーザーに関するその他のリアルタイム情報を表示することもできます。 スティックテーブルデータも集計できます。

      haproxy enterprise real-time dashboard

      HAProxy Enterpriseのリアルタイムダッシュボード

      リアルタイムダッシュボードは、HAProxy Enterpriseで利用可能な多くのアドオンの一つです。

      結論

      このブログ記事では、インフラストラクチャ内の重要なコンポーネントであるロードバランサーを介して可観測性を得るためにHAProxyロ HAPROXYは、TCPモードとHTTPモードのいずれかで動作するときに詳細なSyslogメッセージを出力します。 これらは、rsyslogなどの多くのログツールに送信できます。HaproxyにはHALogコマンドラインユーティリティが付属しており、ユーザーが取得している応答の種類とサーバーの負荷に関する情報が必要な場合にログデータの解析 また、Haproxy StatsページまたはHAProxy Enterprise Real-Timeダッシュボードを使用して、サーバーの正常性を視覚的に確認することもできます。このようなコンテンツがいつ公開されるかを知りたいですか？

      このブログを購読するか、Twitterで私たちに従ってください。 また、Slackで会話に参加することもできます！ HAProxy Enterpriseは、Haproxyとリアルタイムダッシュボード、プレミアムサポートなどのエンタープライズクラスの機能を組み合わせたものです。 詳細を学ぶか、今日の無料トライアルにサインアップするために私達に連絡してくださ

コメントを残す

メールアドレスが公開されることはありません。