Apche日誌系列(2)：錯誤日誌(轉)

Apche日誌系列(2)：錯誤日誌(轉)[@more@]

錯誤日誌和訪問日誌一樣也是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把日誌資訊傳送給系統管理員，等等