Bevezetés a HAProxy Naplózásba

amikor a naplóadatok operacionalizálásáról van szó, a HAProxy rengeteg információt nyújt. Ebben a blogbejegyzésben bemutatjuk, hogyan kell beállítani a HAProxy naplózást, megcélozni egy Syslog szervert, megérteni a naplómezőket, és javasolni néhány hasznos eszközt a naplófájlok elemzéséhez.

mély merülés HAProxy naplózás

HAProxy ül a kritikus utat az infrastruktúra. Akár élterhelés-kiegyenlítőként, oldalkocsiként, akár Kubernetes behatolásvezérlőként használják, az értelmes naplók kiszállítása a HAProxy-ból kötelező.

a naplózás betekintést nyújt az egyes kapcsolatokba és kérésekbe. Lehetővé teszi a hibaelhárításhoz szükséges megfigyelhetőséget, sőt a problémák korai felismerésére is használható. Ez az egyik módja annak, hogy információt szerezzen a HAProxy-tól. Más módszerek közé tartozik a metrikák beszerzése a statisztikai oldal vagy a futásidejű API használatával, e-mail riasztások beállítása, valamint a különféle nyílt forráskódú integrációk felhasználása napló vagy statisztikai adatok időbeli tárolására. A HAProxy nagyon részletes naplókat biztosít milliszekundumos pontossággal, és rengeteg információt generál az infrastruktúrába áramló forgalomról. Ez magában foglalja:

• metrikák a forgalomról: időzítési adatok, kapcsolatok számlálói, forgalom mérete stb.
• információ a HAProxy döntésekről: tartalomváltás, szűrés, perzisztencia stb.
• információ a kérésekről és válaszokról: fejlécek, állapotkódok, hasznos terhelések stb.
• a munkamenet befejezési állapota és a hibák nyomon követésének képessége (kliens oldal, szerver oldal?)

ebben a bejegyzésben megtudhatja, hogyan konfigurálhatja a HAProxy naplózást, és hogyan olvassa el az általa generált naplóüzeneteket. Ezután felsorolunk néhány eszközt, amelyek hasznosak lesznek a naplóadatok operacionalizálásakor.

Syslog Server

a HAProxy képes naplózási üzenetet kibocsátani egy syslog szerver általi feldolgozásra. Ez kompatibilis az ismerős syslog eszközökkel, mint például az Rsyslog, valamint az újabb systemd szolgáltatás journald. Különböző naplófuvarozókat is használhat, mint például a Logstash és a Fluentd, hogy megkapja a Syslog üzeneteket a HAProxy-tól, és eljuttassa őket egy központi napló-összesítőhöz.

ha konténer környezetben dolgozik, a HAProxy támogatja a felhőalapú natív naplózást, amely lehetővé teszi a naplóüzenetek elküldését az stdout és az stderr számára. Ebben az esetben ugorjon a következő szakaszra, ahol láthatja, hogyan.

mielőtt megvizsgálná, hogyan engedélyezheti a naplózást a HAProxy konfigurációs fájlon keresztül, először győződjön meg arról, hogy van egy Syslog szerver, például az rsyslog, amely konfigurálva van a naplók fogadására. Az Ubuntuban az rsyslogot az apt csomagkezelő segítségével telepítené, így:

miután az rsyslog telepítve van, szerkessze a konfigurációját a HAProxy naplóüzenetek bevitelének kezeléséhez. Adja hozzá a következőket az /etc/rsyslog állományhoz.conf vagy egy új fájlt a rsyslog.d könyvtár, például az /etc/rsyslog.d / haproxy.conf:

ezután indítsa újra az rsyslog szolgáltatást. A fenti példában az rsyslog a 127.0.0.1 IP visszacsatolási címet figyeli az alapértelmezett 514 UDP porton. Ez a konfiguráció két naplófájlba ír. A kiválasztott fájl azon a súlyossági szinten alapul, amellyel az üzenetet naplózták. Ennek megértése érdekében nézze meg közelebbről a fájl utolsó két sorát. Úgy kezdődik, mint ez:

a Syslog szabvány előírja, hogy minden naplózott üzenethez hozzá kell rendelni egy létesítménykódot és egy súlyossági szintet. A fenti rsyslog konfigurációs példa alapján feltételezhetjük, hogy a HAProxy-t úgy konfiguráljuk, hogy az összes naplóüzenetét local0 létesítménykóddal küldje el.

a súlyossági szint a létesítménykód után van megadva, ponttal elválasztva. Itt az első sor minden súlyossági szinten rögzíti az üzeneteket, és egy haproxy-traffic nevű fájlba írja őket.napló. A második sor csak értesítési szintű vagy annál magasabb üzeneteket rögzít, naplózva őket egy haproxy-admin nevű fájlba.napló.

a HAProxy kódolt, hogy bizonyos súlyossági szinteket használjon bizonyos üzenetek küldésekor. Például a kapcsolatokhoz és a HTTP-kérésekhez kapcsolódó naplóüzeneteket az info súlyossági szinttel kategorizálja. Más eseményeket a másik, kevésbé bőbeszédű szintek egyikével kategorizálunk. A legtöbbtől a legkevésbé fontosig a súlyossági szintek a következők:

súlyossági szint	HAProxy naplók
emerg	hibák, például az operációs rendszer fájlleíróinak kifogyása.
alert	néhány ritka eset, amikor valami váratlan történt, például nem sikerült gyorsítótárazni a választ.
crit	nem használt.
err	hibák, mint például, hogy nem tudja elemezni a térkép fájlt, hogy nem tudja elemezni a HAProxy konfigurációs fájl, és ha egy művelet egy stick tábla sikertelen.
figyelmeztetés	bizonyos fontos, de nem kritikus hibák, mint például a kérés fejlécének beállítása vagy a DNS-névszerverhez való csatlakozás elmulasztása.
értesítés	a szerver állapotának változásai, például felfelé vagy lefelé, vagy ha a szerver le van tiltva. Az indításkor más események is szerepelnek, például a proxyk indítása és a modulok betöltése. Az állapotfelmérés naplózása, Ha engedélyezve van, szintén ezt a szintet használja.
info	TCP kapcsolat és HTTP kérés részletei és hibái.
debug	írhat egyéni Lua kódot, amely naplózza a hibakeresési üzeneteket

a Modern Linux disztribúciókat a Service manager systemd szállítja, amely bevezeti a naplót a naplók gyűjtésére és tárolására. A journald szolgáltatás nem Syslog implementáció, de Syslog kompatibilis, mivel ugyanazon a /dev/log aljzaton fog hallgatni. Összegyűjti a beérkezett naplókat, és lehetővé teszi a felhasználó számára, hogy szűrje őket létesítménykód és/vagy súlyossági szint szerint az egyenértékű naplómezőkkel (SYSLOG_FACILITY, PRIORITY).

HAProxy naplózási konfiguráció

a HAProxy konfigurációs kézikönyv elmagyarázza, hogy a naplózást két lépéssel lehet engedélyezni: az első egy Syslog szerver megadása a global szakaszban egy log irányelv használatával:

a log irányelv utasítja HAProxy küldeni naplók a syslog szerver hallgat a 127.0.0.1:514. Az üzenetek a local0 szolgáltatással kerülnek elküldésre, amely az egyik szabványos, felhasználó által definiált Syslog szolgáltatás. Ez az a lehetőség is, amelyet az rsyslog konfigurációnk vár. Egynél több log utasítást adhat hozzá, hogy kimenetet küldjön több Syslog szerverre.

a naplózási szint hozzáadásával szabályozhatja, hogy mennyi információ kerül naplózásra:

a naplózás konfigurálásának második lépése a különböző proxyk frissítése (frontendbackend, és listen szakaszok) az üzenetek küldéséhez a global szakaszban konfigurált syslog szerver(ek) re. Ez egy log global irányelv hozzáadásával történik. Hozzáadhatja adefaults szakaszhoz, amint látható:

alog global irányelv alapvetően azt mondja, használja alog sort, amelyet aglobal szakaszban állítottak be. A log global irányelv beillesztése a defaults szakaszba egyenértékű az összes következő proxy szakaszba helyezésével. Tehát ez lehetővé teszi az összes proxy bejelentkezését. A HAProxy konfigurációs fájl szakaszairól többet olvashat blogbejegyzésünkben a HAProxy konfiguráció négy alapvető szakasza.

alapértelmezés szerint a HAProxy kimenete minimális. A option httplog sor hozzáadása a defaults szakaszhoz további részletes HTTP naplózást tesz lehetővé, amelyet később részletesebben ismertetünk.

egy tipikus HAProxy konfiguráció így néz ki:

a globális naplózási szabályok használata a leggyakoribb HAProxy beállítás, de ezeket közvetlenül a frontend szakaszba helyezheti. Hasznos lehet, ha egy másik naplózási konfiguráció egyszeri. Érdemes például egy másik cél Syslog kiszolgálóra mutatni, egy másik naplózási lehetőséget használni, vagy különböző súlyossági szinteket rögzíteni a háttéralkalmazás Használati esetétől függően. Tekintsük a következő példát, amelyben afrontend szakaszok, fe_site1 és fe_site2, különböző IP-címeket és súlyossági szinteket állítanak be:

helyi Syslog szolgáltatásba történő bejelentkezéskor a UNIX socket-be történő írás gyorsabb lehet, mint a TCP visszacsatolási cím megcélzása. Általában Linux rendszereken a Syslog üzeneteket figyelő UNIX socket elérhető a /dev/log címen, mert itt a GNU C könyvtár syslog() funkciója alapértelmezés szerint üzeneteket küld. Célozza meg a UNIX socket—et így:

azonban ne feledje, hogy ha Unix socket—et fog használni a naplózáshoz, és ugyanakkor a HAProxy-t chroot környezetben futtatja-vagy hagyja, hogy a HAProxy hozzon létre egy chroot könyvtárat a chroot konfigurációs irányelv használatával -, akkor a UNIX socket-et elérhetővé kell tenni abban a chroot könyvtárban. Ezt kétféle módon lehet megtenni.

először is, amikor az rsyslog elindul, létrehozhat egy új hallgatási aljzatot a chroot fájlrendszeren belül. Adja hozzá a következőket a HAProxy rsyslog konfigurációs fájljához:

a második módszer a socket kézi hozzáadása a chroot fájlrendszerhez amount paranccsal a--bind opcióval.

mindenképpen adjunk hozzá egy bejegyzést az /etc/fstab fájlhoz vagy egy systemd egység fájlhoz, hogy a csatolás az újraindítás után is fennmaradjon. Miután konfigurálta a naplózást, meg kell értenie az üzenetek felépítését. A következő részben a TCP-és HTTP-szintű naplókat alkotó mezők láthatók.

ha korlátozni kell a tárolt adatok mennyiségét, az egyik módja a naplóüzenetek csak egy részének mintavétele. Állítsa a naplószintet csendes értékre véletlenszerű számú kéréshez, például:

vegye figyelembe, hogy ha lehetséges, jobb, ha annyi adatot rögzít, amennyit csak tud. Így nincs hiányzó információ, Amikor a legnagyobb szüksége van rá. Az ACL kifejezést úgy is módosíthatja, hogy bizonyos feltételek felülírják a szabályt.

a naplózott üzenetek számának korlátozásának másik módja a option dontlog-normalbeállítása a defaultsvagy frontend. Így csak időtúllépések, újrapróbálkozások és hibák kerülnek rögzítésre. Valószínűleg nem akarja ezt egész idő alatt engedélyezni, hanem csak bizonyos időpontokban, például benchmarking tesztek végrehajtásakor.

Ha a HAProxy-t egy Docker tárolóban futtatja, és a HAProxy 1.9-es verzióját használja, akkor a naplókimenet Syslog szerverre történő küldése helyett elküldheti azt az stdout és/vagy stderr címre. Állítsa be a címet stdout vagy stderr. Ebben az esetben célszerű az üzenet formátumát raw értékre állítani, például:

HAProxy Log Format

a naplózás típusát a HAProxy-ban beállított proxy mód határozza meg. A HAProxy működhet 4. réteg (TCP) proxyként vagy 7.réteg (HTTP) proxyként. A TCP mód Az alapértelmezett. Ebben a módban full-duplex kapcsolat jön létre az ügyfelek és a szerverek között, és nem kerül sor a 7.réteg vizsgálatára. Ha az rsyslog konfigurációját az első szakaszban folytatott megbeszélésünk alapján állította be, akkor a naplófájlt a /var/log/haproxy-traffic könyvtárban találja.napló.

TCP módban, amelyet a mode tcp hozzáadásával állít be, hozzá kell adnia a tcplog opciót is. Ezzel az opcióval a naplóformátum alapértelmezés szerint olyan struktúrát jelent, amely hasznos információkat nyújt, például a 4.réteg kapcsolatának részleteit, időzítőket, bájtok számát stb. Ha újra létrehozná ezt a formátumot a log-format használatával, amely egyéni formátum beállítására szolgál, akkor ez így néz ki:

ezeknek a mezőknek a leírása megtalálható a TCP log format dokumentációban, bár a következő részben többet fogunk leírni.

amikor a HAProxy Layer 7 proxyként fut a mode http segítségével, hozzá kell adnia a httplog irányelv opciót. Ez biztosítja, hogy a HTTP kéréseket és válaszokat alaposan elemezzék, és hogy egyetlen RFC-kompatibilis tartalom sem marad el. Ez az a mód, amely valóban kiemeli a HAProxy diagnosztikai értékét. A HTTP log formátum ugyanolyan szintű információt nyújt, mint a TCP formátum, de a HTTP protokollra jellemző további adatokkal. Ha újra létrehozná ezt a formátumot a log-format használatával, ez így nézne ki:

a különböző mezők részletes leírása megtalálható a HTTP log formátum dokumentációjában.

egyéni naplóformátumot is megadhat, csak azt rögzítve, amire szüksége van. Használja alog-format (vagylog-format-sd A strukturált adatok syslog) irányelvet adefaults vagyfrontend. Olvassa el a blogbejegyzést HAProxy Log Testreszabás többet megtudni, és néhány példát.

a következő néhány szakaszban megismerheti azokat a mezőket, amelyek a option tcplogvagy option httplog használatakor szerepelnek.

proxyk

a létrehozott naplófájlban minden sor azzal a frontenddel, backenddel és kiszolgálóval kezdődik, amelyre a kérést elküldték. Például, ha a következő HAProxy konfigurációval rendelkezett, akkor olyan sorokat látna, amelyek leírják a kéréseket a http-in kezelőfelületen keresztül a statikus háttérbe, majd az srv1 kiszolgálóra.

Ez akkor válik létfontosságú információvá, ha tudnia kell, hová küldték a kérést, például amikor olyan hibákat lát, amelyek csak néhány kiszolgálót érintenek.

Időzítők

az időzítők ezredmásodpercben vannak megadva, és lefedik a munkamenet során bekövetkező eseményeket. Az alapértelmezett TCP log formátum által rögzített időzítők Tw / Tc / Tt. Az alapértelmezett HTTP log formátum A TR/ Tw / Tc / Tr / Ta. Ezek lefordítani, mint:

Timer	jelentése
TR	a teljes idő, hogy az ügyfél kérésére (HTTP módban).
Tw	a csatlakozási nyílásra váró sorokban töltött teljes idő.
Tc	a szerverrel való TCP kapcsolat létrehozásának teljes ideje.
Tr	a szerver válaszideje (csak HTTP módban).
Ta	a HTTP kérés teljes aktív ideje (csak HTTP módban).
Tt	a teljes TCP munkamenet időtartama, attól a pillanattól kezdve, hogy a proxy elfogadta, és attól a pillanattól kezdve, hogy mindkét vége lezárult.

