Introduzione alla registrazione HAProxy

Quando si tratta di rendere operativi i dati di registro, HAProxy fornisce una vasta gamma di informazioni. In questo post del blog, dimostriamo come impostare la registrazione HAProxy, indirizzare un server Syslog, comprendere i campi di log e suggerire alcuni strumenti utili per l’analisi dei file di log.

Immersione profonda nella registrazione HAProxy

HAProxy si trova nel percorso critico della tua infrastruttura. Che sia usato come edge load balancer, sidecar o come controller di ingresso Kubernetes, ottenere log significativi da HAProxy è un must.

La registrazione fornisce informazioni su ogni connessione e richiesta. Consente l’osservabilità necessaria per la risoluzione dei problemi e può anche essere utilizzato per rilevare i problemi in anticipo. È uno dei tanti modi per ottenere informazioni da HAProxy. Altri modi includono ottenere metriche utilizzando la pagina delle statistiche o l’API di runtime, impostare avvisi e-mail e utilizzare le varie integrazioni open-source per la memorizzazione di log o dati statistici nel tempo. HAProxy fornisce registri molto dettagliati con precisione al millisecondo e genera una grande quantità di informazioni sul traffico che scorre nella tua infrastruttura. Ciò include:

• Metriche sul traffico: dati di temporizzazione, contatori di connessioni,dimensioni del traffico, ecc.
• Informazioni sulle decisioni HAProxy: commutazione dei contenuti, filtraggio, persistenza, ecc.
• Informazioni su richieste e risposte: intestazioni, codici di stato, payload, ecc.
• Stato di terminazione di una sessione e la possibilità di tenere traccia dove si verificano errori (lato client, lato server?)

In questo post, imparerai come configurare la registrazione HAProxy e come leggere i messaggi di log che genera. Elencheremo quindi alcuni strumenti che troverai utili durante l’operatività dei tuoi dati di registro.

Syslog Server

HAProxy può emettere messaggi di log per l’elaborazione da parte di un server syslog. Questo è compatibile con strumenti syslog familiari come Rsyslog, così come il più recente servizio systemd journald. È inoltre possibile utilizzare vari forwarder di log come Logstash e Fluentd per ricevere messaggi Syslog da HAProxy e spedirli a un aggregatore di log centrale.

Se si lavora in un ambiente contenitore, HAProxy supporta la registrazione nativa del cloud che consente di inviare i messaggi di log a stdout e stderr. In tal caso, passa alla sezione successiva in cui vedrai come.

Prima di esaminare come abilitare la registrazione tramite il file di configurazione HAProxy, è necessario assicurarsi di avere un server Syslog, come rsyslog, configurato per ricevere i log. Su Ubuntu, dovresti installare rsyslog usando il gestore di pacchetti apt, in questo modo:

Una volta installato rsyslog, modifica la sua configurazione per gestire l’ingestione di messaggi di log HAProxy. Aggiungi quanto segue a / etc / rsyslog.conf o a un nuovo file all’interno di rsyslog.d directory, come /etc / rsyslog.d / haproxy.conf:

Quindi, riavviare il servizio rsyslog. Nell’esempio sopra, rsyslog ascolta sull’indirizzo di loopback IP, 127.0.0.1, sulla porta UDP predefinita 514. Questa particolare configurazione scrive su due file di registro. Il file scelto si basa sul livello di gravità con cui è stato registrato il messaggio. Per capire questo, dai un’occhiata più da vicino alle ultime due righe del file. Iniziano così:

Lo standard Syslog prescrive che ad ogni messaggio registrato debba essere assegnato un codice di struttura e un livello di gravità. Dato l’esempio di configurazione rsyslog sopra, si può presumere che configureremo HAProxy per inviare tutti i suoi messaggi di registro con un codice di struttura di local0.

Il livello di gravità viene specificato dopo il codice della struttura, separato da un punto. Qui, la prima riga acquisisce i messaggi a tutti i livelli di gravità e li scrive in un file chiamato haproxy-traffic.log. La seconda riga acquisisce solo messaggi a livello di avviso e superiori, registrandoli in un file chiamato haproxy-admin.log.

