Inleiding tot HAProxy Logging

wanneer het aankomt op het operationaliseren van uw loggegevens, biedt HAProxy een schat aan informatie. In deze blogpost laten we zien hoe we HAProxy logging kunnen instellen, een Syslog-server kunnen targeten, de logvelden kunnen begrijpen en een aantal handige tools kunnen voorstellen voor het ontleden van logbestanden.

diep duiken in HAProxy Logging

HAProxy bevindt zich in het kritieke pad van uw infrastructuur. Of gebruikt als een rand load balancer, een zijspan, of als een Kubernetes ingress controller, het krijgen van zinvolle logs uit HAProxy is een must-have.

Logging geeft u inzicht over elke verbinding en aanvraag. Het maakt observability nodig voor het oplossen van problemen en kan zelfs worden gebruikt om problemen vroegtijdig te detecteren. Het is een van de vele manieren om informatie te krijgen van HAProxy. Andere manieren zijn onder meer het verkrijgen van statistieken met behulp van de statistieken pagina of runtime API, het opzetten van e-mail alerts, en gebruik te maken van de verschillende open-source integraties voor het opslaan van log-of statistische gegevens in de tijd. HAProxy biedt zeer gedetailleerde logboeken met milliseconde nauwkeurigheid en genereert een schat aan informatie over het verkeer dat in uw infrastructuur stroomt. Dit omvat:

• Metrics over het verkeer: timing gegevens, verbindingen tellers, verkeer grootte, enz.
• informatie over HAProxy-beslissingen: content switching, filtering, persistentie, enz.
• informatie over verzoeken en Antwoorden: headers, statuscodes, payloads, enz.
• Beëindigingsstatus van een sessie en de mogelijkheid om bij te houden waar er fouten optreden (client -, server-zijde?)

In dit bericht leert u hoe u HAProxy logging configureert en hoe u de logberichten leest die het genereert. We zullen dan een lijst van een aantal tools die u nuttig zult vinden bij het operationaliseren van uw loggegevens.

Syslog Server

HAProxy kan Logbericht versturen voor verwerking door een syslog server. Dit is compatibel met bekende syslog tools zoals Rsyslog, evenals de nieuwere systemd service journald. U kunt ook gebruik maken van verschillende log forwarders zoals Logstash en Fluentd te ontvangen Syslog berichten van HAProxy en stuur ze naar een centrale log aggregator.

Als u in een container-omgeving werkt, ondersteunt HAProxy logging in de cloud, waarmee u de logberichten naar stdout en stderr kunt verzenden. In dat geval, ga naar de volgende sectie waar u zult zien hoe.

voordat u nagaat hoe u logging kunt inschakelen via het HAProxy configuratiebestand, moet u eerst controleren of u een Syslog-server, zoals rsyslog, hebt geconfigureerd om de logs te ontvangen. Op Ubuntu zou je rsyslog installeren met behulp van de apt package manager, zoals zo:

zodra rsyslog is geïnstalleerd, bewerk je de configuratie om HAProxy logberichten te verwerken. Voeg het volgende toe aan /etc / rsyslog.conf of naar een nieuw bestand binnen de rsyslog.d directory, zoals /etc / rsyslog.d / haproxy.conf:

start vervolgens de rsyslog-service opnieuw op. In het voorbeeld hierboven luistert rsyslog op het IP loopback adres, 127.0.0.1, op de standaard UDP poort 514. Deze specifieke configuratie schrijft naar twee logbestanden. Het gekozen bestand is gebaseerd op de ernst waarmee het bericht is gelogd. Om dit te begrijpen, neem een kijkje op de laatste twee regels in het bestand. Ze beginnen zo.:

de Syslog-standaard schrijft voor dat aan elk gelogd bericht een faciliteitcode en een ernstniveau moet worden toegewezen. Gegeven het voorbeeld rsyslog configuratie hierboven, kun je ervan uitgaan dat we HAProxy zullen configureren om al zijn log berichten te verzenden met een facility code van local0.

het ernstniveau wordt gespecificeerd na de faciliteitscode, gescheiden door een punt. Hier, de eerste regel vangt berichten op alle niveaus van ernst en schrijft ze naar een bestand genaamd haproxy-traffic.log. De tweede regel vangt alleen bericht-niveau berichten en hoger, loggen ze naar een bestand genaamd haproxy-admin.log.