az összes rendelkezésre álló időzítő részletes leírását megtalálja a HAProxy dokumentációjában. Az alábbi ábra azt is bemutatja, hogy az idő hol kerül rögzítésre egyetlen végpontok közötti tranzakció során. Vegye figyelembe, hogy a széleken lévő lila vonalak időzítőket jelölnek.

munkamenet állapot a Leválasztáskor

mind a TCP, mind a HTTP naplók tartalmaznak egy felmondási állapotkódot, amely megmondja, hogy a TCP vagy a HTTP munkamenet hogyan fejeződött be. Ez egy két karakteres kód. Az első karakter az első eseményt jelenti, amely a munkamenet befejezését okozta, míg a második a TCP vagy HTTP munkamenet állapotát jelenti, amikor bezárták.

íme néhány példa a felmondási kódra:

Kétkarakteres kód	jelentése
–	normál Befejezés mindkét oldalon.
cD	a kliens nem küldött és nem nyugtázott semmilyen adatot és végül timeout client lejárt.
SC	a kiszolgáló kifejezetten elutasította a TCP kapcsolatot.
PC	a proxy nem volt hajlandó kapcsolatot létesíteni a szerverrel, mert a folyamat’ socket limitje elérésre került, miközben megpróbált csatlakozni.

sokféle oka lehet annak, hogy egy kapcsolat megszakadt. Az összes lehetséges végződési kódról részletes információk találhatók a HAProxy dokumentációban.

számlálók

számlálók jelzik a rendszer állapotát, amikor egy kérés megtörtént. A HAProxy öt számlálót rögzít minden kapcsolathoz vagy kéréshez. Felbecsülhetetlen értékűek lehetnek annak meghatározásában, hogy mekkora terhelést helyeznek a rendszerre, hol van a rendszer lemaradása, és hogy elérték-e a határokat. Ha egy sort néz a naplóban, a számlálókat öt számként sorolja fel, perjelekkel elválasztva: 0/0/0/0/0.

TCP vagy HTTP módban ezek a következőképpen oszlanak meg:

• a HAProxy folyamat egyidejű kapcsolatainak teljes száma a munkamenet naplózásakor.
• az ezen keresztül továbbított egyidejű kapcsolatok száma frontend a munkamenet naplózásakor.
• az ehhez a backend szekció naplózása során átirányított egyidejű kapcsolatok száma.
• a munkamenet naplózásakor még aktív egyidejű kapcsolatok száma server.
• a háttérkiszolgálóhoz való csatlakozás során megkísérelt újrapróbálkozások száma.

egyéb mezők

a HAProxy nem rögzít mindent a dobozon kívül, de módosíthatja, hogy rögzítse, amire szüksége van. A HTTP kérés fejlécét a http-request capture direktíva hozzáadásával lehet naplózni:

a napló a göndör zárójelek közötti fejléceket mutatja, amelyeket csőjelek választanak el egymástól. Itt láthatja a kérés Host és User-Agent fejléceit:

a válaszfejléc naplózható egy http-response capture irányelv hozzáadásával:

ebben az esetben hozzá kell adnia egy declare capture response irányelvet is, amely egy rögzítési helyet foglal el, ahol a válaszfejléc megérkezése után tárolható. Minden slot, hogy adjunk automatikusan hozzárendel egy azonosítót nulláról indul. Hivatkozzon erre az azonosítóra a http-response capturehívásakor. A válaszfejlécek a kérés fejlécei után kerülnek naplózásra, külön göndör zárójelben.

a Cookie-k értékei hasonló módon naplózhatók ahttp-request capture direktívával.

bármi, amit ahttp-request capture segítségével rögzítettek, beleértve a HTTP fejléceket és a cookie-kat is, ugyanabban a göndör zárójelben jelenik meg. Ugyanez vonatkozik mindenre, amit a http-response capturesegítségével rögzítettek.

a http-request capture használatával naplózhatja a mintavételezett adatokat a bottáblákból. Ha a felhasználói kérések arányát stick-table segítségével követte, akkor a következőképpen naplózhatja őket:

tehát egy HTML dokumentumot és két képet tartalmazó weboldalra történő kérés esetén a felhasználó egyidejű kérési aránya hárommal növekszik:

naplózhatja a lekérési módszerek értékeit is, például rögzítheti az SSL/TLS használt verzióját (vegye figyelembe, hogy van egy beépített naplóváltozó ennek megszerzéséhez, az úgynevezett %sslv):

a http-request set-var változók is naplózhatók.

az ACL kifejezések értéke Igaz vagy hamis. Közvetlenül nem tudja naplózni őket, de beállíthat egy változót annak alapján, hogy a kifejezés igaz-e. Például, ha a felhasználó meglátogatja a /api-t, beállíthat egy req.is_api nevű változót is API értékre, majd rögzítheti azt a naplókban.

A HAProxy profilozás engedélyezése

a HAProxy 1.9 kiadásával rögzítheti a HAProxy-n belüli kérés feldolgozására fordított CPU-időt. Adja hozzá a profiling.tasks irányelvet a global szakasz:

vannak új letöltési módszerek, amelyek feltárják a profilozási mutatókat:

fetch method	leírás
date_us	a dátum mikroszekundumos része.
cpu_calls	az adatfolyamot vagy az aktuális kérést feldolgozó feladathoz intézett hívások száma a kiosztás óta. Ez visszaáll minden új kérés ugyanazon a kapcsolaton.
cpu_ns_avg	az adatfolyamot vagy az aktuális kérést feldolgozó feladat minden egyes hívásában eltöltött nanoszekundumok átlagos száma.
cpu_ns_tot	az adatfolyamot vagy az aktuális kérést feldolgozó feladat minden egyes hívásában eltöltött nanoszekundumok száma.
lat_ns_avg	az adatfolyamot kezelő feladat felébresztésének és a tényleges meghívásának pillanata között eltöltött nanoszekundumok átlagos száma.
lat_ns_tot	a nanoszekundumok teljes száma az adatfolyamot kezelő feladat felébresztése és a tényleges meghívás pillanata között.

adja hozzá ezeket a naplóüzenetekhez, mint ez:

Ez egy nagyszerű módja annak, hogy felmérje, mely kérések feldolgozása kerül a legtöbbe.

A HAProxy naplók elemzése

mint megtanultad, a HAProxy számos mezővel rendelkezik, amelyek óriási betekintést nyújtanak a kapcsolatokba és a kérésekbe. A közvetlen olvasás azonban információs túlterheléshez vezethet. Gyakran könnyebb elemezni és összesíteni őket külső eszközökkel. Ebben a szakaszban néhány ilyen eszközt láthat, valamint azt, hogy hogyan tudják kihasználni a HAProxy által biztosított naplózási információkat.

HALog

a HALog egy kicsi, de hatékony naplóelemző eszköz, amelyet a HAProxy szállít. Úgy tervezték, hogy a termelési szerverekre telepíthető legyen, ahol segíthet a kézi hibaelhárításban, például amikor élő problémákkal szembesül. Rendkívül gyors és képes a TCP és HTTP naplók elemzésére másodpercenként 1-2 GB sebességgel. A zászlók kombinációjának átadásával statisztikai információkat nyerhet ki a naplókból, beleértve az URL-enkénti kéréseket és a forrás IP-nkénti kéréseket. Ezután rendezheti a válaszidőt, a hibaarányt és a felmondási kódot.

ha például kiszolgálónkénti statisztikákat szeretne kinyerni a naplókból, használhatja a következő parancsot:

Ez akkor hasznos, ha állapotkódonként kell elemezni a naplósorokat, és gyorsan fel kell deríteni, hogy egy adott szerver egészségtelen-e (pl. túl sok 5xx választ ad vissza). Vagy lehet, hogy egy szerver túl sok kérést tagad meg (4xx válaszok), ami a brute-force támadás jele. A kiszolgálónkénti átlagos válaszidőt a avg_rt oszlop segítségével is megkaphatja, amely hasznos a hibaelhárításhoz.

