Access Log
server access log registrerer alle anmodninger behandlet af serveren. Placeringen og indholdet af adgangsloggen kontrolleres afCustomLog
direktivet. LogFormat
direktivet kan bruges til at forenkle valget af indholdet af logfilerne. Dette afsnit beskriver, hvordan du konfigurerer serveren til at registrere oplysninger i adgangsloggen.
lagring af oplysningerne i adgangsloggen er naturligvis kun starten på logadministrationen., Det næste trin er at analysere disse oplysninger for at producere nyttige statistikker. Log analyse generelt er uden for rammerne af dette dokument, og ikke rigtig en del af jobbet af webebserveren selv. For mere information om dette emne, og for applikationer, der udfører log analyse, tjek Open Directory.
Forskellige versioner af Apache httpd har brugt andre moduler og direktiver for at kontrollere adgangen skovhugst, herunder mod_log_referer, mod_log_agent, og TransferLog
direktiv., CustomLog
direktivet indeholder nu funktionaliteten i alle de ældre direktiver.
formatet af adgangsloggen er meget konfigurerbar. Formatet er angivet ved hjælp af et format streng, der ligner meget en C-stil printf(1) format streng. Nogle eksempler er præsenteret i de næste afsnit. For en komplet liste over det mulige indhold af formatstrengen, se mod_log_config
formatstrenge.
almindeligt logformat
en typisk konfiguration for adgangsloggen kan se ud som følger.,
LogFormat "%h %l %u %t \"%r\" %>s %b" commonCustomLog logs/access_log common
Dette definerer kaldenavn common
og forbinder det med en særlig log format-streng. Formatstrengen består af procentdirektiver, som hver fortæller serveren at logge et bestemt stykke information. Bogstavelige tegn kan også placeres i formatstrengen og kopieres direkte ind i logudgangen. Citattegnet ("
) skal undgås ved at placere et tilbageslag før det for at forhindre, at det fortolkes som slutningen af formatstrengen., Formatstrengen kan også indeholde de specielle kontroltegn ” \n
” for ny linje og “\t
” for fanen.
CustomLog
direktivet opretter en ny logfil ved hjælp af det definerede kaldenavn. Filnavnet for adgangsloggen er i forhold til ServerRoot
medmindre det begynder med en skråstreg.
ovenstående konfiguration vil skrive logposter i et format kendt som Common Log Format (CLF). Dette standardformat kan produceres af mange forskellige webebservere og læses af mange loganalyseprogrammer., Logfilindtastningerne produceret i CLF vil se sådan ud:
127.0.0.1 - frank "GET /apache_pb.gif HTTP/1.0" 200 2326
hver del af denne logindgang er beskrevet nedenfor.
127.0.0.1
(%h
) dette er IP-adressen på klienten (ekstern vært), der fremsatte anmodningen til serveren. HvisHostnameLookups
er indstillet tilOn
, vil serveren forsøge at bestemme værtsnavnet og logge det i stedet for IP-adressen. Denne konfiguration anbefales dog ikke, da den kan bremse serveren markant., I stedet er det bedst at bruge en log post-processor somlogresolve
til at bestemme værtsnavne. Den her rapporterede IP-adresse er ikke nødvendigvis adressen på den maskine, hvor brugeren sidder. Hvis der findes en pro .yserver mellem brugeren og serveren, vil denne adresse være adressen på pro .yen snarere end den oprindelige maskine.-
(%l
) “bindestreg” i output angiver, at det ønskede stykke information ikke er tilgængeligt., I dette tilfælde er de oplysninger, der ikke er tilgængelige, klientens RFC 1413 identitet bestemt afidentd
på klientens maskine. Disse oplysninger er meget upålidelige og bør næsten aldrig bruges undtagen på tæt kontrollerede interne netværk. Apache httpd vil ikke engang forsøge at bestemme disse oplysninger, medmindreIdentityCheck
er indstillet tilOn
.frank
(%u
) dette er brugeridet for den person, der anmoder om dokumentet, bestemt ved HTTP-godkendelse., Den samme værdi leveres typisk til CGI-scripts iREMOTE_USER
miljøvariablen. Hvis statuskoden for anmodningen (se nedenfor) er 401, skal denne værdi ikke stole på, fordi brugeren endnu ikke er godkendt. Hvis dokumentet ikke er beskyttet med adgangskode, vil denne del være “-
” ligesom den forrige.(
%t
) det tidspunkt, hvor anmodningen blev modtaget., Formatet er:
Det er muligt at have den tid, der vises i et andet format ved at angive %{format}t
i log-format string, hvor format
enten som i strftime(3)
fra C standard-bibliotek, eller en af de understøttede særlige tokens. For detaljer se mod_log_config
formatstrenge.
"GET /apache_pb.gif HTTP/1.0"
(\"%r\"
) anmodningslinjen fra klienten er angivet i dobbelt citater. Forespørgselslinjen indeholder en masse nyttige oplysninger., For det første er den metode, som klienten brugerGET
. For det andet anmodede klienten ressourcen/apache_pb.gif
, og for det tredje brugte klienten protokollenHTTP/1.0
. Det er også muligt at logge en eller flere dele af anmodningslinjen uafhængigt. For eksempel vil formatstrengen “%m %U%q %H
” logge metoden, stien, forespørgselsstrengen og protokollen, hvilket resulterer i nøjagtigt det samme output som “%r
“.200
(%>s
) dette er den statuskode, som serveren sender tilbage til klienten., Denne information er meget værdifuld, fordi den afslører, om anmodningen resulteret i en vellykket reaktion (koder, der begynder i 2), en omdirigering (koder, der begynder i 3), en fejl, der er forårsaget af kunden (koder, der begynder i 4), eller en fejl på serveren (koder, der begynder i 5). Den fulde liste over mulige statuskoder findes i HTTP-specifikationen (RFC2616 afsnit 10).
2326
(%b
) den sidste del angiver størrelsen på objektet, der returneres til klienten, ikke inklusive svaroverskrifterne., Hvis der ikke blev returneret noget indhold til klienten, vil denne værdi være “-
“. For at logge “0
” uden indhold, skal du bruge%B
i stedet for.
kombineret logformat
en anden almindeligt anvendt formatstreng kaldes det kombinerede logformat. Det kan bruges som følger.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combinedCustomLog log/access_log combined
dette format er nøjagtigt det samme som det almindelige logformat med tilføjelse af yderligere to felter. Hvert af de yderligere felter bruger procentdirektivet %{header}i
, hvor overskriften kan være en hvilken som helst http-anmodningsoverskrift., Access-log under dette format vil se ud som dette:
De yderligere felter, der er:
"http://www.example.com/start.html"
(\"%{Referer}i\"
), “Henvisnings” (sic) HTTP request headeren. Dette giver det siteebsted, som klienten rapporterer at være blevet henvist fra. (Dette skal være den side, der linker til eller indeholder/apache_pb.gif
)."Mozilla/4.08 (Win98; I ;Nav)"
(\"%{User-agent}i\"
) http-anmodningsoverskriften til brugeragent. Dette er de identificerende oplysninger, som klientbro .seren rapporterer om sig selv.,
flere adgangslogfiler
flere adgangslogfiler kan oprettes ved blot at angive flereCustomLog
direktiver i konfigurationsfilen. For eksempel opretter følgende direktiver tre adgangslogfiler. Den første indeholder de grundlæggende CLF-oplysninger, mens den anden og tredje indeholder referer-og bro .seroplysninger. De sidste to CustomLog
linjer viser, hvordan du efterligne virkningerne af ReferLog
og AgentLog
direktiver.,
dette eksempel viser også, at det ikke er nødvendigt at definere et kaldenavn med LogFormat
direktiv. I stedet kan logformatet specificeres direkte iCustomLog
direktiv.
betingede Logs
Der er tidspunkter, hvor det er praktisk at udelukke visse poster fra adgangslogfilerne baseret på karakteristika for klientanmodningen. Dette opnås let ved hjælp af miljøvariabler. For det første skal der indstilles en miljøvariabel for at indikere, at anmodningen opfylder visse betingelser., Dette opnås normalt med SetEnvIf
. Derefter bruges env=
– klausulen i CustomLog
til at inkludere eller ekskludere anmodninger, hvor miljøvariablen er indstillet. Nogle eksempler:
som et andet eksempel kan du overveje at logge anmodninger fra engelsktalende til en logfil og ikke-engelsktalende til en anden logfil.
SetEnvIf Accept-Language "en" englishCustomLog logs/english_log common env=englishCustomLog logs/non_english_log common env=!english
i et caching-scenarie vil man gerne vide om effektiviteten af cachen., En meget enkel metode til at finde ud af dette, ville være:
SetEnv CACHE_MISS 1LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cacheCustomLog logs/access_log common-cache
mod_cache
vil køre, før mod_env
og, når det lykkes, vil levere indholdet uden at være det. I så fald vil et cache hit logge -
, mens en cache miss vil logge 1
.,
ud over det env=
syntaks, LogFormat
understøtter logge værdier betinget af HTTP-response-kode:
LogFormat "%400,501{User-agent}i" browserlogLogFormat "%!200,304,302{Referer}i" refererlog
I det første eksempel, User-agent
vil blive logget, hvis HTTP-statuskoden er 400 eller 501. I andre tilfælde vil en bogstavelig “-” blive logget i stedet. Ligeledes i det andet eksempel vil Referer
blive logget, hvis http-statuskoden ikke er 200, 204 eller 302. (Bemærk “!”før statuskoderne . ,
selvom vi netop har vist, at betinget logning er meget kraftfuld og fleksibel, er det ikke den eneste måde at kontrollere indholdet af logfilerne på. Logfiler er mere nyttige, når de indeholder en komplet registrering af serveraktivitet. Det er ofte lettere at blot efterbehandle logfilerne for at fjerne anmodninger, som du ikke ønsker at overveje.