HAProxy is hardcoded om bepaalde ernstniveaus te gebruiken bij het verzenden van bepaalde berichten. Het categoriseert bijvoorbeeld logberichten met betrekking tot verbindingen en HTTP-verzoeken met het infozwaarheidsniveau. Andere gebeurtenissen worden gecategoriseerd met behulp van een van de andere, minder uitgebreide niveaus. Van het meest naar het minst belangrijke zijn de ernstniveaus:

ernstniveau	HAProxy Logs
emerg	fouten zoals het opraken van bestandsbeschrijvingen van besturingssystemen.
alert	enkele zeldzame gevallen waarin iets onverwachts is gebeurd, zoals het niet in staat zijn om een antwoord in de cache te plaatsen.
crit	niet gebruikt.
err	fouten zoals het niet kunnen ontleden van een kaartbestand, het HAProxy configuratiebestand niet kunnen ontleden, en wanneer een bewerking op een stoktabel mislukt.
waarschuwing	bepaalde belangrijke, maar niet-kritische fouten, zoals het niet instellen van een request header of het niet verbinden met een DNS nameserver.
notice	wijzigingen in de status van een server, zoals omhoog of omlaag of wanneer een server is uitgeschakeld. Andere gebeurtenissen bij het opstarten, zoals het starten van proxies en het laden van modules zijn ook opgenomen. Bij statuscontrole-logboekregistratie, indien ingeschakeld, wordt ook dit niveau gebruikt.
info	TCP-verbinding en HTTP-verzoek details en fouten.
debug	u kunt aangepaste Lua-code schrijven die debugberichten registreert

moderne Linux-distributies worden geleverd met de service manager systemd, die journald introduceert voor het verzamelen en opslaan van logs. De journald service is geen Syslog implementatie, maar het is Syslog compatibel omdat het zal luisteren op dezelfde / dev / log socket. Het zal de ontvangen logs verzamelen en de gebruiker toestaan om ze te filteren op facility code en / of ernst niveau met behulp van de equivalente journald velden (SYSLOG_FACILITY, PRIORITY).

HAProxy Logging configuratie

De HAProxy configuratie handleiding legt uit dat loggen kan worden ingeschakeld met twee stappen: de eerste is om een Syslog server op te geven in de global sectie met behulp van een log directive:

The log directive instructs haproxy om logs te sturen naar de Syslog server die luistert op 127.0.0.1:514. Berichten worden verzonden met facility local0, een van de standaard, door de gebruiker gedefinieerde Syslog faciliteiten. Het is ook de faciliteit die onze rsyslog configuratie verwacht. U kunt meer dan één log statement toevoegen om uitvoer naar meerdere Syslog-servers te verzenden.

u kunt bepalen hoeveel informatie wordt gelogd door een Syslog-niveau toe te voegen aan het einde van de regel:

de tweede stap naar het configureren van logboekregistratie is het bijwerken van de verschillende proxies (frontendbackend, en listen secties) om berichten naar de Syslog-server te sturen(s) geconfigureerd in de global sectie. Dit wordt gedaan door een log global richtlijn toe te voegen. U kunt het toevoegen aan de defaults sectie, zoals getoond:

de log global directive zegt in principe, gebruik de log regel die was ingesteld in de global sectie. Het plaatsen van een log global richtlijn in de defaults sectie is gelijk aan het plaatsen in alle volgende proxy secties. Zo, dit zal het inloggen op alle proxies mogelijk te maken. U kunt meer lezen over de secties van een HAProxy configuratie bestand in onze blog post De vier essentiële secties van een HAProxy configuratie.

standaard is de uitvoer van HAProxy minimaal. Het toevoegen van de regel option httplog aan uw defaults sectie zal meer uitgebreide HTTP logging mogelijk maken, die we later in meer detail zullen uitleggen.

een typische HAProxy configuratie ziet er als volgt uit:

het gebruik van globale logregels is de meest voorkomende HAProxy setup, maar u kunt ze direct in een frontend sectie plaatsen. Het kan handig zijn om een andere logging configuratie als een eenmalige. U kunt bijvoorbeeld naar een andere doelsyslog-server verwijzen, een andere logfunctie gebruiken of verschillende ernstniveaus vastleggen, afhankelijk van het gebruik van de backend-toepassing. Neem het volgende voorbeeld waarin defrontend secties, fe_site1 en fe_site2, verschillende IP-adressen en ernstniveaus instellen:

bij het loggen op een lokale Syslog-service kan het schrijven naar een UNIX-socket sneller zijn dan het TCP loopback-adres targeten. Over het algemeen is op Linux systemen een UNIX socket die luistert naar Syslog berichten beschikbaar in /dev/log omdat hier de syslog() functie van de GNU C bibliotheek standaard berichten verzendt. Richt de UNIX socket als volgt:

Houd er echter rekening mee dat als je een UNIX socket gaat gebruiken voor loggen en tegelijkertijd HAProxy draait binnen een gechrooteerde omgeving—of als je HAProxy een chroot map voor je laat maken met behulp van de chroot configuratie richtlijn—dan moet de UNIX socket beschikbaar worden gemaakt binnen die chroot map. Dit kan op twee manieren.

ten eerste, wanneer rsyslog opstart, kan het een nieuwe luistersocket aanmaken binnen het chroot bestandssysteem. Voeg het volgende toe aan uw HAProxy rsyslog configuratiebestand:

de tweede manier is om de socket handmatig toe te voegen aan het chroot bestandssysteem met behulp van de mount commando met de --bind optie.

voeg een regel toe aan je /etc/fstab bestand of aan een systemd unit bestand zodat de mount blijft bestaan na een herstart. Zodra u logging geconfigureerd, zult u willen begrijpen hoe de berichten zijn gestructureerd. In de volgende sectie, zie je de velden die deel uitmaken van de TCP en HTTP-niveau logs.

als u de hoeveelheid opgeslagen gegevens wilt beperken, kunt u een voorbeeld nemen van slechts een deel van de logberichten. Stel het logniveau in op stil voor een willekeurig aantal verzoeken, zoals:

merk op dat, indien mogelijk, het beter is om zoveel mogelijk gegevens vast te leggen als je kunt. Op die manier heb je geen ontbrekende informatie wanneer je het het meest nodig hebt. U kunt ook de ACL-expressie wijzigen zodat bepaalde voorwaarden de regel overschrijven.

een andere manier om het aantal gelogde berichten te beperken is door option dontlog-normal in uw defaults of frontendin te stellen. Op die manier worden alleen time-outs, pogingen en fouten vastgelegd. U zou dit waarschijnlijk niet de hele tijd willen inschakelen, maar alleen tijdens bepaalde tijden, zoals bij het uitvoeren van benchmarking-tests.

als je HAProxy draait in een Docker container en je gebruikt HAProxy versie 1.9, dan kun je in plaats van log uitvoer naar een Syslog server sturen naar stdout en / of stderr. Stel het adres in op stdout of stderr. In dat geval is het ook beter om het formaat van het bericht in te stellen op raw, zoals zo:

HAProxy Log Format

het type logging dat u zult zien wordt bepaald door de proxy mode die u in HAProxy hebt ingesteld. HAProxy kan werken als een Layer 4 (TCP) proxy of als Layer 7 (HTTP) proxy. TCP-modus is de standaard. In deze modus wordt een full-duplex verbinding tot stand gebracht tussen clients en servers, en er wordt geen layer 7 onderzoek uitgevoerd. Als je je rsyslog configuratie hebt ingesteld op basis van onze discussie in de eerste sectie, vind je het log bestand in /var/log/haproxy-traffic.log.

In TCP-modus, die wordt ingesteld door mode tcp toe te voegen, moet u ook optie tcplog toevoegen. Met deze optie wordt het log formaat standaard ingesteld op een structuur die nuttige informatie biedt zoals layer 4 verbindingsdetails, timers, byte aantal, enz. Als u dit formaat opnieuw zou maken met log-format, die wordt gebruikt om een aangepast formaat in te stellen, zou het er zo uitzien:

beschrijvingen van deze velden kunnen gevonden worden in de TCP log format documentatie, hoewel we er een aantal zullen beschrijven in de volgende sectie.

wanneer HAProxy wordt uitgevoerd als een layer 7 proxy via mode http, moet u de optie httplog directive toevoegen. Het zorgt ervoor dat HTTP-aanvragen en-Antwoorden grondig worden geanalyseerd en dat geen RFC-compatibele inhoud niet wordt opgenomen. Dit is de wijze die werkelijk de kenmerkende waarde van HAProxy benadrukt. Het HTTP-logformaat biedt hetzelfde niveau van informatie als het TCP-formaat, maar met extra gegevens die specifiek zijn voor het HTTP-protocol. Als u dit formaat opnieuw zou maken met log-format, zou het er zo uitzien:

gedetailleerde beschrijvingen van de verschillende velden zijn te vinden in de HTTP log format documentatie.

