NGINX Tilgang til Loggene og feillogger

Loggene er svært nyttig for å overvåke aktivitetene til et program bortsett fra å gi deg verdifull informasjon mens du feilsøker det.

Som alle andre program, NGINX også registrerer hendelser som besøkende til nettstedet ditt, problemer det støtt og mer til loggfiler. Denne informasjonen gjør det mulig for deg å ta preemptive tiltak i tilfelle du merker noen alvorlige avvik i loggen hendelser.,

Denne artikkelen vil veilede deg i detaljer om hvordan du konfigurerer NGINX logging slik at du har en bedre innsikt i sin virksomhet.

Forutsetning

  • Du har allerede installert NGINX ved å følge vår tutorial her.

Logger i NGINX

som standard, NGINX skriver sine arrangementer i to typer logger – feilloggen og få tilgang til loggen., I de fleste av de populære Linux-distro som Ubuntu, CentOS eller Debian, både tilgang og feilloggen som kan bli funnet i /var/log/nginx, forutsatt at du allerede har aktivert tilgang og feillogger i kjernen NGINX konfigurasjonsfilen.

La oss finne ut mer om NGINX logg, feillogg og hvordan å gjøre dem i stand hvis du ikke har gjort det tidligere.

Hva er NGINX logg?

NGINX logger aktiviteter av alle besøkende til nettstedet ditt i tilgang til loggene., Her kan du finne hvilke filer som er tilgjengelige, hvordan NGINX svarte på en forespørsel, og hva leseren en klient bruker, IP-adressen til klienter og mer. Det er mulig å bruke informasjon fra logg til å analysere trafikken til å finne nettsteder bruksområder over tid. Videre, ved å overvåke tilgang til loggene på riktig måte, kan man finne ut om en bruker sender noen uvanlige forespørselen for å finne feil i utfelt web-applikasjon.

Hva er NGINX feilloggen?

På den annen side, hvis NGINX ansikter noen glitches deretter vil det ta opp arrangementet til feilloggen., Dette kan skje hvis det er noen feil i konfigurasjonsfilen. Derfor, hvis NGINX er i stand til å starte eller brått stoppet da bør du sjekke feilen logger for å finne mer informasjon. Du kan også finne noen advarsler i feilloggen men det betyr ikke at det har oppstått et problem, men hendelsen kan utgjøre et alvorlig problem i nær fremtid.

Hvordan for å aktivere NGINX logg?

generelt, logg kan aktiveres med access_log direktiv enten http eller i server-delen., Det første argumentet log_file er obligatorisk, mens det andre argumentet log_format er valgfritt. Hvis du ikke angir hvilket som helst format deretter logger vil bli skrevet i standard kombinert format.

access_log log_file log_format;

logg er aktivert som standard på http sammenheng med core NGINX konfigurasjonsfilen. Det betyr få tilgang til logg over alle virtuelle verten vil bli tatt opp i den samme filen.

http { ... ... access_log /var/log/nginx/access.log; ... ...}

Det er alltid bedre å skille tilgang til loggene for alle virtuelle verter ved å lagre dem i en egen fil., For å gjøre det, må du overstyre access_log direktiv som er definert i http-delen med en annen access_log direktiv i server-sammenheng.

last inn på nytt NGINX å bruke de nye innstillingene. For å vise tilgang til loggene for domenet domain1.com i filen /var/log/nginx/domain1.access.log bruk følgende halen kommandoen i terminalen.

# tail -f /var/log/nginx/domain1.access.log

Bruke Tilpassede Format i Logg på

standard logg format som brukes til å registrere en hendelse i logg er kombinert log-format., Du kan overstyre standard oppførsel ved å lage dine egne log-format og deretter angir du navnet på det egendefinerte formatet i access_log direktivet.

følgende eksempel definerer en tilpasset log-format ved å utvide den forhåndsdefinerte kombinert format med verdien av gzip kompresjon forholdet på svar. Formatet er deretter brukt som indikerer log-format med access_log direktiv.

Når du har brukt ovenfor log-format i miljøet, laste NGINX. Nå hale tilgang til loggen for å finne gzip-forhold på slutten av loggen event.,

Hvordan for å aktivere NGINX feilloggen?

error_log direktivet setter opp feil logging til fil eller stderr, eller syslog ved å angi minimal alvorlighetsgraden av feilmeldinger være innlogget. Syntaksen for error_log direktivet er:

error_log log_file log_level;

Det første argumentet log_file definerer banen i loggfilen, og det andre argumentet log_level definerer alvorlighetsgraden av loggoppføring for å bli tatt opp. Hvis du ikke angi log_level standard logger hendelser med alvorlighetsgrad av feil er registrert.,

For eksempel, følgende eksempel angir alvorlighetsgrad av feilmeldinger være innlogget for å crit. Videre error_log direktivet i http-sammenheng innebærer at feil logg for alle virtuelle verten vil være tilgjengelig i en enkelt fil.

http { ... error_log /var/log/nginx/error_log crit; ...}

Det er også mulig å ta opp feil-logger for alle virtuelle verten separat av tvingende den error_log direktivet i server-sammenheng. Følgende eksempel gjør nøyaktig som av tvingende error_log direktivet i server-sammenheng.,

Alle eksemplene som er beskrevet ovenfor registrerer logge hendelser til en fil. Du kan også konfigurere error_log direktiv for å sende logger hendelser til en syslog server. Følgende error_log direktiv sender feil-logger til syslog server med en IP-adresse av 192.168.10.11 i debug-format.

error_log syslog:server=192.168.10.11 debug;

I noen situasjon, vil du kanskje deaktivere feilloggen. For å gjøre det, sett logg-fil til /dev/null.,

error_log /dev/null;

Nginx Feil Logg Alvorlighetsgrad

Det er mange typer log-nivåer som er forbundet med en loggoppføring, og med en annen prioritet. Alle logger nivåer er listet opp nedenfor. I det følgende logg nivåer, debug har topp prioritet, og omfatter resten av nivåer også. For eksempel, hvis du angir feil som en logg nivå, så vil det også ta logg hendelser de som er merket som kritisk, varsling og beredskap.

  1. emerg: nødmeldinger når systemet er ustabilt.
  2. varsling: Varsling meldinger om alvorlige saker.,
  3. crit: Kritiske spørsmål som må tas hånd om umiddelbart.
  4. feilmelding: En feil har oppstått. Noe gikk feil under behandling av en side.
  5. advare: En advarsel meldinger som du bør se på det.
  6. merknad: En enkel logg legg merke til at du kan ignorere.
  7. info: Bare en informasjon som du kanskje ønsker å vite.
  8. debug: Feilsøking-informasjon som brukes til å fastslå plasseringen av feil.,

Oppsummering

for å få tilgang til og feillogger i NGINX vil ikke bare holde en fane på brukerne aktivitet, men også sparer din tid og innsats i prosessen med debugging. Videre, du kan også tilpasse logg hvis du trenger mer informasjon til din disposisjon. Det er alltid bedre å aktivere tilgang og feillogger fordi disse to filene inneholder alle ledetråder for bedre vedlikehold av NGINX server.

Share

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *