Apache日誌解讀,Apache日誌每列代表什麼?

Apche日誌系列(1)：訪問日誌

想要知道什麼人在什麼時候瀏覽了網站的哪些內容嗎。查看Apache的訪問日誌就可以知道。訪問日誌是Apache的標準日誌，本文詳細解釋了訪問日誌的內容以及相關選項的配置。

一、訪問日誌的格式

Apache內建了記錄伺服器活動的功能，這就是它的日誌功能。這個《Apache日誌》系列文章介紹的就是Apache的訪問日誌、錯誤記錄檔，以及如何分析日誌資料，如何定製Apache日誌，如何從日誌資料產生統計報表等內容。

如果Apache的安裝方式是預設安裝，伺服器一運行就會有兩個記錄檔產生。這兩個檔案是access_log（在Windows上是 access.log）和error_log（在Windows上是error.log）。採用預設安裝方式時，這些檔案可以在/usr/local /apache/logs下找到；對於Windows系統，這些記錄檔將儲存在Apache安裝目錄的logs子目錄。不同的包管理器會把記錄檔放到 各種不同的位置，所以你可能需要找找其他的地方，或者通過設定檔查看這些記錄檔配置到了什麼地方。

正如其名字所示，訪問日誌access_log記錄了所有對Web伺服器的訪問活動。下面是訪問日誌中一個典型的記錄：

216.35.116.91 - - [19/Aug/2000:14:47:37 -0400] “GET / HTTP/1.0″ 200 654

這行內容由7項構成，上面的例子中有兩項空白，但整行內容仍舊分成了7項。

第一項資訊是遠程主機的地址，即它表明訪問網站的究竟是誰。在上面的例子中，訪問網站的主機是216.35.116.91。隨便說一句，這 個地址屬於一台名為si3001.inktomi.com的機器（要找出這個資訊，可以使用nslookup工具尋找DNS），inktomi.com是 一家製作Web搜尋軟體的公司。可以看出，僅僅從日誌記錄的第一項出發，我們就可以得到有關訪問者的不少資訊。

預設情況下，第一項資訊只是遠程主機的IP地址，但我們可以要求Apache查出所有的主機名稱字，並在記錄檔中用主機名稱字來替代IP地 址。然而，這種做法通常不值得推薦，因為它將極大地影響伺服器記錄日誌的速度，從而也就減低了整個網站的效率。另外，有許多工具能夠將記錄檔中的IP地 址轉換成主機名稱字，因此要求Apache記錄主機名稱字替代IP地址是得不償失的。

然而，如果確實有必要讓Apache找出遠程主機的名字，那麼我們可以使用如下指令：

HostNameLookups on

如果HostNameLookups設定成double而不是on，日誌記錄程式將對它找到的主機名稱字進行反向尋找，驗證該主機名稱字確實指向了原來出現的IP地址。預設情況下HostNameLookups設定為off。

上例日誌記錄中的第二項是空白，用一個“-”預留位置替代。實際上絕大多數時候這一項都是如此。這個位置用於記錄瀏覽者的標識，這不只是瀏覽 者的登入名稱字，而是瀏覽者的email地址或者其他唯一識別碼。這個資訊由identd返回，或者直接由瀏覽器返回。很早的時候，那時 Netscape 0.9還佔據著統治地位，這個位置往往記錄著瀏覽者的email地址。然而，由於有人用它來收集郵件地址和發送垃圾郵件，所以它未能保 留多久，很久之前市場上幾乎所有的瀏覽器就取消了這項功能。因此，到了今天，我們在日誌記錄的第二項看到email地址的機會已經微乎其微了。

日誌記錄的第三項也是空白。這個位置用於記錄瀏覽者進行身分識別驗證時提供的名字。當然，如果網站的某些內容要求使用者進行身分識別驗證，那麼這項資訊是不會空白的。但是，對於大多數網站來說，記錄檔的大多數記錄中這一項仍舊是空白的。

日誌記錄的第四項是請求的時間。這個資訊用方括弧包圍，而且採用所謂的“公用日誌格式”或“標準英文格式”。因此，上例記錄資料表示請求的時間是2000年8月19日星期三14:47:37。時間資訊最後的“-0400”表示伺服器所處時區位於UTC之前的4小時。

日誌記錄的第五項資訊或許是整個日誌記錄中最有用的資訊，它告訴我們伺服器收到的是一個什麼樣的請求。該項資訊的典型格式是“METHOD RESOURCE PROTOCOL”，即“方法 資源 協議”。

在上例中，METHOD是GET，其他經常可能出現的METHOD還有POST和HEAD。此外還有不少可能出現的合法METHOD，但主要就是這三種。

RESOURCE是指瀏覽者向伺服器請求的文檔，或URL。在這個例子中，瀏覽者請求的是“/”，即網站的首頁或根。大多數情況下，“/”指向DocumentRoot目錄的index.html文檔，但根據伺服器配置的不同它也可能指向其他檔案。

PROTOCOL通常是HTTP，後面再加上版本號碼。版本號碼或者是1.0，或者是1.1，但出現1.0的時候比較多。我們知道，HTTP協 議是Web得以工作的基礎，HTTP/1.0是HTTP協議的早期版本，而1.1是最近的版本。當前大多數Web客戶程式仍使用1.0版本的HTTP協 議。

日誌記錄的第六項資訊是狀態碼。它告訴我們請求是否成功，或者遇到了什麼樣的錯誤。大多數時候，這項值是200，它表示伺服器已經成功地 響應瀏覽器的請求，一切正常。此處不準備給出狀態碼的完整清單以及解釋它們的含義，請參考相關資料瞭解這方面的資訊。但一般地說，以2開頭的狀態碼表 示成功，以3開頭的狀態碼表示由於各種不同的原因使用者請求被重新導向到了其他位置，以4開頭的狀態碼表示用戶端存在某種錯誤，以5開頭的狀態碼表示服 務器遇到了某個錯誤。

日誌記錄的第七項表示發送給用戶端的總位元組數。它告訴我們傳輸是否被打斷（即，該數值是否和檔案的大小相同）。把日誌記錄中的這些值加起來就可以得知伺服器在一天、一周或者一月內發送了多少資料。

二、配置訪問日誌

訪問記錄檔的位置實際上是一個配置選項。如果我們檢查httpd.conf設定檔，可以看到該檔案中有如下這行內容：

CustomLog /usr/local/apache/logs/access_log common

注意，對於版本較早的Apache伺服器，這行內容可能略有不同。它使用的可能不是CustomLog指令，而是TransferLog指令。如果你的伺服器屬於這類情況，建議你儘可能地早日升級伺服器。

CustomLog指令指定了儲存記錄檔的具體位置以及日誌的格式。至於如何定製記錄檔的格式以及內容，我們將在這個《Apache日 志》系列文章的後面幾篇討論。上面這行指令指定的是common日誌格式，自從有了Web伺服器開始，common格式就是它的標準格式。由此我們也可以 理解，雖然幾乎不再有任何客戶程式向伺服器提供使用者的標識資訊，但訪問日誌卻還保留著第二項內容。

CustomLog指令中的路徑是記錄檔的路徑。注意，由於記錄檔是由HTTP使用者開啟的（用User指令指定），因此必須注意這個路徑要有安全保證，防止該檔案被隨意改寫。

《Apache日誌》系列文章的後面幾篇將繼續介紹：Apache錯誤記錄檔，定製日誌的格式和內容，如何將日誌內容寫入指定的程式而不是檔案，如何從記錄檔獲得一些非常有用的統計資訊，等等。

Apche日誌系列(2)：錯誤記錄檔

錯誤記錄檔和訪問日誌一樣也是Apache的標準日誌。本文分析錯誤記錄檔的內容，介紹如何設定和錯誤記錄檔相關的選項，文檔錯誤和CGI錯誤的分類，以及如何方便地查看日誌內容，等等。

一、位置和內容

前文討論了Apache的訪問日誌，包括它的內容、格式和如何設定訪問日誌有關的選項。本文我們要討論的是另外一種Apache標準日誌——錯誤記錄檔。

錯誤記錄檔無論在格式上還是在內容上都和訪問日誌不同。然而，錯誤記錄檔和訪問日誌一樣也提供豐富的資訊，我們可以利用這些資訊分析伺服器的運行情況、哪裡出現了問題。

錯誤記錄檔的檔案名稱字是error_log，但如果是Windows平台，則錯誤記錄檔的檔案名稱字是error.log。錯誤記錄檔的位置可以通過ErrorLog指令設定：

ErrorLog logs/error.log

除非檔案位置用“/”開頭，否則這個檔案位置是相對於ServerRoot目錄的相對路徑。如果Apache採用預設安裝方式安裝，那麼錯 誤日誌的位置應該在/usr/local/apache/logs下。但是，如果Apache用某種包管理器安裝，錯誤記錄檔很可能在其他位置。

正如其名字所示，錯誤記錄檔記錄了伺服器運行期間遇到的各種錯誤，以及一些普通的診斷資訊，比如伺服器何時啟動、何時關閉等。

我們可以設定記錄檔記錄資訊層級的高低，控制記錄檔記錄資訊的數量和類型。這是通過LogLevel指令設定的，該指令預設設定的層級 是error，即記錄稱得上錯誤的事件。有關該指令中允許設定的各種選項的完整清單，請參見http://www.apache.org/docs /mod/core.html#loglevel的Apache文檔。

大多數情況下，我們在記錄檔中見到的內容分屬兩類：文檔錯誤和CGI錯誤。但是，錯誤記錄檔中偶爾也會出現配置錯誤，另外還有前面提到的伺服器啟動和關閉資訊。

二、文檔錯誤

文檔錯誤和伺服器應答中的400系列代碼相對應，最常見的就是404錯誤——Document Not Found（文檔沒有找到）。除了404錯誤以外，使用者身分識別驗證錯誤也是一種常見的錯誤。

404錯誤在使用者請求的資源（即URL）不存在時出現，它可能是由於使用者輸入的URL錯誤，或者由於伺服器上原來存在的文檔因故被刪除或移動。

順便說一下，按照Jakob Nielson的意見，在不提供重新導向或者其他補救措施的情況下，我們永遠不應該移動或者刪除Web網站的任何資源。Nielson的更多文章，請參見http://www.zdnet.com/devhead/alertbox/。

當使用者不能開啟伺服器上的文檔時，錯誤記錄檔中出現的記錄如下所示：

[Fri Aug 18 22:36:26 2000] [error]

[client 192.168.1.6] File does not exist:

/usr/local/apache/bugletdocs/Img/south-korea.gif

可以看到，正如訪問日誌access_log檔案一樣，錯誤記錄檔記錄也分成多個項。

錯誤記錄的開頭是日期/時間標記，注意它們的格式和access_log中日期/時間的格式不同。access_log中的格式被稱為“標準英文格式”，這或許是曆史跟我們開的一個玩笑，但現在要改變它已經太遲了。

錯誤記錄的第二項是目前記錄的層級，它表明了問題的嚴重程度。這個層級資訊可能是LogLevel指令的文檔中所列出的任一層級（參見前面 LogLevel的連結），error層級處於warn層級和crit層級之間。404屬於error錯誤層級，這個層級表示確實遇到了問題，但伺服器還 可以運行。

錯誤記錄的第三項表示使用者發出請求時所用的IP地址。

記錄的最後一項才是真正的錯誤資訊。對於404錯誤，它還給出了完整路徑指示伺服器試圖訪問的檔案。當我們料想某個檔案應該在目標位置卻出 現了404錯誤時，這個資訊是非常有用的。此時產生這種錯誤的原因往往是由於伺服器配置錯誤、檔案實際所處的虛擬機器主機和我們料想的不同，或者其他一些意料 不到的情況。

由於使用者身分識別驗證問題而出現的錯誤記錄如下所示：

[Tue Apr 11 22:13:21 2000]

[error] [client 192.168.1.3] user rbowen@rcbowen.

com: authentication failure for “/cgi-bin/hirecareers/company.cgi”:

password mismatch

注意，由於文檔錯誤是使用者請求的直接結果，因此它們在訪問日誌中也會有相應的記錄。

三、CGI錯誤
錯誤記錄檔最主要的用途或許是診斷行為異常的CGI程式。為了進一步分析和處理方便，CGI程式輸出到 STDERR（Standard Error，標準錯誤裝置）的所有內容都將直接進入錯誤記錄檔。這意味著，任何編寫良好的CGI程式，如果出現了問題，錯 誤日誌就會告訴我們有關問題的詳細資料。

然而，把CGI程式錯誤輸出到錯誤記錄檔也有它的缺點，錯誤記錄檔中將出現許多沒有標準格式的內容，這使得用錯誤記錄檔自動剖析器從中分析出有用的資訊變得相當困難。

下面是一個例子，它是調試Perl CGI代碼時，錯誤記錄檔中出現的一個錯誤記錄：

[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature

end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

Global symbol “$rv” requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.

Global symbol “%details” requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.

Global symbol “$Config” requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.

Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

aborted due to compilation errors.

可以看到，CGI錯誤和前面的404錯誤格式相同，包含日期/時間、錯誤層級以及客戶地址、錯誤資訊。但這個CGI錯誤的錯誤資訊有好幾行，這往往會干擾一些錯誤記錄檔分析軟體的工作。

有了這個錯誤資訊，即使是對Perl不太熟悉的人也能夠找出許多有關錯誤的資訊，例如至少可以方便地得知是哪幾行代碼出現了問題。Perl在報告程式錯誤方面的機制是相當完善的。當然，不同的程式設計語言輸出到錯誤記錄檔的資訊會有所不同。

由於CGI程式運行環境的特殊性，如果沒有錯誤記錄檔的協助，大多數CGI程式的錯誤都將很難解決。

有不少人在郵件清單或者新聞群組中抱怨說自己有一個CGI程式，當開啟網頁時伺服器卻返回錯誤，比如 “Internal Server Error”。我們可以肯定，這些人還沒有看過伺服器的錯誤記錄檔，或者根本不知道錯誤記錄檔的存在。決多大多數情況下， 錯誤記錄檔能夠精確地指出CGI錯誤的所在以及如何修正這個錯誤。

四、查看記錄檔

我常常告訴別人說，在進行開發的同時我會不斷地檢查伺服器的日誌，以便能夠立即知道哪兒出了問題。但我得到的回答卻往往是沉默。起先我以為這種沉默意味著“你當然得這樣做”，後來我才發現這種沉默的真正含義是“我不知道別人的做法，但我自己是不乾的。”

雖然如此，下面我們還是要看看如何方便地查看伺服器記錄檔。用telnet串連到伺服器，然後輸入下面的命令：

tail -f /usr/local/apache/logs/error_log

該命令將顯示出記錄檔的最後幾行內容，如果有新的內容加入到記錄檔，它還會立即顯示出新加入的內容。

Windows使用者也同樣可以使用這種方法，比如可以使用各種為Windows提供的Unix工具軟體包。我個人愛好一個稱為AINTX的工具，它可以在http://maxx.mc.net/~jlh/nttools/index.htm找到。

還有一種替代方法是使用下面的Perl代碼，它利用了一個稱為File::Tail的模組：

use File::Tail;

$file=File::Tail->new(“/some/log/file”);

while (defined($line=$file->read)) {

print “$line”;

}

無論具體採用的是哪一種方法，同時開啟多個終端視窗都是一種好習慣：比如在一個視窗中顯示錯誤記錄檔，在另一個視窗中顯示訪問日誌。這樣，我們就能夠隨時獲知網站上發生的事情並立即予以解決。

在這個《Apache日誌》系列的下一篇文章中，我們將討論定製伺服器日誌，即如何在記錄檔中記錄所有我們想要的資訊，排除所有我們不想要的資訊。

在此之後，我們還將討論記錄檔的處理，即如何從記錄檔產生統計報表。在最後幾篇文章中，我們還將討論如何把日誌記錄重新導向到指定的程式 而不是儲存到記錄檔，以便由程式即時地處理新產生的日誌資料，比如將日誌資料儲存到資料庫，或者當發生某些關鍵性錯誤時通過email把日誌資訊發送給 系統管理員，等等。

Apche日誌系列(3)：定製日誌

有時候我們需要定製Apache預設日誌的格式和內容，比如增加或減少日誌所記錄的資訊、改變預設記錄檔的格式等。本文介紹可以用日誌記錄的所有資訊，以及如何設定Apache使其記錄這些資訊。

一、定義日誌格式(4月3日)

很久以前，記錄檔只有一種格式，這就是“公用格式”，許多人已經習慣於使用這種格式。隨後出現了定製日誌格式，而且看起來定製日誌格式更 很受歡迎，即使公用日誌格式本身也重新用定製日誌格式定義。本文介紹的就是如何隨心所欲地定製記錄檔的格式、如何讓記錄檔記錄自己想要的資訊。

定製記錄檔的格式涉及到兩個指令，即LogFormat指令和CustomLog指令，預設httpd.conf檔案提供了關於這兩個指令的幾個樣本。

LogFormat指令定義格式並為格式指定一個名字，以後我們就可以直接引用這個名字。CustomLog指令設定記錄檔，並指明記錄檔所用的格式（通常通過格式的名字）。

LogFormat指令的功能是定義日誌格式並為它指定一個名字。例如，在預設的httpd.conf檔案中，我們可以找到下面這行代碼：

LogFormat “%h %l %u %t \”%r\” %>s %b” common

該指令建立了一種名為“common”的日誌格式，日誌的格式在雙引號包圍的內容中指定。格式字串中的每一個變數代表著一項特定的資訊，這些資訊按照格式串規定的次序寫入到記錄檔。

Apache文檔已經給出了所有可用于格式串的變數及其含義，下面是其譯文：

———————————————————————-

%…a: 遠程IP地址

%…A: 本地IP地址

%…B: 已發送的位元組數，不包含HTTP頭

%…b: CLF格式的已發送位元組數量，不包含HTTP頭。

例如當沒有發送資料時，寫入‘-’而不是0。

%e: 環境變數FOOBAR的內容

%…f: 檔案名稱字

%…h: 遠程主機

%…H 請求的協議

%i: Foobar的內容，發送給伺服器的請求的標題行。

%…l: 遠程登入名稱字（來自identd，如提供的話）

%…m 請求的方法

%n: 來自另外一個模組的註解“Foobar”的內容

%o: Foobar的內容，應答的標題行

%…p: 伺服器響應請求時使用的連接埠

%…P: 響應請求的子進程ID。

%…q 查詢字串（如果存在查詢字串，則包含“?”後面的

部分；否則，它是一個Null 字元串。）

%…r: 請求的第一行

%…s: 狀態。對於進行內部重新導向的請求，這是指*原來*請求

的狀態。如果用%…>s，則是指後來的請求。

%…t: 以公用日誌時間格式表示的時間（或稱為標準英文