Apache日志詳解

雪落无影

http://fjt.now.net.cn:7751/www.linuxext.com/forum_view.asp?forum_id=16&view_id=243

Apache日志詳解（一）
訪問日志

錯誤日志

定制日志

日志分析

高級技術

想要知道什么人在什么時候瀏覽了網站的哪些內容嗎？查看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。在這個例子中，瀏覽者請求的是“/”，即網站的主頁或根。大多數情況下，“/”指向document.oot目錄的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錯誤日志，定制日志的格式和內容，如何將日志內容寫入指定的程序而不是文件，如何從日志文件獲得一些非常有用的統計信息，等等。

錯誤日志 跳轉到 》》》訪問日志 定制日志 日志分析 高級技術

錯誤日志和訪問日志一樣也是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.nbspNot 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把日志信息發送給係統管理員，等等。

本文出處http://linux-down.kmip.net ，如需轉載請注明！

雪落无影

Apache日志詳解（二）
定制日志 跳轉到 》》》訪問日志 錯誤日志 日志分析 高級技術

有時候我們需要定制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


日志分析 跳轉到 》》》訪問日志 錯誤日志 高級技術 定制日志

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

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

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

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

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

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


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

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

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

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


高級技術 跳轉到 》》》訪問日志 錯誤日志 日志分析 定制日志

這是《Apache日志》係列文章的最後一篇，除了補充說明前面幾篇文章之外，另外討論了三個問題：如何將日志記錄寫入指定的程序而不是日志文件，如何輪換日志防止磁盤空間不足，多虛擬主機環境下的日志文件管理。

一、把日志記錄寫入到指定程序

　　在這個《Apache日志》係列文章的前一篇中，我們討論了幾種日志文件分析工具。應當補充說明的是，它並沒有列出全部的分析工具。在Google上簡單地搜索一下“apache log reporting”或類似的關鍵詞，返回有關該主題的頁面多達數百個，有許多供應商在為這個相對簡單的問題推銷自己特有的方案。

　　 日志記錄並非只能寫入到文件，它還可以寫入到指定的進程。當我們想要把日志信息寫入數據庫、或者是某些能夠實時顯示網站流量統計信息的程序時，這一點是非常有用的。

　　 那么，如何實現這一點呢？使用TransferLog或者CustomLog指令，我們能夠指定“|”，後面再加上接收日志信息的程序名字。例如：


CustomLog |/usr/bin/apachelog.pl common

　　 其中/usr/bin/apachelog.pl是一個程序，這個程序知道如何處理Apache日志文件的記錄。事實上，這個程序非常簡單，比如它可以是一個按照某種方式處理日志記錄的Perl程序，或者是一個將日志記錄寫入數據庫的程序。

　　 在採用這種記錄日志數據的方法時，安全問題是最必須關注的問題。日志文件是以啟動服務器的用戶所具有的權限打開的，通常是root。對於將日志記錄寫入數據庫的程序，這一點也同樣有效，所以應當確保用於記錄日志數據的程序具有充分的安全保證。

　　如果日志數據通過一個不安全的程序記錄（這個程序可能被非root用戶侵入和修改），那么係統就面臨著日志記錄程序被其他懷有惡意的程序替換的危險。例如，如果/usr/bin/apachelog.pl可被全世界的用戶修改，那么任何用戶都將能夠編輯這個文件關閉Web服務器，把密碼文件發送到某個信箱，或者刪除某些重要的文件，因為root用戶具有進行所有這些操作的權限。

　　 如果你要把日志記錄寫入到某個程序，建議先找找是否有現成的具備自己想要功能的模塊。請訪問http://modules.apache.org/，該網站收集了許多面向Apache完成各類實際任務的模塊。

二、輪換日志

　　 日志文件會越來越大，如果不小心把日志文件放到了/var之類位置，日志文件可能寫滿分區，從而導致服務器被迫停止運行。這種事情確實曾經發生過。

　　防止出現這種問題的辦法是，在日志文件變得太大之前把它們移到其他具有足夠空間的位置。這可以通過幾種方法實現。某些Unix變種提供一個 logrotate腳本，它能夠幫助我們完成這個任務。例如RedHat就已經預先配置，它會根據日志文件的大小或者日志文件的使用時間，每隔幾日輪換日志文件。

　　 如果要自己實現這方面的功能，我們可以使用稱為Logfile&::Rotate的Perl模塊（可從CPAN下載）。下面的代碼就具有這種功能，它由cron按照一定的間隔周期（比如一星期）運行，為了節省空間。每一個備份的日志文件都經過壓縮。


use Logfile&::Rotate;

$logfile = new Logfile&::Rotate(

File => &single;/usr/local/apache/logs/access_log&single;,

Count => 5,

Gzip => &single;/bin/gzip&single;,

Signal => sub {

`/usr/local/apache/bin/apachectl restart`;

}
);
　　 代碼不多，Perl模塊Logfile&::Rotate負責了所有具體操作任務。運行這個程序，我們將得到名為access_log.1.gz、 access_log.2.gz等的文件。它可以幫助我們避免磁盤空間的不足，使得我們能夠保存任意多的檔案文件。
三、多個虛擬主機的日志
　　 曾經有好幾個人問起，當同一臺機器上運行著多個虛擬主機時應該如何分析日志？我想，他們是先把所有虛擬主機的日志記錄都保存到了同一臺機器，然後又企圖把這個日志文件按照虛擬主機的不同分割成多個部分。
　　徹底解決這個問題的方法是一開始就不要把所有虛擬主機的日志記錄都寫入到同一個文件。雖然我知道確實存在這樣的工具，它們能夠把多個虛擬主機混合的日志記錄根據虛擬主機配置分開，指出哪些請求針對哪個虛擬主機發出，然後分別生成報表。然而，這種方法看起來實在是太麻煩了。
　　 為每一個虛擬主機分別指定日志文件時，我們只需在每個VirtualHost區域指定該主機的日志文件。此後，當需要制作報表時，我們就可以分別地處理各個日志文件。
　　但這裏必須注意一下可用文件句柄的問題。也就是說，如果某臺服務器上運行的虛擬主機多達數百個，每個虛擬主機都有單獨的日志文件，係統可能會出現可用文件句柄不足的問題，它可能導致係統不穩定甚至導致係統崩潰。然而，只有當服務器上運行的虛擬主機數量非常龐大時，我們才有關注這個問題的
必要。
　　 《Apache日志》係列文章到此已經全部結束。在這五篇文章中，我們討論了Apache日志功能的方方面面，從標準日志（訪問日志，錯誤日志）到定制日志、日志分析等等，希望這些內容能夠對你有所幫助。

本文出處http://linux-down.kmip.net ，如需轉載請注明！