Access Log

server access log zaznamenává všechny požadavky zpracované serverem. Umístění a obsah přístupového protokolu jsou řízeny směrnicí CustomLog. Pro zjednodušení výběru obsahu protokolů lze použít směrnici LogFormat. Tato část popisuje, jak nakonfigurovat server tak, aby zaznamenával informace v protokolu přístupu.

ukládání informací do přístupového protokolu je samozřejmě pouze začátkem správy protokolu., Dalším krokem je analyzovat tyto informace a vytvořit užitečné statistiky. Analýza protokolu obecně přesahuje rámec tohoto dokumentu a není skutečně součástí úlohy samotného webového serveru. Pro více informací o tomto tématu a pro aplikace, které provádějí analýzu protokolu, zkontrolujte otevřený adresář.

Různé verze Apache httpd používají jiné moduly a směrnic pro řízení přístupu protokolování, včetně mod_log_referer, mod_log_agent, a TransferLog směrnice., Směrnice CustomLog nyní nahrazuje funkčnost všech starších směrnic.

formát přístupového protokolu je vysoce konfigurovatelný. Formát je zadán pomocí řetězce formátu, který vypadá podobně jako řetězec formátu printf(1) ve stylu C. Některé příklady jsou uvedeny v následujících částech. Úplný seznam možného obsahu řetězce formátu naleznete v řetězcích formátumod_log_config.

běžný formát protokolu

typická konfigurace protokolu přístupu může vypadat následovně.,

LogFormat "%h %l %u %t \"%r\" %>s %b" commonCustomLog logs/access_log common