a HALog segítségével URL-statisztikákat kaphat a következő paranccsal:

a kimenet a kérések számát, A hibák számát, A teljes számítási időt, az átlagos számítási időt, a sikeres kérések teljes számítási idejét, a sikeres kérések átlagos számítási idejét, az elküldött bájtok átlagos számát és az elküldött bájtok teljes számát mutatja. A szerver-és URL-statisztikák elemzése mellett több szűrőt is alkalmazhat, hogy a naplókat egy adott válaszidővel, HTTP-állapotkóddal, munkamenet-lezárási kóddal stb.

HAProxy Stats oldal

a naplók HALog segítségével történő elemzése nem az egyetlen módja annak, hogy a mutatókat a HAProxy-ból kihozzuk. A HAProxy Stats oldal engedélyezhető a stats enable irányelv hozzáadásával a frontend vagy listen szakaszhoz. Megjeleníti a szerverek élő statisztikáit. A következőlisten szakasz elindítja a statisztika oldalt, amely a 8404-es porton hallgat:

A statisztika oldal nagyon hasznos, ha azonnali információt szeretne kapni a HAProxy-n keresztül áramló forgalomról. Ezeket az adatokat azonban nem tárolja, és csak egyetlen terheléselosztóhoz jeleníti meg az adatokat.

HAProxy Enterprise valós idejű Irányítópult

Ha HAProxy Enterprise-t használ, akkor hozzáférhet a valós idejű irányítópulthoz. Míg a statisztika oldal a HAProxy egyetlen példányának statisztikáit mutatja, a valós idejű Irányítópult összesíti és megjeleníti az információkat a terheléselosztók klaszterében. Ez megkönnyíti az összes szerver egészségének megfigyelését egyetlen képernyőn. Az adatok akár 30 percig is megtekinthetők.

az irányítópult információkat tárol és jelenít meg a szolgáltatás állapotáról, a kérések arányáról és a betöltésről. Ezenkívül megkönnyíti az adminisztratív feladatok elvégzését, például a háttérprogramok engedélyezését, letiltását és ürítését. Egy pillantással láthatja, hogy mely szerverek működnek és mennyi ideig. Megtekintheti a stick tábla adatait is, amelyek attól függően, hogy a stick tábla mit követ, megjeleníthetik a hibaarányokat, a kérések arányát és más valós idejű információkat a felhasználókról. A Stick táblázat adatai is összesíthetők.

a valós idejű Irányítópult a HAProxy Enterprise számos kiegészítőjének egyike.

következtetés

ebben a blogbejegyzésben megtanulta, hogyan kell konfigurálni a HAProxy naplózást, hogy megfigyelhetőséget kapjon a terheléselosztón, amely az infrastruktúra kritikus eleme. A HAProxy részletes Syslog üzeneteket bocsát ki, ha TCP vagy HTTP módban működik. Ezeket lehet küldeni számos naplózási eszközök, mint például rsyslog.

a HAProxy a HALog parancssori segédprogrammal érkezik, amely leegyszerűsíti a naplóadatok elemzését, amikor információra van szüksége a felhasználók által kapott válaszok típusairól és a kiszolgálók terheléséről. A kiszolgálók állapotáról a HAProxy Stats oldal vagy a HAProxy Enterprise valós idejű Irányítópult segítségével is képet kaphat.

szeretné tudni, hogy mikor jelenik meg ilyen tartalom? Iratkozzon fel erre a blogra, vagy kövessen minket a Twitteren. Csatlakozhat a beszélgetéshez a Slack oldalon is! A HAProxy Enterprise egyesíti a HAProxy-t a vállalati szintű funkciókkal, például a valós idejű irányítópulttal és a prémium Támogatással. Vegye fel velünk a kapcsolatot, ha többet szeretne megtudni, vagy regisztráljon még ma egy ingyenes próbaverzióra!