Einführung in die HAProxy-Protokollierung

Wenn es um die Operationalisierung Ihrer Protokolldaten geht, bietet HAProxy eine Fülle von Informationen. In diesem Blogbeitrag zeigen wir, wie Sie die HAProxy-Protokollierung einrichten, einen Syslog-Server als Ziel festlegen, die Protokollfelder verstehen und einige hilfreiche Tools zum Analysieren von Protokolldateien vorschlagen.

Tiefer Einblick in die HAProxy-Protokollierung

HAProxy befindet sich im kritischen Pfad Ihrer Infrastruktur. Ob als Edge-Load-Balancer, Sidecar oder Kubernetes-Ingress-Controller, das Abrufen aussagekräftiger Protokolle aus HAProxy ist ein Muss.

Die Protokollierung gibt Ihnen Einblicke in jede Verbindung und Anforderung. Es ermöglicht die für die Fehlerbehebung erforderliche Beobachtbarkeit und kann sogar verwendet werden, um Probleme frühzeitig zu erkennen. Dies ist eine der vielen Möglichkeiten, Informationen von HAProxy abzurufen. Andere Möglichkeiten sind das Abrufen von Metriken über die Statistikseite oder die Laufzeit-API, das Einrichten von E-Mail-Benachrichtigungen und die Verwendung der verschiedenen Open-Source-Integrationen zum Speichern von Protokoll- oder Statistikdaten im Laufe der Zeit. HAProxy liefert sehr detaillierte Protokolle mit Millisekundengenauigkeit und generiert eine Fülle von Informationen über den Datenverkehr, der in Ihre Infrastruktur fließt. Dazu gehören:

• Metriken zum Datenverkehr: Timing-Daten, Verbindungszähler, Datenverkehrsgröße usw.
• Informationen zu HAProxy-Entscheidungen: Inhaltsumschaltung, Filterung, Persistenz usw.
• Informationen zu Anforderungen und Antworten: Header, Statuscodes, Nutzlasten usw.
• Beendigungsstatus einer Sitzung und die Möglichkeit zu verfolgen, wo Fehler auftreten (Client-Seite, Server-Seite?)

In diesem Beitrag erfahren Sie, wie Sie die HAProxy-Protokollierung konfigurieren und die generierten Protokollnachrichten lesen. Wir listen dann einige Tools auf, die Sie bei der Operationalisierung Ihrer Protokolldaten hilfreich finden.

Syslog-Server

HAProxy kann eine Protokollnachricht zur Verarbeitung durch einen Syslog-Server ausgeben. Dies ist mit bekannten Syslog-Tools wie Rsyslog sowie dem neueren Systemd-Dienst Journald kompatibel. Sie können auch verschiedene Protokollweiterleitungen wie Logstash und Fluentd verwenden, um Syslog-Nachrichten von HAProxy zu empfangen und an einen zentralen Protokollaggregator zu senden.

Wenn Sie in einer Containerumgebung arbeiten, unterstützt HAProxy die Cloud-native Protokollierung, mit der Sie die Protokollnachrichten an stdout und stderr senden können. Fahren Sie in diesem Fall mit dem nächsten Abschnitt fort, in dem Sie sehen, wie.

Bevor Sie untersuchen, wie Sie die Protokollierung über die HAProxy-Konfigurationsdatei aktivieren, sollten Sie zunächst sicherstellen, dass ein Syslog-Server wie rsyslog für den Empfang der Protokolle konfiguriert ist. Unter Ubuntu würden Sie rsyslog mit dem apt-Paketmanager wie folgt installieren:

Sobald rsyslog installiert ist, bearbeiten Sie die Konfiguration, um die Aufnahme von HAProxy-Protokollnachrichten zu verarbeiten. Fügen Sie die folgenden Zeilen zu /etc/rsyslog hinzu.conf oder in eine neue Datei innerhalb des rsyslog.d Verzeichnis, wie /etc/rsyslog.d /haproxy.conf:

