Apache日誌詳解

    
Apache日誌詳解

來源：Linux技術中堅站


訪問日誌

錯誤日誌

定製日誌

日誌分析

高階技術

想要知道什麼人在什麼時候瀏覽了網站的哪些內容嗎？檢視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錯誤日誌，定製日誌的格式和內容，如何將日誌內容寫入指定的程式而不是檔案，如何從日誌檔案獲得一些非常有用的統計資訊，等等。

錯誤日誌 跳轉到 》》》訪問日誌 定製日誌 日誌分析 高階技術

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

一、位置和內容

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

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

　　 錯誤日誌的檔名字是error_log，但如果是Windows平臺，則錯誤日誌的檔名字是error.log。錯誤日誌的位置可以透過ErrorLog指令設定：


ErrorLog logs/error.log

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

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

　　我們可以設定日誌檔案記錄資訊級別的高低，控制日誌檔案記錄資訊的數量和型別。這是透過LogLevel指令設定的，該指令預設設定的級別是 error，即記錄稱得上錯誤的事件。有關該指令中允許設定的各種選項的完整清單，請參見http: //的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的工具，它可以在~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把日誌資訊傳送給系統管理員，等等。

定製日誌 跳轉到 》》》訪問日誌 錯誤日誌 日誌分析 高階技術

有時候我們需要定製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使用者具有進行所有這些操作的許可權。

　　 如果你要把日誌記錄寫入到某個程式，建議先找找是否有現成的具備自己想要功能的模組。請訪問，該網站收集了許多面向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日誌功能的方方面面，從標準日誌（訪問日誌，錯誤日誌）到定製日誌、日誌分析等等，希望這些內容能夠對你有所幫助。