u kunt ook een aangepast log format definiëren, waarbij alleen wordt vastgelegd wat u nodig hebt. Gebruik delog-format (oflog-format-sd voor structured-data syslog) richtlijn in uwdefaults offrontend. Lees onze blogpost HAProxy Log Customization voor meer informatie en zie enkele voorbeelden.

in de volgende secties zult u vertrouwd raken met de velden die zijn opgenomen wanneer u option tcplog of option httploggebruikt.

Proxies

binnen het logbestand dat wordt geproduceerd, begint elke regel met de frontend, backend en server waarnaar het verzoek is verzonden. Bijvoorbeeld, als je de volgende HAProxy configuratie had, zou je regels zien die Verzoeken beschrijven als gerouteerd via de http-in frontend naar de statische backend en vervolgens naar de srv1 server.

Dit wordt belangrijke informatie wanneer u wilt weten waar een verzoek is verzonden, zoals wanneer u fouten ziet die slechts enkele van uw servers beïnvloeden.

Timers

Timers worden geleverd in milliseconden en bestrijken de gebeurtenissen die tijdens een sessie plaatsvinden. De timers vastgelegd door de standaard TCP log formaat zijn Tw / Tc / Tt. De standaard HTTP log format is TR / Tw/ Tc / tr / Ta. Deze worden vertaald als:

Timer	wat betekent
	TR	de totale tijd om het verzoek van de cliënt te ontvangen (alleen in HTTP-modus).
Tw	de totale tijd die wordt doorgebracht in de wachtrijen die wachten op een verbindingssleuf.
Tc	de totale tijd om de TCP-verbinding met de server tot stand te brengen.
Tr	de responstijd van de server (alleen in HTTP-modus).
Ta	de totale actieve tijd voor het HTTP-verzoek (alleen HTTP-modus).
Tt	de totale duur van de TCP-sessie, tussen het moment dat de proxy het accepteerde en het moment dat beide uiteinden werden gesloten.

u vindt een gedetailleerde beschrijving van alle beschikbare timers in de HAProxy documentatie. Het volgende diagram laat ook zien waar de tijd wordt geregistreerd tijdens een enkele end-to-end transactie. Merk op dat de paarse lijnen op de randen duiden timers.

Sessietoestand bij het verbreken van de verbinding

zowel TCP-als HTTP-logs bevatten een afsluitstatuscode die u vertelt hoe de TCP-of HTTP-sessie eindigde. Het is een code van twee tekens. Het eerste teken rapporteert de eerste gebeurtenis waardoor de sessie werd beëindigd, terwijl het tweede de TCP-of HTTP-sessiestatus rapporteert wanneer deze werd gesloten.

Hier zijn enkele voorbeelden van termination code:

twee-tekencode	Betekenis
—	normale beëindiging aan beide zijden.
cD	de client heeft geen gegevens verzonden of bevestigd en uiteindelijk is timeout client verlopen.
SC	de server weigerde expliciet de TCP-verbinding.
PC	de proxy weigerde een verbinding met de server tot stand te brengen omdat de socket-limiet van het proces werd bereikt tijdens het verbinden.

Er zijn verschillende redenen waarom een verbinding gesloten kan zijn. Gedetailleerde informatie over alle mogelijke beëindigingscodes is te vinden in de HAProxy documentatie.

tellers

tellers geven de status van het systeem aan wanneer een verzoek werd goedgekeurd. HAProxy registreert vijf tellers voor elke verbinding of aanvraag. Ze kunnen van onschatbare waarde zijn bij het bepalen hoeveel belasting er op het systeem wordt geplaatst, waar het systeem achterblijft, en of er grenzen zijn geraakt. Als je naar een regel binnen de log kijkt, zie je de tellers weergegeven als vijf getallen gescheiden door schuine strepen: 0/0/0/0/0.

in de TCP-of HTTP-modus worden deze opgesplitst als:

• het totale aantal gelijktijdige verbindingen op het HAProxy-proces toen de sessie werd gelogd.
• het totale aantal gelijktijdige verbindingen dat via deze verbinding wordt gerouteerd frontend toen de sessie werd gelogd.
• het totale aantal gelijktijdige verbindingen dat naar deze backend werd gerouteerd.
• het totale aantal gelijktijdige verbindingen dat nog actief is op deze server toen de sessie werd gelogd.
• het aantal pogingen om opnieuw verbinding te maken met de backend-server.

