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 查詢字元串（如果存在查詢字元串，則包含「?」後面的

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

%...r: 請求的第一行

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

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

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

%t: 以指定格式format表示的時間

%...T: 為響應請求而耗費的時間，以秒計

%...u: 遠程用戶（來自auth；如果返回狀態（%s）是401則可能是偽造的）

%...U: 用戶所請求的URL路徑

%...v: 響應請求的伺服器的ServerName

%...V: 依照UseCanonicalName設置得到的伺服器名字


------------------------------------------------------------------


　　 在所有上面列出的變數中，「...」表示一個可選的條件。如果沒有指定條件，則變數的值將以「-」取代。分析前面來自默認httpd.conf文件的LogFormat指令示例，可以看出它創建了一種名為「common」的日誌格式，其中包括：遠程主機，遠程登錄名字，遠程用戶，請求時間，請求的第一行代碼，請求狀態，以及發送的位元組數。

　　 有時候我們只想在日誌中記錄某些特定的、已定義的信息，這時就要用到「...」。如果在「%」和變數之間放入了一個或者多個HTTP狀態代碼，則只有當請求返回的狀態代碼屬於指定的狀態代碼之一時，變數所代表的內容才會被記錄。例如，如果我們想要記錄的是網站的所有無效鏈接，那麼可以使用：

----------------------------------------------------

LogFormat %404{Referer}i BrokenLinks

---------------------------------------------------



　　 反之，如果我們想要記錄那些狀態代碼不等於指定值的請求，只需加入一個「!」符號即可：



LogFormat %!200U SomethingWrong

Apche日誌系列(4)：日誌分析


儘管日誌文件中包含著大量有用的信息，但這些信息只有在經過深入挖掘之後才能夠最大限度地發揮作用。本文首先討論了能夠從日誌文件獲得的信息以及不能從日誌文件獲得的信息，然後介紹了幾種優秀的日誌分析工具以及如何自己編程分析日誌文件。

一、可以得到哪些信息(4月4日)

　　 在這個《Apache日誌》系列文章的前面幾篇中，我們討論了Apache的標準日誌文件——訪問日誌和錯誤日誌，以及如何定製日誌文件。本文接下來討論如何分析日誌文件獲得寶貴的統計信息。

　　 我們面臨的問題是，雖然日誌文件中包含了大量的信息，但這些信息對於我們管理、規劃網站卻沒有多少直接的幫助。為了管理和規劃網站，我們需要知道：有多少人瀏覽了網站，他們在看些什麼，停留了多長時間，他們從哪裡得知這個網站，等等。所有這些信息就隱藏於（或者可能隱藏於）日誌文件之中。

　　 就網站的經營者而言，他們還希望知道瀏覽者的姓名、地址、鞋子大小，甚至還有瀏覽者的信用卡號碼，但這些信息都不可能從日誌文件中得到。為此，作為技術人員的我們就必須知道如何向這些經營者解釋清楚：這部分信息不僅不可能從日誌文件獲得，而且要獲得這些信息的唯一方法是直接向瀏覽者本人詢問，並作好被拒絕的準備。

　　 有許多信息可以用日誌文件來記錄，其中包括：



遠程機器的地址：「遠程機器的地址」和「誰在瀏覽網站」差不多，但並不等同。具體地說，遠程機器的地址告訴我們瀏覽者來自何方，比如它可能是buglet.rcbowen.com或者proxy01.aol.com。

瀏覽時間：瀏覽者何時開始訪問網站？從這個問題的答案中我們能夠了解不少情況。如果網站的大多數瀏覽者都在早上9:00和下午4:00之間訪問網站，那麼可以相信網站的瀏覽者大多數總在工作時間進行訪問；如果訪問記錄大多出現在下午7:00到午夜之間，我們可以肯定瀏覽者一般在家裡上網。 當然，從單個訪問記錄能夠得到的信息非常有限，但如果從數千個訪問記錄出發，我們就可以得到非常有用和重要的統計信息。

用戶所訪問的資源：網站的哪些部分最受用戶歡迎？這些最受歡迎的部分就是我們應該繼續加以發展的部分。網站的哪些部分總是受到冷落？網站中這些受到冷落的部分或許隱藏得太深，或許它們確實沒有什麼意思，此時我們就得想辦法加以改進。當然，網站還有的內容，比如法律上的聲明，雖然很少有人訪問，但卻不應該隨便地改動它們。

無效鏈接：當然，日誌文件還能夠告訴我們哪些東西不能按照我們所想象地運行。網站中是否存在錯誤的鏈接？其他網站鏈接過來時有沒有搞錯URL？是否存在不能正常運行的CGI程序？是否有搜索引擎檢索程序每秒發出數千個請求，從而影響了本網站的正常服務？這些問題的答案都可以從日誌文件找到線索

Tags: linux system 系統