HAProxy è hardcoded per utilizzare determinati livelli di gravità quando si inviano determinati messaggi. Ad esempio, categorizza i messaggi di log relativi alle connessioni e alle richieste HTTP con il livello di gravità delle informazioni. Altri eventi sono classificati utilizzando uno degli altri livelli meno prolissi. Dal più al meno importante, i livelli di gravità sono:

Livello di Gravità	HAProxy Registri
emerg	Errori, quali l’esecuzione di funzionamento, sistema di descrittori di file.
alert	Alcuni rari casi in cui è successo qualcosa di inaspettato, come l’impossibilità di memorizzare nella cache una risposta.
crit	Non utilizzato.
err	Errori come l’impossibilità di analizzare un file di mappa, l’impossibilità di analizzare il file di configurazione HAProxy e quando un’operazione su una tabella stick fallisce.
avviso	Alcuni errori importanti, ma non critici, come la mancata impostazione di un’intestazione di richiesta o la mancata connessione a un nameserver DNS.
avviso	Modifiche allo stato di un server, ad esempio in ALTO o in BASSO o quando un server è disabilitato. Sono inclusi anche altri eventi all’avvio, come l’avvio dei proxy e il caricamento dei moduli. Anche la registrazione del controllo dello stato, se abilitata, utilizza questo livello.
info	Connessione TCP e richiesta HTTP dettagli ed errori.
debug	È possibile scrivere codice Lua personalizzato che registra i messaggi di debug

Le moderne distribuzioni Linux vengono fornite con il service manager systemd, che introduce journald per la raccolta e la memorizzazione dei log. Il servizio journald non è un’implementazione Syslog, ma è compatibile con Syslog poiché ascolterà sullo stesso socket /dev/log. Raccoglierà i log ricevuti e consentirà all’utente di filtrarli in base al codice della struttura e/o al livello di gravità utilizzando i campi journald equivalenti (SYSLOG_FACILITY, PRIORITY).

HAProxy Configurazione di Registrazione

HAProxy configurazione manuale spiega che la registrazione può essere attivata in due modi: Il primo è quello di specificare un server Syslog nel global sezione utilizzando un log direttiva:

log direttiva indica HAProxy per inviare i log di Syslog server in ascolto su 127.0.0.1:514. I messaggi vengono inviati con facility local0, che è una delle strutture Syslog standard definite dall’utente. È anche la struttura che la nostra configurazione rsyslog si aspetta. È possibile aggiungere più di un’istruzione log per inviare l’output a più server Syslog.

È possibile controllare la quantità di informazioni è connesso con l’aggiunta di un livello Syslog alla fine della riga:

Il secondo passo per la configurazione della registrazione è quello di aggiornare i diversi proxy (frontendbackend e listen sezioni) per l’invio di messaggi Syslog server(s) configurato nel global sezione. Questo viene fatto aggiungendo una direttivalog global. Puoi aggiungerlo alla sezionedefaults, come mostrato:

La direttivalog global dice fondamentalmente, usa la rigalog che è stata impostata nella sezioneglobal. Inserire una direttivalog global nella sezionedefaults equivale a inserirla in tutte le sezioni proxy successive. Quindi, questo consentirà l’accesso a tutti i proxy. Puoi leggere di più sulle sezioni di un file di configurazione HAProxy nel nostro post sul blog Le quattro sezioni essenziali di una configurazione HAProxy.

Per impostazione predefinita, l’output da HAProxy è minimo. L’aggiunta della riga option httplogalla sezionedefaults consentirà una registrazione HTTP più dettagliata, che spiegheremo più dettagliatamente in seguito.

Una tipica configurazione HAProxy si presenta così:

L’utilizzo delle regole di registrazione globali è la configurazione HAProxy più comune, ma è possibile inserirle direttamente in una sezionefrontend. Può essere utile avere una configurazione di registrazione diversa come una tantum. Ad esempio, è possibile puntare a un server Syslog di destinazione diverso, utilizzare una funzione di registrazione diversa o acquisire livelli di gravità diversi a seconda del caso d’uso dell’applicazione backend. Si consideri il seguente esempio in cui le sezionifrontend, fe_site1 e fe_site2, impostano diversi indirizzi IP e livelli di gravità:

Quando si accede a un servizio Syslog locale, la scrittura su un socket UNIX può essere più veloce del targeting dell’indirizzo di loopback TCP. Generalmente, su sistemi Linux, un socket UNIX che ascolta i messaggi Syslog è disponibile in / dev / log perché è qui che la funzione syslog() della libreria GNU C invia messaggi per impostazione predefinita. Target il socket UNIX come questo:

Tuttavia, si dovrebbe tenere a mente che se si sta andando ad utilizzare un socket UNIX per la registrazione e, al tempo stesso, in esecuzione di HAProxy all’interno di un ambiente chroot—o si lascia HAProxy creare un chroot directory utilizzando il chroot direttiva di configurazione—quindi il socket UNIX deve essere reso disponibile all’interno di tale directory chroot. Questo può essere fatto in due modi.

In primo luogo, quando rsyslog si avvia, può creare un nuovo socket di ascolto all’interno del filesystem chroot. Aggiungi quanto segue al tuo file di configurazione HAProxy rsyslog:

Il secondo modo è aggiungere manualmente il socket al filesystem chroot usando il comando mountcon l’opzione --bind.

Assicurati di aggiungere una voce al tuo file/etc / fstab o a un file di unità systemd in modo che il mount persista dopo un riavvio. Una volta configurata la registrazione, ti consigliamo di capire come sono strutturati i messaggi. Nella sezione successiva, vedrai i campi che compongono i registri a livello TCP e HTTP.

Se è necessario limitare la quantità di dati memorizzati, un modo è quello di campionare solo una parte dei messaggi di log. Imposta il livello di registro su silent per un numero casuale di richieste, in questo modo:

Nota che, se possibile, è meglio acquisire quanti più dati possibile. In questo modo, non hai informazioni mancanti quando ne hai più bisogno. È inoltre possibile modificare l’espressione ACL in modo che alcune condizioni sovrascrivano la regola.

Un altro modo per limitare il numero di messaggi registrati è impostare option dontlog-normalnel tuo defaultso frontend. In questo modo, vengono catturati solo timeout, tentativi ed errori. Probabilmente non vorresti abilitare questo tutto il tempo, ma solo in determinati momenti, ad esempio quando si eseguono test di benchmarking.

Se si esegue HAProxy all’interno di un contenitore Docker e si utilizza HAProxy versione 1.9, invece di inviare l’output del log a un server Syslog è possibile inviarlo a stdout e/o stderr. Impostare l’indirizzo su stdout o stderr, rispettivamente. In tal caso, è anche preferibile impostare il formato del messaggio su raw, in questo modo:

HAProxy Log Format

Il tipo di registrazione che vedrai è determinato dalla modalità proxy impostata all’interno di HAProxy. HAProxy può funzionare come proxy Layer 4 (TCP) o come proxy Layer 7 (HTTP). La modalità TCP è quella predefinita. In questa modalità, viene stabilita una connessione full duplex tra client e server e non verrà eseguito alcun esame di livello 7. Se hai impostato la configurazione di rsyslog in base alla nostra discussione nella prima sezione, troverai il file di log in / var / log / haproxy-traffic.log.

Quando si è in modalità TCP, che viene impostata aggiungendo mode tcp, si dovrebbe anche aggiungere l’opzione tcplog. Con questa opzione, il formato del registro di default è una struttura che fornisce informazioni utili come i dettagli di connessione del livello 4, i timer,il conteggio dei byte, ecc. Se si dovesse ricreare questo formato usando log-format, che viene utilizzato per impostare un formato personalizzato, sarebbe simile a questo:

Le descrizioni di questi campi possono essere trovate nella documentazione del formato del registro TCP, anche se ne descriveremo diversi nella prossima sezione.

Quando HAProxy viene eseguito come proxy Layer 7 tramitemode http, è necessario aggiungere l’opzione httplog directive. Garantisce che le richieste e le risposte HTTP vengano analizzate in modo approfondito e che nessun contenuto conforme alla RFC non venga catturato. Questa è la modalità che evidenzia davvero il valore diagnostico di HAProxy. Il formato del registro HTTP fornisce lo stesso livello di informazioni del formato TCP, ma con dati aggiuntivi specifici per il protocollo HTTP. Se si dovesse ricreare questo formato usandolog-format, sarebbe simile a questo:

Descrizioni dettagliate dei diversi campi possono essere trovate nella documentazione del formato del registro HTTP.