andere velden

HAProxy registreert niet alles out-of-the-box, maar u kunt het aanpassen om vast te leggen wat u nodig hebt. Een HTTP request header kan gelogd worden door de http-request capture directive toe te voegen:

Het log zal headers tonen tussen accolades en gescheiden door pipesymbolen. Hier kunt u de headers van Host en User-Agent zien voor een verzoek:

een reactieheader kan gelogd worden door een http-response capture directive toe te voegen:

in dit geval moet u ook een declare capture response directive toevoegen, die een capture slot toewijst waar de reactieheader, zodra deze arriveert, kan worden opgeslagen. Aan elk slot dat u toevoegt, wordt automatisch een ID toegewezen vanaf nul. Refereer naar dit ID bij het aanroepen van http-response capture. Antwoordheaders worden gelogd na de aanvraagheaders, binnen een aparte set accolades.

Cookie waarden kunnen op een vergelijkbare manier worden ingelogd met dehttp-request capture richtlijn.

alles wat is vastgelegd met http-request capture, inclusief HTTP headers en cookies, zal binnen dezelfde set accolades verschijnen. Hetzelfde geldt voor alles wat is vastgelegd met http-response capture.

u kunt ook http-request capture gebruiken om verzamelde gegevens uit stoktabellen te loggen. Als u gebruikersaanvragen bijhoudt met een stick-table, kunt u ze als volgt loggen:

dus, een verzoek indienen naar een webpagina die het HTML-document bevat en twee afbeeldingen zouden de gelijktijdige aanvraagsnelheid van de gebruiker laten zien, oplopend naar drie:

u kunt ook de waarden van fetch-methoden registreren, zoals de versie van SSL/TLS die werd gebruikt (Merk op dat er een ingebouwde log variabele is om dit te verkrijgen genaamd %sslv):

variabelen die zijn ingesteld met http-request set-var kunnen ook worden gelogd.

ACL expressies evalueren naar true of false. U kunt ze niet direct loggen, maar u kunt een variabele instellen op basis van de vraag of de expressie waar is. Bijvoorbeeld, als de gebruiker /api bezoekt, kunt u een variabele genaamd req.is_api instellen op een waarde van IS API en dat vervolgens vastleggen in de logs.

enabling HAProxy Profiling

met de release van HAProxy 1.9, kunt u CPU tijd besteed aan het verwerken van een verzoek binnen HAProxy opnemen. Voeg de profiling.tasks richtlijn voor uw global sectie:

Er zijn nieuwe halen methoden die bloot de profilering statistieken:

Fetch-methode	Omschrijving
date_us	De microseconden deel van de datum.
cpu_calls	het aantal aanroepen naar de taak die de stream of huidige aanvraag verwerkt sinds deze is toegewezen. Het wordt gereset voor elke nieuwe aanvraag op dezelfde verbinding.
cpu_ns_avg	het gemiddelde aantal nanoseconden dat wordt besteed aan elke aanroep naar de taak die de stroom of huidige aanvraag verwerkt.
cpu_ns_tot	het totale aantal nanoseconden dat wordt besteed aan elke aanroep naar de taak die de stream of huidige aanvraag verwerkt.
lat_ns_avg	het gemiddelde aantal nanoseconden dat wordt besteed tussen het moment dat de taak waarmee de stream wordt behandeld wordt gewekt en het moment dat deze effectief wordt aangeroepen.
lat_ns_tot	het totale aantal nanoseconden tussen het moment dat de taak die de stream behandelt wordt gewekt en het moment dat deze effectief wordt aangeroepen.

voeg deze als volgt toe aan uw logberichten:

Dit is een geweldige manier om te peilen welke verzoeken het meest kosten om te verwerken.

het ontleden van HAProxy Logs

zoals je hebt geleerd, heeft HAProxy veel velden die een enorme hoeveelheid inzicht bieden over verbindingen en verzoeken. Echter, het lezen van hen direct kan leiden tot informatie-overload. Vaak is het makkelijker om ze te ontleden en te aggregeren met externe tools. In deze sectie, zie je een aantal van deze tools en hoe ze kunnen profiteren van de logging informatie die door HAProxy.

HALog

HALog is een kleine maar krachtige log analyse tool die wordt geleverd met HAProxy. Het is ontworpen om te worden ingezet op productieservers waar het kan helpen met handmatige probleemoplossing, zoals bij live-problemen. Het is extreem snel en in staat om TCP en HTTP logs te ontleden met 1 tot 2 GB per seconde. Door een combinatie van vlaggen door te geven, kunt u statistische informatie uit de logboeken halen, inclusief verzoeken per URL en verzoeken per bron-IP. Vervolgens kunt u sorteren op reactietijd, foutenpercentage en beëindigingscode.

als u bijvoorbeeld statistieken per server uit de logboeken wilt extraheren, kunt u het volgende commando gebruiken:

Dit is handig wanneer u logregels per statuscode moet ontleden en snel moet ontdekken of een bepaalde server ongezond is (bijvoorbeeld te veel 5xx-reacties retourneren). Of, een server kan te veel verzoeken weigeren (4xx reacties), wat een teken is van een brute-force aanval. U kunt ook de gemiddelde responstijd per server krijgen met de kolom avg_rt, wat handig is voor het oplossen van problemen.

met HALog kunt u per-URL statistieken verkrijgen met het volgende commando:

De output toont het aantal verzoeken, het aantal fouten, de totale rekentijd, de gemiddelde rekentijd, de totale rekentijd van succesvolle Verzoeken, de gemiddelde rekentijd van succesvolle verzoeken, het gemiddelde aantal verzonden bytes en het totale aantal verzonden bytes. Naast het ontleden van server-en URL-statistieken, kunt u meerdere filters toepassen om logboeken te matchen met een bepaalde responstijd, HTTP-statuscode, sessiebeëindigingscode, enz.

HAProxy Stats Page

Het ontleden van de logs met HALog is niet de enige manier om metrics uit HAProxy te krijgen. De HAProxy Stats pagina kan worden ingeschakeld door de stats enable richtlijn toe te voegen aan een frontend of listen sectie. Het toont live statistieken van uw servers. De volgende listen sectie start de pagina statistieken luisteren op poort 8404:

de pagina statistieken is erg handig voor het verkrijgen van directe informatie over het verkeer dat door HAProxy stroomt. Het slaat deze gegevens echter niet op en geeft alleen gegevens weer voor een enkele load balancer.

HAProxy Enterprise Real-Time Dashboard

Als u HAProxy Enterprise gebruikt, hebt u toegang tot het real-Time Dashboard. Terwijl de statistieken pagina toont statistieken voor een enkele instantie van HAProxy, de Real-Time Dashboard aggregaten en geeft informatie over een cluster van load balancers. Dit maakt het gemakkelijk om de gezondheid van al uw servers te observeren vanaf een enkel scherm. Gegevens kunnen tot 30 minuten worden bekeken.

het dashboard slaat informatie op en toont informatie over servicestatus, aanvraagpercentages en belasting. Het maakt het ook gemakkelijker om administratieve taken uit te voeren, zoals het in -, uitschakelen en aftappen van backends. In één oogopslag kunt u zien welke servers up en voor hoe lang. U kunt ook de gegevens van de stoktabel bekijken, die, afhankelijk van wat de stoktabel volgt, u foutenpercentages, aanvraagpercentages en andere real-time informatie over uw gebruikers kunnen tonen. Stick table gegevens kunnen ook worden samengevoegd.

Het real-Time Dashboard is een van de vele add-ons die beschikbaar zijn met HAProxy Enterprise.

conclusie

In deze blogpost hebt u geleerd hoe u HAProxy logging kunt configureren om de zichtbaarheid van uw load balancer te verkrijgen, wat een cruciaal onderdeel is binnen uw infrastructuur. HAProxy zendt gedetailleerde Syslog-berichten uit bij gebruik in TCP – en HTTP-modus. Deze kunnen worden verzonden naar een aantal logging tools, zoals rsyslog.

HAProxy wordt geleverd met het opdrachtregelprogramma HALog, dat het verwerken van loggegevens vereenvoudigt wanneer u informatie nodig hebt over de soorten reacties die gebruikers krijgen en de belasting op uw servers. U kunt ook een beeld krijgen van de gezondheid van uw servers door gebruik te maken van de HAProxy Stats pagina of het HAProxy Enterprise Real-Time Dashboard.

wilt u weten wanneer deze inhoud wordt gepubliceerd? Abonneer je op deze blog of volg ons op Twitter. U kunt ook deelnemen aan het gesprek op Slack! HAProxy Enterprise combineert HAProxy met enterprise-class functies, zoals het Real-Time Dashboard en premium support. Neem contact met ons op voor meer informatie of Meld u vandaag nog aan voor een gratis proefperiode!