Logging With NGINX-How To Configure It and What to Watch Out For

NGINX is een krachtige en betrouwbare webserver die in staat is om grote hoeveelheden verkeer voor de drukste websites van het internet af te handelen. Bij het oplossen van problemen hebt u een manier nodig om het verkeer te begrijpen en NGINX biedt flexibele logfuncties om waardevolle details vast te leggen en u te helpen het gedrag van uw webserver te begrijpen.

NGINX biedt twee verschillende bestanden voor het loggen van waardevolle webservergegevens., Deze twee bestanden zijn error_log en access_log. access_log wordt gebruikt voor het opslaan van informatie over webclient requestsand error_log slaat andere onverwachte of informatieve berichten.

access_log configureren

het access_log bestand verzamelt alle clientaanvragen onmiddellijk nadat het verzoek is verwerkt, wat een geweldige manier is om te loggen welke pagina ‘ s gebruikers opvragen van uw webserver., U kunt kiezen waar de acess_log-gegevens naar geschreven worden met behulp van de volgende syntaxis van het configuratiebestand:

access_log path ] ];access_log off;

Specificingformat stelt u in staat om een aangepast formaat in uw logs te gebruiken met behulp van variabelen zoals het aantal bytessent voor de client ($bytes_sent) of de request length ($request_length).

Normaal zal NGINX elke transactie loggen die het verwerkt in access_log. De if = condition parameter biedt een krachtige manier om conditionele logging uit te voeren, zodat het alleen log toegang log berichten opslaat als een voorwaarde Waar is., Als u bijvoorbeeld alleen verzoeken wilt opnemen die een HTTP 404-statuscode retourneren, kunt u het volgende fragment gebruiken:

map $status $should_log {404 1;default 0;}access_log logs/access.log combined if=$should_log;

Met deze wijziging worden alle aanvragen die succesvol zijn voltooid (2xx), doorgestuurd naar een andere pagina (3xx) of een servererror (5xx) tegengekomen, niet ingelogd in logs/access.log-only404 fouten zullen worden gelogd.

als u meer dan één virtuele host of meerdere http -, server-of locatierichtlijnen hebt, is het soms handig om in staat te zijn om loggen uit te schakelen op het huidige directief-niveau, en de speciale Uit-waarde is hiervoor gemaakt.,De volgende configuratieregel laat zien hoe u kunt voorkomen dat NGINX toegangs-informatie schrijft naar een access_log-doel op het huidige niveau:

access_log off;

voor een uitgebreidere uitleg van de configuratieopties, bekijk de Nginx access_log-documentatie.

Nginx Log Ernstniveaus

NGINX ondersteunt een breed scala aan ernstniveaus om het gemakkelijk te maken om de informatie waar u om geeft te loggen. Elk van deze niveaus kan worden gebruikt met de error_log directivom het minimumniveau in te stellen waarop berichten worden gelogd., Hier zijn de ondersteunde niveaus in de laagste tot hoogste volgorde, samen met een gids over hoe ze worden gebruikt:

  • Debug – Debugging berichten die meestal niet nuttig zijn.
  • Info-informatieve berichten die goed zijn om te weten.
  • Notice-er gebeurde iets normaals maar betekenisvols en het moet worden opgemerkt.
  • Warn-er is iets onverwachts gebeurd, maar het is geen reden tot bezorgdheid.
  • fout-iets is mislukt.
  • Crit-een kritieke toestand trad op.
  • Alert-onmiddellijke actie is vereist.
  • Emerg-het systeem is onbruikbaar.,

configureren error_log

standaard legt het error_log-bestand alle logberichten vast op het niveau van de ernst van de fout, wat betekent dat het voornamelijk wordt gebruikt voor het begrijpen van fatale of kritieke berichten om problemen op te lossen. De standaardlocatie voor error_logis logs/error.log. De manier waarop nginxstores foutmeldingen is flexibel en—samen met het toestaan van het schrijven van berichten naar een bestand-het ondersteunt ook het verzenden van error_logmessages naar stderr of de syslog daemon. Als je nginxopen source 1.5 draait.,2 of nieuwer, u kunt error_log berichten ook naar meer dan één plaats tegelijk verzenden door meerdere error_log richtlijnen op hetzelfde configuratieniveau op te geven.

Als u alle berichten wilt loggen op of boven de ernst van het waarschuwingslogboek, moet u de volgende configuratie wijzigen:

error_log logs/error.log warn;

loggen naar Syslog met NGINX

zowel de access_log-als error_log-richtlijnen ondersteunen het verzenden van berichten naar een syslog-daemon met behulp van de syslog: – string in uw configuratie., De volgende code ziet u de syntaxis voor het gebruik van een van de richtlijnen met een syslog daemon:

http {error_log syslog:server;…}

bijvoorbeeld, als u wilt direct alle error_log berichten met een waarschuwing of een hogere ernst van de syslogdaemon gebruik deze richtlijn regel:

error_log syslog:server=192.168.1.1 severity=warn;

U verder kunt aanpassen de syslogconfiguration aan uw omgeving door het gebruik van de syslog-parameter describedin de NGINXsyslog documentatie.

Frustratievrij logbeheer. (Het is een ding.,)

uw logs samenvoegen, organiseren en beheren met Papertrail

dingen om op te letten voor

de flexibiliteit die Nginx logging biedt, komt met een kostprijs, en er zijn een aantal dingen om op te letten bij het schrijven van uw configuratiebestand. We hebben al behandeld Nginx ‘ s vermogen om logging configuraties overschrijven op het niveau van de richtlijn, en deze functie is uiterst nuttig voor hetlogging extra informatie wanneer gebruikers toegang krijgen tot specifieke paden, bijvoorbeeld logging extra verkeersinformatie voor alle gebruikers toegang tot de /privé URI., Echter, het gebruik van geneste toegang logs kan snel wordencomplex en je moet voorzichtig zijn om deze functie niet te veel te gebruiken.

het schrijven van access_logentries naar een bestand op schijf kan de prestaties van de server degraderen en de latentie van de response voor verzoeken van gebruikers verhogen. Voor webservers die hoge prestaties moeten behouden, biedt NGINX een manier om logberichten naar een cyclische buffer inmemory te schrijven, waarbij de schijf volledig wordt omzeild. Het extraheren van deze logs is meer betrokken dan het lezen van een bestand, dus je moet dit alleen gebruiken als de prestaties van cruciaal belang zijn voor je werklast.,

om deze functie te gebruiken, moet uw versie van NGINX worden geconfigureerd met de optie—with-debug. U kunt controleren of dit het geval is door dit te doen:

$ nginx -V 2>&1 | grep—‘—with-debug’configure arguments: --with-debug

in het configuratiebestand kunt u het schrijven van logboekvermeldingen naar het geheugen inschakelen met het volgende fragment:

error_log memory:32m debug;...http {...}

Dit schrijft alle logberichten op debugniveau. Het extraheren van de logberichten uit het geheugen impliceert het gebruik van gdb om verbinding te maken met het Nginx-proces en het volgende script kopiëren en plakken achter de prompt:

set $log = ngx_cycle->logwhile $log->writer != ngx_log_memory_writerset $log = $log->nextendset $buf = (ngx_log_memory_buf_t *) $log->wdatadump binary memory debug_log.txt $buf->start $buf->end

en GDB afsluiten met Ctrl-D., Het bovenstaande scriptzal de inhoud van het geheugen naar de debug_log schrijven.txtfile waar je het als normaal kunt lezen.

conclusie

NGINX stelt u in staat om logs voor Bo-through toegangen en onverwachte fouten te verzamelen in afzonderlijke bestanden voor latere analyse en het oplossen van problemen. Het formaat van het access_logbestand kan uitgebreid worden aangepast om gedetailleerde informatie te bevatten over verzoeken, zoals het aantal bytes dat naar de client is verzonden of de lengte van de aanvraag,en de error_log-richtlijn staat je toe om het minimale ernstniveau te bepalen dat nodig is om berichten te registreren.,Zowel de access_log-als error_log-richtlijnen kunnen logentries verzenden naar een syslog-daemon, wat zeer handig kan zijn voor ontwikkelaars die werken met meerdere webservers.

en als al deze functies niet genoeg zijn voor u, kunt u error_logentries zelfs naar een geheugenbuffer schrijven om schrijven naar schijf te voorkomen en de performanceimpact voor drukke servers te verminderen.

Leave a Comment