È anche possibile definire un formato di log personalizzato, catturando solo ciò di cui si ha bisogno. Utilizzare la direttivalog-format (olog-format-sd per il syslog dei dati strutturati) neldefaults ofrontend. Leggi il nostro post sul blog HAProxy Log Customization per saperne di più e vedere alcuni esempi.

Nelle prossime sezioni, acquisirai familiarità con i campi inclusi quando usi option tcplogo option httplog.

Proxy

All’interno del file di log prodotto, ogni riga inizia con il frontend, il backend e il server a cui è stata inviata la richiesta. Ad esempio, se si dispone della seguente configurazione HAProxy, verranno visualizzate le righe che descrivono le richieste come instradate attraverso il frontend http-in al backend statico e quindi al server srv1.

Questa diventa un’informazione vitale quando è necessario sapere dove è stata inviata una richiesta, ad esempio quando si vedono errori che riguardano solo alcuni dei server.

Timer

I timer sono forniti in millisecondi e coprono gli eventi che si verificano durante una sessione. I timer catturati dal formato di log TCP predefinito sono Tw / Tc / Tt. Quelli forniti dal formato di log HTTP predefinito sono TR/ Tw / Tc / Tr / Ta. Questi si traducono come:

Timer	Significato
TR	Il tempo totale per ottenere la richiesta del client (solo in modalità HTTP).
Tw	Il tempo totale trascorso nelle code in attesa di uno slot di connessione.
Tc	Il tempo totale per stabilire la connessione TCP al server.
Tr	Il tempo di risposta del server (solo in modalità HTTP).
Ta	Il tempo attivo totale per la richiesta HTTP (solo modalità HTTP).
Tt	Il tempo totale di durata della sessione TCP, tra il momento in cui il proxy lo ha accettato e il momento in cui entrambe le estremità sono state chiuse.

Troverete una descrizione dettagliata di tutti i timer disponibili nella documentazione HAProxy. Il diagramma seguente mostra anche dove viene registrato il tempo durante una singola transazione end-to-end. Si noti che le linee viola sui bordi indicano i timer.

Stato della sessione alla disconnessione

Entrambi i registri TCP e HTTP includono un codice di stato di terminazione che indica il modo in cui è terminata la sessione TCP o HTTP. E ‘ un codice a due caratteri. Il primo carattere riporta il primo evento che ha causato la chiusura della sessione, mentre il secondo riporta lo stato della sessione TCP o HTTP quando è stato chiuso.

Ecco alcuni esempi di codice di terminazione:

Codice a due caratteri	Significato
–	Terminazione normale su entrambi i lati.
cD	Il client non ha inviato né riconosciuto alcun dato e alla finetimeout client è scaduto.
SC	Il server ha rifiutato esplicitamente la connessione TCP.
PC	Il proxy ha rifiutato di stabilire una connessione al server perché il limite di socket del processo è stato raggiunto durante il tentativo di connessione.

C’è una grande varietà di motivi per cui una connessione potrebbe essere stata chiusa. Informazioni dettagliate su tutti i possibili codici di terminazione possono essere trovate nella documentazione HAProxy.

Contatori

Contatori indicano lo stato del sistema quando una richiesta è passata. HAProxy registra cinque contatori per ogni connessione o richiesta. Possono essere inestimabili nel determinare quanto carico viene posizionato sul sistema, dove il sistema è in ritardo e se i limiti sono stati colpiti. Quando guardi una linea all’interno del registro, vedrai i contatori elencati come cinque numeri separati da barre: 0/0/0/0/0.

In modalità TCP o HTTP, questi si suddividono come:

• Il numero totale di connessioni simultanee sul processo HAProxy quando la sessione è stata registrata.
• Il numero totale di connessioni simultanee instradate attraverso questofrontend quando la sessione è stata registrata.
• Il numero totale di connessioni simultanee instradate a questobackend quando la sessione è stata registrata.
• Il numero totale di connessioni simultanee ancora attive su questoserver quando la sessione è stata registrata.
• Il numero di tentativi tentati quando si tenta di connettersi al server backend.

Altri campi

HAProxy non registra tutto pronto, ma puoi modificarlo per catturare ciò di cui hai bisogno. Un’intestazione di richiesta HTTP può essere registrata aggiungendo la direttivahttp-request capture:

Il registro mostrerà intestazioni tra parentesi graffe e separate da simboli pipe. Qui puoi vedere le intestazioni Host e User-Agent per una richiesta:

Un’intestazione di risposta può essere registrata aggiungendo una direttivahttp-response capture:

In questo caso, è necessario aggiungere anche una direttivadeclare capture response, che alloca uno slot di acquisizione in cui l’intestazione di risposta, una volta arrivata, può essere memorizzata. Ogni slot che si aggiunge viene assegnato automaticamente un ID a partire da zero. Fare riferimento a questo ID quando si chiama http-response capture. Le intestazioni di risposta vengono registrate dopo le intestazioni della richiesta, all’interno di un set separato di parentesi graffe.

I valori dei cookie possono essere registrati in modo simile con la direttivahttp-request capture.

Qualsiasi cosa catturata conhttp-request capture, incluse intestazioni HTTP e cookie, apparirà all’interno dello stesso set di parentesi graffe. Lo stesso vale per qualsiasi cosa catturata con http-response capture.

Puoi anche usare http-request capture per registrare i dati campionati dalle tabelle stick. Se stavi monitorando i tassi di richiesta utente con unstick-table, potresti registrarli in questo modo:

Quindi, fare una richiesta a una pagina Web che contiene il documento HTML e due immagini mostrerebbero il tasso di richiesta concorrente dell’utente che aumenta a tre:

È anche possibile registrare i valori dei metodi di recupero, come ad esempio per registrare la versione di SSL/TLS che è stata utilizzata (si noti che esiste una variabile di registro incorporata per ottenere questo chiamato %sslv):

Le variabili impostate conhttp-request set-var possono anche essere registrate.

Le espressioni ACL valutano true o false. Non è possibile registrarli direttamente, ma è possibile impostare una variabile in base al fatto che l’espressione sia vera. Ad esempio, se l’utente visita /api, è possibile impostare una variabile chiamata req.is_api su un valore di Is API e quindi acquisirla nei log.

Abilitazione HAProxy Profiling

Con il rilascio di HAProxy 1.9, è possibile registrare il tempo di CPU impiegato per l’elaborazione di una richiesta all’interno di HAProxy. Aggiungere il profiling.tasks direttiva per il global sezione:

Ci sono nuove fetch metodi che espongono le metriche per il profiling:

metodo di recupero	Descrizione
date_us	Il microsecondi parte della data.
cpu_calls	Il numero di chiamate all’attività che elabora il flusso o la richiesta corrente da quando è stata allocata. Viene resettato per ogni nuova richiesta sulla stessa connessione.
cpu_ns_avg	Il numero medio di nanosecondi spesi in ogni chiamata all’attività che elabora il flusso o la richiesta corrente.
cpu_ns_tot	Il numero totale di nanosecondi spesi in ogni chiamata all’attività che elabora il flusso o la richiesta corrente.
lat_ns_avg	Il numero medio di nanosecondi trascorsi tra il momento in cui il task che gestisce il flusso viene svegliato e il momento in cui viene effettivamente chiamato.
lat_ns_tot	Il numero totale di nanosecondi tra il momento in cui il task che gestisce il flusso viene svegliato e il momento in cui viene effettivamente chiamato.

Aggiungi questi ai tuoi messaggi di log in questo modo:

Questo è un ottimo modo per valutare quali richieste costano di più da elaborare.

Analisi dei registri HAProxy

Come hai imparato, HAProxy ha molti campi che forniscono un’enorme quantità di informazioni su connessioni e richieste. Tuttavia, leggerli direttamente può portare a sovraccarico di informazioni. Spesso, è più facile analizzarli e aggregarli con strumenti esterni. In questa sezione, vedrai alcuni di questi strumenti e come possono sfruttare le informazioni di registrazione fornite da HAProxy.

HALog

HALog è un piccolo ma potente strumento di analisi dei log fornito con HAProxy. È stato progettato per essere distribuito su server di produzione dove può aiutare con la risoluzione dei problemi manuali, ad esempio quando si affrontano problemi live. È estremamente veloce e in grado di analizzare i registri TCP e HTTP da 1 a 2 GB al secondo. Passando una combinazione di flag, è possibile estrarre informazioni statistiche dai registri, tra cui richieste per URL e richieste per IP di origine. Quindi, è possibile ordinare per tempo di risposta, tasso di errore e codice di terminazione.

