Log di accesso
Il log di accesso del server registra tutte le richieste elaborate dal server. La posizione e il contenuto del log di accesso sono controllati dalla direttivaCustomLog
. La direttivaLogFormat
può essere utilizzata per semplificare la selezione dei contenuti dei log. Questa sezione descrive come configurare il server per registrare le informazioni nel registro di accesso.
Naturalmente, la memorizzazione delle informazioni nel log di accesso è solo l’inizio della gestione dei log., Il prossimo passo è analizzare queste informazioni per produrre statistiche utili. L’analisi dei log in generale va oltre lo scopo di questo documento e non fa realmente parte del lavoro del server Web stesso. Per ulteriori informazioni su questo argomento e per le applicazioni che eseguono l’analisi dei log, controllare la directory aperta.
Varie versioni di Apache httpd hanno utilizzato altri moduli e direttive per controllare la registrazione degli accessi, tra cui mod_log_referer, mod_log_agent e la direttivaTransferLog
., La direttivaCustomLog
ora sussume la funzionalità di tutte le direttive precedenti.
Il formato del log di accesso è altamente configurabile. Il formato viene specificato utilizzando una stringa di formato che assomiglia molto a una stringa di formato printf(1) in stile C. Alcuni esempi sono presentati nelle prossime sezioni. Per un elenco completo dei possibili contenuti della stringa di formato, vedere le stringhe di formatomod_log_config
.
Formato di log comune
Una configurazione tipica per il log di accesso potrebbe essere la seguente.,
LogFormat "%h %l %u %t \"%r\" %>s %b" commonCustomLog logs/access_log common
Questo definisce il nickname common
e lo associa a una particolare stringa di formato di log. La stringa di formato è costituita da direttive percentuali, ognuna delle quali indica al server di registrare una particolare informazione. I caratteri letterali possono anche essere inseriti nella stringa di formato e verranno copiati direttamente nell’output del log. Il carattere di citazione ("
) deve essere sfuggito posizionando una barra rovesciata prima di esso per evitare che venga interpretato come la fine della stringa di formato., La stringa di formato può anche contenere i caratteri di controllo speciali “\n
“per new-line e”\t
” per tab.
La direttiva CustomLog
imposta un nuovo file di registro utilizzando il nickname definito. Il nome del file per il log di accesso è relativo a ServerRoot
a meno che non inizi con una barra.
La configurazione precedente scriverà le voci di registro in un formato noto come Common Log Format (CLF). Questo formato standard può essere prodotto da molti server Web diversi e letto da molti programmi di analisi dei log., Le voci del file di registro prodotte in CLF saranno simili a queste:
127.0.0.1 - frank "GET /apache_pb.gif HTTP/1.0" 200 2326
Ogni parte di questa voce di registro è descritta di seguito.
127.0.0.1
(%h
) Questo è l’indirizzo IP del client (host remoto) che ha fatto la richiesta al server. SeHostnameLookups
è impostato suOn
, il server cercherà di determinare il nome host e registrarlo al posto dell’indirizzo IP. Tuttavia, questa configurazione non è raccomandata poiché può rallentare in modo significativo il server., Invece, è meglio usare un post-processore di log comelogresolve
per determinare i nomi host. L’indirizzo IP riportato qui non è necessariamente l’indirizzo della macchina in cui l’utente è seduto. Se esiste un server proxy tra l’utente e il server, questo indirizzo sarà l’indirizzo del proxy, piuttosto che la macchina di origine.-
(%l
) Il” trattino ” nell’output indica che l’informazione richiesta non è disponibile., In questo caso, l’informazione che non è disponibile è l’identità RFC 1413 del client determinata daidentd
sul computer client. Queste informazioni sono altamente inaffidabili e non dovrebbero quasi mai essere utilizzate se non su reti interne strettamente controllate. Apache httpd non tenterà nemmeno di determinare queste informazioni a meno cheIdentityCheck
non sia impostato suOn
.frank
(%u
) Questo è l’ID utente della persona che richiede il documento come determinato dall’autenticazione HTTP., Lo stesso valore viene in genere fornito agli script CGI nella variabile di ambienteREMOTE_USER
. Se il codice di stato per la richiesta (vedi sotto) è 401, questo valore non dovrebbe essere considerato attendibile perché l’utente non è ancora autenticato. Se il documento non è protetto da password, questa parte sarà “-
” proprio come la precedente.(
%t
) L’ora in cui la richiesta è stata ricevuta., Il formato è:
È possibile visualizzare l’ora in un altro formato specificando %{format}t
nella stringa del formato di log, dove format
è come in strftime(3)
dalla libreria standard C, o uno dei token speciali supportati. Per i dettagli vedere le stringhe di formatomod_log_config
.
"GET /apache_pb.gif HTTP/1.0"
(\"%r\"
) La riga di richiesta dal client è indicata tra virgolette. La riga di richiesta contiene una grande quantità di informazioni utili., Innanzitutto, il metodo utilizzato dal client èGET
. In secondo luogo, il client ha richiesto la risorsa/apache_pb.gif
, e in terzo luogo, il client ha utilizzato il protocolloHTTP/1.0
. È anche possibile registrare una o più parti della riga di richiesta in modo indipendente. Ad esempio, la stringa di formato “
%m %U%q %H
” registrerà il metodo, il percorso, la stringa di query e il protocollo, ottenendo esattamente lo stesso output di “%r
“.200
(%>s
) Questo è il codice di stato che il server invia al client., Questa informazione è molto preziosa, perché rivela se la richiesta ha portato a una risposta riuscita (codici che iniziano in 2), un reindirizzamento (codici che iniziano in 3), un errore causato dal client (codici che iniziano in 4) o un errore nel server (codici che iniziano in 5). L’elenco completo dei possibili codici di stato può essere trovato nella specifica HTTP (RFC2616 sezione 10).2326
(%b
) L’ultima parte indica la dimensione dell’oggetto restituito al client, escluse le intestazioni di risposta., Se nessun contenuto è stato restituito al client, questo valore sarà “-
“. Per registrare “0
“per nessun contenuto, utilizzare invece%B
.
Formato di log combinato
Un’altra stringa di formato comunemente utilizzata è chiamata Formato di log combinato. Può essere usato come segue.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combinedCustomLog log/access_log combined
Questo formato è esattamente lo stesso del formato di registro comune, con l’aggiunta di altri due campi. Ciascuno dei campi aggiuntivi utilizza la direttiva percentuale %{header}i
, dove l’intestazione può essere qualsiasi intestazione di richiesta HTTP., Il log di accesso in questo formato sarà simile a:
I campi aggiuntivi sono:
"http://www.example.com/start.html"
(\"%{Referer}i\"
) L’intestazione della richiesta HTTP “Referer” (sic). Questo dà il sito che il client segnala essere stato riferito da. (Questa dovrebbe essere la pagina che collega o include/apache_pb.gif
)."Mozilla/4.08 (Win98; I ;Nav)"
(\"%{User-agent}i\"
) L’intestazione della richiesta HTTP User-Agent. Questa è l’informazione identificativa che il browser client riporta su se stesso.,
Registri di accesso multipli
I registri di accesso multipli possono essere creati semplicemente specificando più direttiveCustomLog
nel file di configurazione. Ad esempio, le seguenti direttive creeranno tre registri di accesso. Il primo contiene le informazioni CLF di base, mentre il secondo e il terzo contengono informazioni referer e browser. Le ultime due righeCustomLog
mostrano come imitare gli effetti delle direttiveReferLog
eAgentLog
.,
Questo esempio mostra anche che non è necessario definire un nickname con la direttivaLogFormat
. Invece, il formato del registro può essere specificato direttamente nella direttivaCustomLog
.
Log condizionali
Ci sono momenti in cui è conveniente escludere determinate voci dai log di accesso in base alle caratteristiche della richiesta del client. Questo è facilmente realizzabile con l’aiuto di variabili di ambiente. Innanzitutto, è necessario impostare una variabile di ambiente per indicare che la richiesta soddisfa determinate condizioni., Questo di solito è realizzato conSetEnvIf
. Quindi la clausolaenv=
della direttivaCustomLog
viene utilizzata per includere o escludere richieste in cui è impostata la variabile di ambiente. Alcuni esempi:
Come altro esempio, considerare le richieste di registrazione da anglofoni a un file di registro e non anglofoni a un file di registro diverso.
SetEnvIf Accept-Language "en" englishCustomLog logs/english_log common env=englishCustomLog logs/non_english_log common env=!english
In uno scenario di caching si vorrebbe conoscere l’efficienza della cache., Un metodo molto semplice per scoprirlo sarebbe:
SetEnv CACHE_MISS 1LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cacheCustomLog logs/access_log common-cache
mod_cache
verrà eseguito prima di mod_env
e, in caso di successo, consegnerà il contenuto senza di esso. In tal caso un hit cache registrerà -
, mentre un miss cache registrerà 1
.,
Oltre alla sintassi env=
, LogFormat
supporta i valori di registrazione condizionati al codice di risposta HTTP:
LogFormat "%400,501{User-agent}i" browserlogLogFormat "%!200,304,302{Referer}i" refererlog
Nel primo esempio, il User-agent
sarà registrato se il codice di stato HTTP è 400 o 501. In altri casi, verrà invece registrato un ” – ” letterale. Allo stesso modo, nel secondo esempio, il Referer
verrà registrato se il codice di stato HTTP non è 200, 204 o 302. (Notare il”!”prima dei codici di stato.,
Anche se abbiamo appena dimostrato che la registrazione condizionale è molto potente e flessibile, non è l’unico modo per controllare il contenuto dei log. I file di registro sono più utili quando contengono un record completo di attività del server. Spesso è più facile semplicemente post-elaborare i file di registro per rimuovere le richieste che non si desidera prendere in considerazione.