Toto definuje přezdívku common a spojuje ji s konkrétním řetězcem formátu protokolu. Formátovací řetězec se skládá z procent směrnic, z nichž každá se říct, že server log konkrétní informaci. Doslovné znaky mohou být také umístěny do řetězce formátu a budou zkopírovány přímo do výstupu protokolu. Citát znak (") musí být unikl umístěním zpětného lomítka před tím, než zabránit tomu, aby byl interpretován jako konec řetězce formátu., Formátovací řetězec může také obsahovat speciální ovládací znaky“\n „pro nový řádek a“\t “ pro kartu.

směrniceCustomLog nastavuje nový soubor protokolu pomocí definované Přezdívky. Název souboru pro protokol přístupu je relativní k ServerRoot, pokud nezačíná lomítkem.

výše uvedená konfigurace zapíše položky protokolu ve formátu známém jako Common Log Format (CLF). Tento standardní formát může být produkován mnoha různými webovými servery a čten mnoha programy analýzy protokolu., Položky souboru protokolu, vyrobené v CLF bude vypadat nějak takhle:

Každá část tohoto deníku je popsán níže.

127.0.0.1(%h) Toto je IP adresa klienta (remote host) který podal žádost na server. Pokud jeHostnameLookupsnastavena naOn, server se pokusí určit název hostitele a přihlásit jej místo IP adresy. Tato konfigurace se však nedoporučuje, protože může server výrazně zpomalit., Místo toho je nejlepší použít postprocesor protokolu, jako jelogresolvek určení názvů hostitelů. Zde uvedená IP adresa nemusí být nutně adresou stroje, na kterém uživatel sedí. Pokud existuje proxy server mezi uživatelem a serverem, bude tato adresa spíše adresou proxy než původním strojem.-(%l) „pomlčka“ v výstup označuje, že požadovaná informace není k dispozici., V tomto případě, informace, které nejsou k dispozici, je RFC 1413 totožnosti klienta určujeidentdna klienty stroj. Tyto informace jsou vysoce nespolehlivé a téměř nikdy by neměly být používány s výjimkou přísně kontrolovaných interních sítí. Apache httpd se ani nesnaží zjistit tyto informace, pokudIdentityCheckje nastavena naOn.frank(%u) toto je userid osoby požadující dokument podle ověření HTTP., Stejná hodnota je obvykle poskytována skriptům CGI v proměnné prostředíREMOTE_USER. Pokud je stavový kód požadavku (viz níže) 401, pak by tato hodnota neměla být důvěryhodná, protože uživatel ještě není ověřen. Pokud dokument není chráněn heslem, bude tato část „-“ stejně jako předchozí.(%t) čas, kdy byla žádost přijata., Formát je:

je možné mít čas zobrazen v jiném formátu zadáním %{format}t v protokolu, formátu string, kde format je buď jako v strftime(3) z C, standardní knihovny, nebo jeden z podporovaných speciální žetony. Podrobnosti naleznete v řetězcích formátumod_log_config.

"GET /apache_pb.gif HTTP/1.0"(\"%r\") řádek požadavku od klienta je uveden ve dvojitých uvozovkách. Linka požadavků obsahuje velké množství užitečných informací., Za prvé, metoda používaná klientem jeGET. Za druhé klient požádal o zdroj/apache_pb.gifa za třetí klient použil protokolHTTP/1.0. Je také možné samostatně přihlásit jednu nebo více částí linky požadavku. Například formátovací řetězec „%m %U%q %H“ přihlásit metoda, cesta, dotaz-string, a protokol, což v přesně stejný výstup jako „%r„.200(%>s) jedná se o stavový kód, který server odešle zpět klientovi., Tato informace je velmi cenná, protože ukazuje, zda žádost vyústila v úspěšné reakce (kódy začínající v 2), přesměrování (kódy začátek v 3), chyba způsobená klientem (kódy začínající v 4), nebo chyba v serveru (kódy začátek v 5). Úplný seznam možných stavových kódů naleznete ve specifikaci HTTP (sekce RFC2616 10).

2326(%b) poslední část označuje velikost objektu vráceného klientovi, bez záhlaví odezvy., Pokud nebyl klientovi vrácen žádný obsah, bude tato hodnota „-„. Chcete-li přihlásit „0“ bez obsahu, použijte%Bmísto toho.

kombinovaný formát protokolu

další běžně používaný formátový řetězec se nazývá kombinovaný formát protokolu. Může být použit následovně.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combinedCustomLog log/access_log combined

tento formát je přesně stejný jako běžný formát protokolu s přidáním dalších dvou polí. Každé z dalších polí používá procentuální směrnici %{header}i, kde záhlaví může být libovolné záhlaví požadavku HTTP., Access log pod tento formát bude vypadat takto:

další pole jsou:

"http://www.example.com/start.html"(\"%{Referer}i\") „Referer“ (sic) HTTP hlavičky požadavku. To dává stránky, které klient hlásí, které byly odkázány. (To by měla být stránka, která odkazuje na nebo obsahuje/apache_pb.gif)."Mozilla/4.08 (Win98; I ;Nav)"(\"%{User-agent}i\") záhlaví požadavku HTTP uživatele-agenta. Toto jsou identifikační informace, které o sobě klientský prohlížeč hlásí.,

více přístupových protokolů

více přístupových protokolů lze vytvořit jednoduše zadáním víceCustomLog směrnic v konfiguračním souboru. Například následující směrnice vytvoří tři přístupové protokoly. První obsahuje základní informace CLF, zatímco druhá a třetí obsahují informace o refereru a prohlížeči. Poslední dva CustomLog řádky ukazují, jak napodobují účinky ReferLog AgentLog směrnic.,

tento příklad také ukazuje, že není nutné definovat přezdívku pomocí směrnice LogFormat. Místo toho lze formát protokolu zadat přímo ve směrnici CustomLog.

podmíněné protokoly

existují chvíle, kdy je vhodné vyloučit určité položky z přístupových protokolů na základě charakteristik požadavku klienta. Toho lze snadno dosáhnout pomocí proměnných prostředí. Nejprve musí být nastavena proměnná prostředí, která udává, že žádost splňuje určité podmínky., To se obvykle provádí pomocí SetEnvIf. Poté se klauzuleenv=CustomLog použije k zahrnutí nebo vyloučení požadavků, kde je nastavena proměnná prostředí. Některé příklady:

jako další příklad zvažte protokolování požadavků z anglických reproduktorů do jednoho souboru protokolu a neanglických reproduktorů do jiného souboru protokolu.

SetEnvIf Accept-Language "en" englishCustomLog logs/english_log common env=englishCustomLog logs/non_english_log common env=!english

ve scénáři ukládání do mezipaměti byste chtěli vědět o účinnosti mezipaměti., Velmi jednoduchý způsob, jak to zjistit, by bylo:

SetEnv CACHE_MISS 1LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cacheCustomLog logs/access_log common-cache

mod_cache poběží před mod_env a, pokud bude úspěšný, bude dodávat obsah, aniž by to. V takovém případě se stisk cache přihlásí -, zatímco cache miss se přihlásí 1.,

vedle env= syntaxe, LogFormat podporuje logování hodnot podmíněno kód odpovědi HTTP:

LogFormat "%400,501{User-agent}i" browserlogLogFormat "%!200,304,302{Referer}i" refererlog

V prvním příkladu, User-agent budou zaznamenány, pokud stavový kód HTTP 400 nebo 501. V ostatních případech bude místo toho zaznamenán doslovný“ -„. Podobně ve druhém příkladu budeReferer zaznamenáno, pokud stavový kód HTTP Není 200, 204 nebo 302. (Všimněte si „!“před stavovými kódy.,

přestože jsme právě ukázali, že podmíněné protokolování je velmi silné a flexibilní, není to jediný způsob, jak kontrolovat obsah protokolů. Soubory protokolu jsou užitečnější, pokud obsahují úplný záznam o činnosti serveru. Často je snazší jednoduše zpracovat soubory protokolu a odstranit požadavky, které nechcete zvážit.