Ad esempio, se si desidera estrarre le statistiche per server dai registri, è possibile utilizzare il seguente comando:

Questo è utile quando è necessario analizzare le righe di registro per codice di stato e scoprire rapidamente se un determinato server non è sano (ad esempio restituendo troppe risposte 5xx). Oppure, un server potrebbe negare troppe richieste (risposte 4xx), che è un segno di un attacco a forza bruta. È inoltre possibile ottenere il tempo medio di risposta per server con la colonna avg_rt, utile per la risoluzione dei problemi.

Con HALog, è possibile ottenere statistiche per URL utilizzando il seguente comando:

L’output mostra il numero di richieste, il numero di errori, il tempo di calcolo totale, il tempo medio di calcolo, il tempo totale di calcolo delle richieste riuscite, il tempo medio di calcolo delle richieste riuscite, il numero medio di byte inviati e il numero totale di byte inviati. Oltre all’analisi delle statistiche del server e degli URL, è possibile applicare più filtri per abbinare i registri con un determinato tempo di risposta, codice di stato HTTP, codice di terminazione della sessione, ecc.

HAProxy Stats Page

Analizzare i log con HALog non è l’unico modo per ottenere metriche da HAProxy. La pagina delle statistiche HAProxy può essere abilitata aggiungendo la direttivastats enable a una sezionefrontend olisten. Visualizza le statistiche in tempo reale dei server. La sezione followlisten avvia la pagina delle statistiche in ascolto sulla porta 8404:

La pagina delle statistiche è molto utile per ottenere informazioni istantanee sul traffico che scorre attraverso HAProxy. Tuttavia, non memorizza questi dati e visualizza i dati solo per un singolo bilanciamento del carico.

HAProxy Enterprise Real-Time Dashboard

Se stai utilizzando HAProxy Enterprise, hai accesso al Dashboard in tempo reale. Mentre la pagina Statistiche mostra le statistiche per una singola istanza di HAProxy, il Dashboard in tempo reale aggrega e visualizza le informazioni in un cluster di bilanciatori di carico. In questo modo è facile osservare lo stato di tutti i server da una singola schermata. I dati possono essere visualizzati per un massimo di 30 minuti.

La dashboard memorizza e visualizza informazioni sullo stato del servizio, sulle tariffe delle richieste e sul carico. Rende inoltre più facile eseguire attività amministrative, come abilitare, disabilitare e scaricare i backend. A colpo d’occhio, puoi vedere quali server sono attivi e per quanto tempo. È inoltre possibile visualizzare i dati della tabella stick che, a seconda di ciò che la tabella stick sta monitorando, potrebbero mostrare i tassi di errore, i tassi di richiesta e altre informazioni in tempo reale sugli utenti. Anche i dati della tabella Stick possono essere aggregati.

Il Dashboard in tempo reale è uno dei tanti componenti aggiuntivi disponibili con HAProxy Enterprise.

Conclusione

In questo post del blog, hai imparato come configurare la registrazione HAProxy per ottenere osservabilità sul tuo load balancer, che è un componente critico all’interno della tua infrastruttura. HAProxy emette messaggi Syslog dettagliati quando si opera in modalità TCP e HTTP. Questi possono essere inviati a una serie di strumenti di registrazione, come rsyslog.

HAProxy viene fornito con l’utilità della riga di comando HALog, che semplifica l’analisi dei dati di registro quando sono necessarie informazioni sui tipi di risposte che gli utenti ricevono e sul carico sui server. È inoltre possibile ottenere una visuale dello stato dei server utilizzando la pagina Statistiche HAProxy o la dashboard in tempo reale HAProxy Enterprise.

Vuoi sapere quando vengono pubblicati contenuti come questo? Iscriviti a questo blog o seguici su Twitter. È inoltre possibile partecipare alla conversazione su Slack! HAProxy Enterprise combina HAProxy con funzionalità di classe enterprise, come il dashboard in tempo reale e il supporto premium. Contattaci per saperne di più o iscriviti per una prova gratuita oggi!