Starten Sie dann den rsyslog-Dienst neu. Im obigen Beispiel überwacht rsyslog die IP-Loopback-Adresse 127.0.0.1 auf dem Standard-UDP-Port 514. Diese spezielle Konfiguration schreibt in zwei Protokolldateien. Die ausgewählte Datei basiert auf dem Schweregrad, mit dem die Nachricht protokolliert wurde. Um dies zu verstehen, schauen Sie sich die letzten beiden Zeilen der Datei genauer an. Sie beginnen so:

Der Syslog-Standard schreibt vor, dass jeder protokollierten Nachricht ein Facility-Code und ein Schweregrad zugewiesen werden sollten. In Anbetracht der obigen Beispielkonfiguration von rsyslog können Sie davon ausgehen, dass wir HAProxy so konfigurieren, dass alle Protokollnachrichten mit einem Facility-Code von local0 gesendet werden.

Der Schweregrad wird nach dem Einrichtungscode angegeben, getrennt durch einen Punkt. Hier erfasst die erste Zeile Nachrichten aller Schweregrade und schreibt sie in eine Datei namens Haproxy-traffic.log. Die zweite Zeile erfasst nur Nachrichten auf Benachrichtigungsebene und höher und protokolliert sie in einer Datei namens haproxy-admin.log.

HAProxy ist fest codiert, um bestimmte Schweregrade beim Senden bestimmter Nachrichten zu verwenden. Beispielsweise werden Protokollnachrichten in Bezug auf Verbindungen und HTTP-Anforderungen mit dem Schweregrad info kategorisiert. Andere Ereignisse werden anhand einer der anderen, weniger ausführlichen Ebenen kategorisiert. Von den meisten bis zu den am wenigsten wichtigen sind die Schweregrade:

Schweregrad	HAProxy-Protokolle
emerg	Fehler wie das Ausführen von Dateideskriptoren des Betriebssystems.
alert	Einige seltene Fälle, in denen etwas Unerwartetes passiert ist, z. B. dass eine Antwort nicht zwischengespeichert werden kann.
crit	Nicht verwendet.
err	Fehler, z. B. dass eine Map-Datei nicht analysiert werden kann, die HAProxy-Konfigurationsdatei nicht analysiert werden kann und wenn eine Operation in einer Map-Tabelle fehlschlägt.
Warnung	Bestimmte wichtige, aber nicht kritische Fehler, wie z. B. Fehler beim Festlegen eines Anforderungsheaders oder Fehler beim Herstellen einer Verbindung zu einem DNS-Nameserver.
Hinweis	Ändert den Status eines Servers, z. B. wenn er HOCH oder RUNTER ist oder wenn ein Server deaktiviert ist. Andere Ereignisse beim Start, wie das Starten von Proxys und das Laden von Modulen, sind ebenfalls enthalten. Die Integritätsprüfungsprotokollierung verwendet, falls aktiviert, auch diese Ebene.
info	TCP-Verbindung und HTTP-Anfrage Details und Fehler.
debug	Sie können benutzerdefinierten Lua-Code schreiben, der Debug-Nachrichten protokolliert

Moderne Linux-Distributionen werden mit dem Service Manager systemd ausgeliefert, der Journald zum Sammeln und Speichern von Protokollen einführt. Der Journald-Dienst ist keine Syslog-Implementierung, aber Syslog-kompatibel, da er denselben / dev / log-Socket überwacht. Es sammelt die empfangenen Protokolle und ermöglicht dem Benutzer, sie nach Einrichtungscode und / oder Schweregrad mithilfe der entsprechenden Journalfelder (SYSLOG_FACILITY, PRIORITY) zu filtern.

HAProxy-Protokollierungskonfiguration

Das HAProxy-Konfigurationshandbuch erklärt, dass die Protokollierung in zwei Schritten aktiviert werden kann: Der erste besteht darin, einen Syslog-Server im Abschnitt global anzugeben, indem eine log -Direktive verwendet wird:

Die log HAProxy zum Senden von Protokollen an den Syslog-Server, der auf 127.0.0.1: 514 wartet. Nachrichten werden mit der Einrichtung local0 gesendet, die eine der benutzerdefinierten Standard-Syslog-Funktionen ist. Es ist auch die Einrichtung, die unsere rsyslog-Konfiguration erwartet. Sie können mehr als eine log-Anweisung hinzufügen, um die Ausgabe an mehrere Syslog-Server zu senden.

Sie können steuern, wie viele Informationen protokolliert werden, indem Sie am Ende der Zeile eine Syslog-Ebene hinzufügen:

Der zweite Schritt zur Konfiguration der Protokollierung besteht darin, die verschiedenen Proxys (frontendbackend und listen Abschnitte) zu aktualisieren, um Nachrichten an den Syslog-Server (s) im Abschnitt global konfiguriert. Dies geschieht durch Hinzufügen einer log global Direktive. Sie können es dem Abschnitt defaults hinzufügen, wie gezeigt:

Die Direktive log global besagt im Grunde, verwenden Sie die Zeile log, die im Abschnitt global festgelegt wurde. Das Einfügen einer log global -Direktive in den defaults -Abschnitt entspricht dem Einfügen in alle nachfolgenden Proxy-Abschnitte. Dadurch wird die Protokollierung aller Proxys aktiviert. Weitere Informationen zu den Abschnitten einer HAProxy-Konfigurationsdatei finden Sie in unserem Blogbeitrag Die vier wesentlichen Abschnitte einer HAProxy-Konfiguration.

Standardmäßig ist die Ausgabe von HAProxy minimal. Das Hinzufügen der Zeile option httplog zu Ihrem Abschnitt defaults ermöglicht eine ausführlichere HTTP-Protokollierung, die wir später ausführlicher erläutern werden.

Eine typische HAProxy-Konfiguration sieht folgendermaßen aus:

Die Verwendung globaler Protokollierungsregeln ist das häufigste HAProxy-Setup, aber Sie können sie stattdessen direkt in einen Abschnitt frontend einfügen. Es kann nützlich sein, einmalig eine andere Protokollierungskonfiguration zu verwenden. Beispielsweise möchten Sie möglicherweise auf einen anderen Syslog-Zielserver verweisen, eine andere Protokollierungsfunktion verwenden oder je nach Anwendungsfall der Backend-Anwendung unterschiedliche Schweregrade erfassen. Betrachten Sie das folgende Beispiel, in dem die frontend Abschnitte fe_site1 und fe_site2 unterschiedliche IP-Adressen und Schweregrade festlegen:

Wenn Sie sich bei einem lokalen Syslog-Dienst anmelden, kann das Schreiben in einen UNIX-Socket schneller sein als das Targeting der TCP-Loopback-Adresse. Im Allgemeinen ist auf Linux-Systemen ein UNIX-Socket, der auf Syslog-Nachrichten wartet, unter / dev /log verfügbar, da hier standardmäßig die Funktion syslog () der GNU C-Bibliothek Nachrichten sendet. Richten Sie den UNIX-Socket wie folgt aus:

Sie sollten jedoch bedenken, dass, wenn Sie einen UNIX—Socket für die Protokollierung verwenden und gleichzeitig HAProxy in einer Chroot—Umgebung ausführen – oder Sie HAProxy mithilfe der Chroot-Konfigurationsanweisung ein chroot -Verzeichnis für Sie erstellen lassen – der UNIX-Socket in diesem Chroot-Verzeichnis verfügbar gemacht werden muss. Dies kann auf zwei Arten erfolgen.

Erstens kann rsyslog beim Start einen neuen Listening-Socket innerhalb des Chroot-Dateisystems erstellen. Fügen Sie Ihrer HAProxy rsyslog-Konfigurationsdatei Folgendes hinzu:

Die zweite Möglichkeit besteht darin, den Socket manuell zum Chroot-Dateisystem hinzuzufügen, indem Sie den Befehl mount mit der Option --bind verwenden.

Stellen Sie sicher, dass Sie Ihrer /etc/fstab-Datei oder einer Systemd-Unit-Datei einen Eintrag hinzufügen, damit die Einhängung nach einem Neustart erhalten bleibt. Sobald Sie die Protokollierung konfiguriert haben, möchten Sie verstehen, wie die Nachrichten strukturiert sind. Im nächsten Abschnitt sehen Sie die Felder, aus denen die Protokolle auf TCP- und HTTP-Ebene bestehen.

Wenn Sie die Menge der gespeicherten Daten begrenzen müssen, besteht eine Möglichkeit darin, nur einen Teil der Protokollnachrichten abzufragen. Stellen Sie die Protokollebene für eine zufällige Anzahl von Anforderungen wie folgt auf stumm:

Beachten Sie, dass es nach Möglichkeit besser ist, so viele Daten wie möglich zu erfassen. Auf diese Weise haben Sie keine fehlenden Informationen, wenn Sie sie am dringendsten benötigen. Sie können den ACL-Ausdruck auch so ändern, dass bestimmte Bedingungen die Regel überschreiben.

Eine andere Möglichkeit, die Anzahl der protokollierten Nachrichten zu begrenzen, besteht darin, option dontlog-normal in Ihrem defaults oder frontend . Auf diese Weise werden nur Timeouts, Wiederholungsversuche und Fehler erfasst. Sie möchten dies wahrscheinlich nicht ständig aktivieren, sondern nur zu bestimmten Zeiten, z. B. beim Durchführen von Benchmarking-Tests.

Wenn Sie HAProxy in einem Docker-Container ausführen und HAProxy Version 1.9 verwenden, können Sie die Protokollausgabe nicht an einen Syslog-Server senden, sondern an stdout und/oder stderr . Setzen Sie die Adresse auf stdout bzw. stderr. In diesem Fall ist es auch vorzuziehen, das Format der Nachricht wie folgt auf raw zu setzen:

HAProxy-Protokollformat

Die Art der Protokollierung, die Sie sehen, wird durch den Proxy-Modus bestimmt, den Sie in HAProxy festgelegt haben. HAProxy kann entweder als Layer 4 (TCP) -Proxy oder als Layer 7 (HTTP) -Proxy betrieben werden. Der TCP-Modus ist die Standardeinstellung. In diesem Modus wird eine Vollduplexverbindung zwischen Clients und Servern hergestellt, und es wird keine Layer-7-Prüfung durchgeführt. Wenn Sie Ihre rsyslog-Konfiguration basierend auf unserer Diskussion im ersten Abschnitt festgelegt haben, finden Sie die Protokolldatei unter /var/log/ haproxy-traffic .log.

Im TCP-Modus, der durch Hinzufügen von mode tcp festgelegt wird, sollten Sie auch die Option tcplog hinzufügen. Mit dieser Option verwendet das Protokollformat standardmäßig eine Struktur, die nützliche Informationen wie Layer-4-Verbindungsdetails, Timer, Byteanzahl usw. enthält. Wenn Sie dieses Format mit log-format , das zum Festlegen eines benutzerdefinierten Formats verwendet wird, neu erstellen würden, würde es folgendermaßen aussehen:

Beschreibungen dieser Felder finden Sie in der Dokumentation zum TCP-Protokollformat, obwohl wir im kommenden Abschnitt mehrere beschreiben werden.

Wenn HAProxy als Layer-7-Proxy über mode http ausgeführt wird, sollten Sie die Option httplog Direktive hinzufügen. Es stellt sicher, dass HTTP-Anfragen und -Antworten eingehend analysiert werden und dass kein RFC-konformer Inhalt nicht erfasst wird. Dies ist der Modus, der den diagnostischen Wert von HAProxy wirklich hervorhebt. Das HTTP-Protokollformat bietet dieselbe Informationsebene wie das TCP-Format, jedoch mit zusätzlichen Daten, die für das HTTP-Protokoll spezifisch sind. Wenn Sie dieses Format mit log-format neu erstellen würden, würde es folgendermaßen aussehen:

Detaillierte Beschreibungen der verschiedenen Felder finden Sie in der Dokumentation zum HTTP-Protokollformat.

können Sie auch ein benutzerdefiniertes Protokollformat definieren, das nur das erfasst, was Sie benötigen. Verwenden Sie die log-format (oder log-format-sd für strukturierte Daten syslog) Direktive in Ihrem defaults oder frontend. Lesen Sie unseren Blogbeitrag HAProxy Log Customization, um mehr zu erfahren und einige Beispiele zu sehen.

In den nächsten Abschnitten werden Sie mit den Feldern vertraut gemacht, die enthalten sind, wenn Sie option tcplog oder option httplog .

Proxies

In der erzeugten Protokolldatei beginnt jede Zeile mit dem Frontend, Backend und Server, an den die Anforderung gesendet wurde. Wenn Sie beispielsweise die folgende HAProxy-Konfiguration hätten, würden Zeilen angezeigt, in denen beschrieben wird, dass Anforderungen über das http-In-Frontend an das statische Backend und dann an den srv1-Server weitergeleitet werden.

Dies wird zu wichtigen Informationen, wenn Sie wissen müssen, wohin eine Anforderung gesendet wurde, z. B. wenn Fehler angezeigt werden, die nur einige Ihrer Server betreffen.

Timer

Timer werden in Millisekunden bereitgestellt und decken die Ereignisse ab, die während einer Sitzung auftreten. Die vom Standard-TCP-Protokollformat erfassten Timer sind Tw / Tc / Tt. Die vom Standard-HTTP-Protokollformat bereitgestellten sind TR / Tw/ Tc / Tr / Ta. Diese übersetzen als:

Timer	Bedeutung
TR	Die Gesamtzeit, um die Client-Anfrage zu erhalten (nur HTTP-Modus).
Tw	Die Gesamtzeit, die in den Warteschlangen auf einen Verbindungsschlitz gewartet wird.
Tc	Die Gesamtzeit für den Aufbau der TCP-Verbindung zum Server.
Tr	Die Antwortzeit des Servers (nur HTTP-Modus).
Ta	Die gesamte aktive Zeit für die HTTP-Anforderung (nur HTTP-Modus).
Tt	Die gesamte TCP-Sitzungsdauer zwischen dem Moment, in dem der Proxy sie akzeptiert hat, und dem Moment, in dem beide Enden geschlossen wurden.

Eine detaillierte Beschreibung aller verfügbaren Timer finden Sie in der HAProxy-Dokumentation. Das folgende Diagramm zeigt auch, wo die Zeit während einer einzelnen End-to-End-Transaktion aufgezeichnet wird. Beachten Sie, dass die violetten Linien an den Rändern Timer bezeichnen.

Sitzungsstatus beim Trennen

Sowohl TCP- als auch HTTP-Protokolle enthalten einen Beendigungsstatuscode, der angibt, wie die TCP- oder HTTP-Sitzung beendet wurde. Es ist ein zweistelliger Code. Das erste Zeichen meldet das erste Ereignis, das zum Beenden der Sitzung geführt hat, während das zweite den TCP- oder HTTP-Sitzungsstatus beim Schließen meldet.

Hier sind einige Terminierungscodebeispiele:

Zweistelliger Code	Bedeutung
–	Normaler Abschluss auf beiden Seiten.
cD	Der Client hat keine Daten gesendet oder bestätigt und schließlich timeout client abgelaufen.
SC	Der Server hat die TCP-Verbindung explizit abgelehnt.
PC	Der Proxy weigerte sich, eine Verbindung zum Server herzustellen, da das Socket-Limit des Prozesses beim Verbindungsversuch erreicht wurde.

Es gibt eine Vielzahl von Gründen, warum eine Verbindung geschlossen wurde. Detaillierte Informationen zu allen möglichen Terminierungscodes finden Sie in der HAProxy-Dokumentation.

Zähler

Zähler zeigen den Zustand des Systems an, wenn eine Anforderung durchlaufen wurde. HAProxy zeichnet fünf Zähler für jede Verbindung oder Anforderung auf. Sie können von unschätzbarem Wert sein, um zu bestimmen, wie viel Last auf das System gelegt wird, wo das System nacheilt und ob Grenzwerte erreicht wurden. Wenn Sie sich eine Zeile im Protokoll ansehen, werden die Zähler als fünf durch Schrägstriche getrennte Zahlen aufgeführt: 0/0/0/0/0.

Im TCP- oder HTTP-Modus werden diese wie folgt aufgeteilt:

• Die Gesamtzahl der gleichzeitigen Verbindungen im HAProxy-Prozess, als die Sitzung protokolliert wurde.
• Die Gesamtzahl der gleichzeitigen Verbindungen, die über diese frontend geleitet wurden, als die Sitzung protokolliert wurde.
• Die Gesamtzahl der gleichzeitigen Verbindungen, die zu diesem backend geroutet wurden, als die Sitzung protokolliert wurde.
• Die Gesamtzahl der gleichzeitigen Verbindungen, die auf dieser server noch aktiv waren, als die Sitzung protokolliert wurde.
• Die Anzahl der Versuche, eine Verbindung zum Backend-Server herzustellen.

Andere Felder

HAProxy zeichnet nicht alles sofort auf, aber Sie können es optimieren, um das zu erfassen, was Sie benötigen. Ein HTTP-Anforderungsheader kann durch Hinzufügen der Direktive http-request capture protokolliert werden:

Das Protokoll zeigt Header in geschweiften Klammern und getrennt durch Pipe-Symbole. Hier sehen Sie die Host- und User-Agent-Header für eine Anfrage:

Ein Antwortheader kann durch Hinzufügen einer http-response capture -Direktive protokolliert werden:

In diesem Fall müssen Sie auch eine declare capture response -Direktive hinzufügen, die einen Capture-Slot zuweist, in dem der Antwortheader, sobald er eintrifft, gespeichert werden kann. Jedem Slot, den Sie hinzufügen, wird automatisch eine ID zugewiesen, die bei Null beginnt. Verweisen Sie auf diese ID, wenn Sie http-response capture aufrufen. Antwortheader werden nach den Anforderungsheadern in einem separaten Satz geschweifter Klammern protokolliert.

Cookie-Werte können auf ähnliche Weise mit der Direktive http-request capture protokolliert werden.

Alles, was mit http-request capture erfasst wird, einschließlich HTTP-Header und Cookies, wird in denselben geschweiften Klammern angezeigt. Das gleiche gilt für alles, was mit http-response capture .

Sie können auch http-request capture verwenden, um abgetastete Daten aus Stick-Tabellen zu protokollieren. Wenn Sie die Benutzeranforderungsraten mit einer stick-table , können Sie sie folgendermaßen protokollieren:

Wenn Sie also eine Anfrage an eine Webseite stellen, die das HTML-Dokument und zwei Bilder enthält, wird die gleichzeitige Anforderungsrate des Benutzers auf drei erhöht:

Sie können auch die Werte von Abrufmethoden protokollieren, z. B. um die verwendete Version von SSL/TLS aufzuzeichnen (beachten Sie, dass es eine integrierte Protokollvariable namens %sslv gibt):

Variablen, die mit http-request set-var können ebenfalls protokolliert werden.

ACL-Ausdrücke werden entweder als true oder false ausgewertet. Sie können sie nicht direkt protokollieren, aber Sie können eine Variable basierend darauf festlegen, ob der Ausdruck wahr ist. Wenn der Benutzer beispielsweise /api besucht, können Sie eine Variable namens req.is_api auf den Wert Is API und diese dann in den Protokollen erfassen.

Aktivieren der HAProxy-Profilerstellung

Mit der Veröffentlichung von HAProxy 1.9 können Sie die CPU-Zeit aufzeichnen, die für die Verarbeitung einer Anforderung in HAProxy aufgewendet wurde. Fügen Sie die Direktive profiling.tasks zu Ihrem Abschnitt global hinzu:

Es gibt neue Abrufmethoden, die die Profilierungsmetriken verfügbar machen:

Abrufmethode	Beschreibung
date_us	Der Mikrosekunden-Teil des Datums.
cpu_calls	Die Anzahl der Aufrufe der Task, die den Stream oder die aktuelle Anforderung verarbeitet, seit er zugewiesen wurde. Es wird für jede neue Anforderung auf derselben Verbindung zurückgesetzt.
cpu_ns_avg	Die durchschnittliche Anzahl der Nanosekunden, die bei jedem Aufruf der Aufgabe ausgegeben werden, die den Stream oder die aktuelle Anforderung verarbeitet.
cpu_ns_tot	Die Gesamtzahl der Nanosekunden, die bei jedem Aufruf der Aufgabe ausgegeben werden, die den Stream oder die aktuelle Anforderung verarbeitet.
lat_ns_avg	Die durchschnittliche Anzahl von Nanosekunden, die zwischen dem Moment, in dem die Aufgabe, die den Stream behandelt, geweckt wird, und dem Moment, in dem sie effektiv aufgerufen wird, verbracht wurde.
lat_ns_tot	Die Gesamtzahl der Nanosekunden zwischen dem Moment, in dem die Aufgabe, die den Stream behandelt, geweckt wird, und dem Moment, in dem sie effektiv aufgerufen wird.

Fügen Sie diese zu Ihren Protokollmeldungen wie folgt hinzu:

Dies ist eine großartige Möglichkeit zu messen, welche Anfragen am meisten zu verarbeiten sind.

Analysieren von HAProxy-Protokollen

Wie Sie gelernt haben, verfügt HAProxy über viele Felder, die einen enormen Einblick in Verbindungen und Anforderungen bieten. Das direkte Lesen kann jedoch zu einer Informationsüberflutung führen. Oft ist es einfacher, sie mit externen Tools zu analysieren und zu aggregieren. In diesem Abschnitt sehen Sie einige dieser Tools und wie sie die von HAProxy bereitgestellten Protokollierungsinformationen nutzen können.

HALog

HALog ist ein kleines, aber leistungsstarkes Log-Analyse-Tool, das mit HAProxy ausgeliefert wird. Es wurde entwickelt, um auf Produktionsservern bereitgestellt zu werden, wo es bei der manuellen Fehlerbehebung helfen kann, z. B. bei Live-Problemen. Es ist extrem schnell und kann TCP- und HTTP-Protokolle mit 1 bis 2 GB pro Sekunde analysieren. Indem Sie eine Kombination von Flags übergeben, können Sie statistische Informationen aus den Protokollen extrahieren, einschließlich Anforderungen pro URL und Anforderungen pro Quell-IP. Anschließend können Sie nach Antwortzeit, Fehlerrate und Beendigungscode sortieren.

Wenn Sie beispielsweise Serverstatistiken aus den Protokollen extrahieren möchten, können Sie den folgenden Befehl verwenden:

Dies ist nützlich, wenn Sie Protokollzeilen pro Statuscode analysieren und schnell feststellen müssen, ob ein bestimmter Server fehlerhaft ist (z. B. zu viele 5xx-Antworten zurückgeben). Oder ein Server verweigert möglicherweise zu viele Anforderungen (4xx-Antworten), was ein Zeichen für einen Brute-Force-Angriff ist. Sie können die durchschnittliche Antwortzeit pro Server auch mit der Spalte avg_rt abrufen, die für die Fehlerbehebung hilfreich ist.

Mit HALog können Sie Statistiken pro URL abrufen, indem Sie den folgenden Befehl verwenden:

Die Ausgabe zeigt die Anzahl der Anforderungen, die Anzahl der Fehler, die Gesamtberechnungszeit, die durchschnittliche Berechnungszeit, die Gesamtberechnungszeit erfolgreicher Anforderungen, die durchschnittliche Berechnungszeit erfolgreicher Anforderungen, die durchschnittliche Anzahl der gesendeten Bytes und die Gesamtzahl der gesendeten Bytes. Zusätzlich zum Parsen von Server- und URL-Statistiken können Sie mehrere Filter anwenden, um Protokolle mit einer bestimmten Antwortzeit, einem HTTP-Statuscode, einem Sitzungsbeendigungscode usw. abzugleichen.

HAProxy Stats Page

Das Parsen der Protokolle mit HALog ist nicht die einzige Möglichkeit, Metriken aus HAProxy herauszuholen. Die HAProxy-Statistikseite kann durch Hinzufügen der Direktive stats enable zu einem Abschnitt frontend oder listen aktiviert werden. Es zeigt Live-Statistiken Ihrer Server an. Der Abschnitt follow listen startet die Statistikseite, die Port 8404 abhört:

Die Statistikseite ist sehr nützlich, um sofortige Informationen über den durch HAProxy fließenden Datenverkehr zu erhalten. Es speichert diese Daten jedoch nicht und zeigt Daten nur für einen einzelnen Load Balancer an.

HAProxy Enterprise Echtzeit-Dashboard

Wenn Sie HAProxy Enterprise verwenden, haben Sie Zugriff auf das Echtzeit-Dashboard. Während die Statistikseite Statistiken für eine einzelne Instanz von HAProxy anzeigt, aggregiert und zeigt das Echtzeit-Dashboard Informationen über einen Cluster von Load Balancern an. Dies macht es einfach, den Zustand aller Ihrer Server von einem einzigen Bildschirm aus zu beobachten. Die Daten können bis zu 30 Minuten lang angezeigt werden.

Das Dashboard speichert und zeigt Informationen über den Zustand des Dienstes, die Anforderungsraten und die Auslastung an. Es erleichtert auch die Ausführung administrativer Aufgaben wie das Aktivieren, Deaktivieren und Entleeren von Backends. Auf einen Blick sehen Sie, welche Server wie lange aktiv sind. Sie können auch Stick-Tabellendaten anzeigen, die Ihnen je nachdem, was die Stick-Tabelle verfolgt, möglicherweise Fehlerraten, Anforderungsraten und andere Echtzeitinformationen zu Ihren Benutzern anzeigen. Die Tabellendaten können auch aggregiert werden.

Das Echtzeit-Dashboard ist eines von vielen Add-Ons, die mit HAProxy Enterprise verfügbar sind.

Fazit

In diesem Blogbeitrag haben Sie gelernt, wie Sie die HAProxy-Protokollierung konfigurieren, um Beobachtbarkeit über Ihren Load Balancer zu erhalten, der eine kritische Komponente in Ihrer Infrastruktur darstellt. HAProxy gibt detaillierte Syslog-Nachrichten aus, wenn es im TCP- und HTTP-Modus arbeitet. Diese können an eine Reihe von Protokollierungstools wie rsyslog gesendet werden.

HAProxy wird mit dem Befehlszeilendienstprogramm HALog ausgeliefert, das das Parsen von Protokolldaten vereinfacht, wenn Sie Informationen über die Arten von Antworten benötigen, die Benutzer erhalten, und über die Auslastung Ihrer Server. Sie können sich auch einen Überblick über den Zustand Ihrer Server verschaffen, indem Sie die HAProxy-Statsseite oder das HAProxy Enterprise-Echtzeit-Dashboard verwenden.

Möchten Sie wissen, wann solche Inhalte veröffentlicht werden? Abonnieren Sie diesen Blog oder folgen Sie uns auf Twitter. Sie können auch an der Konversation auf Slack teilnehmen! HAProxy Enterprise kombiniert HAProxy mit Funktionen der Enterprise-Klasse wie dem Echtzeit-Dashboard und Premium-Support. Kontaktieren Sie uns, um mehr zu erfahren, oder melden Sie sich noch heute für eine kostenlose Testversion an!