Apache的日志檔案(轉載)

轉載

apache的日志檔案記錄了伺服器對每次請求做出響應的有關資訊。分析日志檔案可以提供重要的統計資料，如通路量最大或通路最頻繁的web頁；也可以檢視伺服器的錯誤記錄，進而獲得和安全問題相關的資訊。使用者需要高度重視日志檔案，要經常檢視，尤其是錯誤資訊日志檔案，以便能盡快發現已經發生的問題或可能存在的問題。

很多時候，除非使用者注意到apache有些異常，否則都是日志檔案中不尋常的項目最先訓示出有人入侵了系統。黑客也知道這一點，高明的黑客會用vi之類的工具編輯遭受入侵的系統的日志檔案，抹去入侵的痕迹。

apache預設保留兩個日志檔案：通路日志和錯誤日志。

通路日志

redhat linux 7.1的通路日志檔案預設為/var/log/httpd/access_log。這是apache标準的日志檔案。通路日志的作用是記錄所有對apache伺服器的通路活動，使用者可以借此查閱是哪些人在什麼時間什麼地點浏覽了網站的哪些内容。

下面是通路日志中一個典型的記錄：

210.12.195.6 - - [10/aug/2002:14:47:37 -0400] "get / http/1.0" 200 654

　　①　　②③　　　　　④　　　　　　　　　⑤　　　　⑥ ⑦

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

①是遠端主機的位址，即它表明通路網站的究竟是誰。在上面的例子中，通路網站的主機是210.12.195.6。可以通過nslookup之類的工具查找dns。可以看出，僅僅從日志記錄的第一項出發，我們就可以得到有關通路者的不少資訊。

預設情況下，①隻是遠端主機的ip位址，也可以要求apache查出所有的主機名字，并在日志檔案中用主機名字替代ip位址。然而，這種做法通常不值得推薦，因為它将極大地影響伺服器記錄日志的速度，進而也就降低了整個網站的效率。另外，有許多工具能夠将日志檔案中的ip位址轉換成主機名字，是以要求apache用主機名字替代ip位址是得不償失的。

然而，如果确實有必要讓apache找出遠端主機的名字，使用者可以在httpd.c

hostnamelookups on

如果hostnamelookups設定成double而不是

上例日志記錄中的②是空白，用一個“-”占位符替代。實際上絕大多數時候這一項都是如此。這個位置用于記錄浏覽者的辨別，這不隻是浏覽者的登入名字，而是浏覽者的e-mail位址或者其他惟一辨別符。這個資訊由identd傳回，或者直接由浏覽器傳回。很早的時候，當netscape 0.9還占據着統治地位時，這個位置往往記錄着浏覽者的e-mail位址。然而，由于有人用它收集郵件位址和發送垃圾郵件，是以它未能保留多久，幾乎所有的浏覽器都取消了這項功能。是以現在在日志記錄的第二項看到e-mail位址的機會已經微乎其微了。

日志記錄中的③也是空白。這個位置用于記錄浏覽者進行身份驗證時提供的名字。當然，如果網站的某些内容要求使用者進行身份驗證，那麼這項資訊是不會空白的。但對于大多數網站來說，日志檔案的大多數記錄中這一項仍舊是空白的。

日志記錄中的④是請求的時間。這個資訊用方括号“[ ]”包圍，而且采用所謂的“公共日志格式”或“标準英文格式”。是以，上例日志記錄表示請求的時間是2002年8月10日星期六14:47:37。時間資訊最後的“-0400”表示伺服器所處時區位于utc之前的4小時。

日志記錄中的⑤是整個日志記錄中最有用的資訊，它記錄了伺服器收到的是一個什麼樣的請求。該項資訊的典型格式是“method resource protocol”，即“方法 資源 協定”。

在上例中，method是get，其他經常可能出現的method還有post和head。此外還有不少可能出現的合法method，但主要就是這3種。

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開頭的狀态代碼表示伺服器遇到了某個錯誤。

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

注意，由于日志檔案是由apache使用者打開的（在httpd.c

錯誤日志

redhat linux 7.1的錯誤日志檔案預設為/var/log/httpd/error_log。

錯誤日志無論在格式上還是在内容上都和通路日志不同。然而，錯誤日志和通路日志一樣也提供豐富的資訊，可以利用這些資訊分析伺服器的運作情況、哪裡出現了問題。

錯誤日志記錄了apache伺服器運作期間遇到的各種錯誤，以及一些普通的診斷資訊，比如apache伺服器何時啟動、何時關閉等。

可以在httpd.c

大多數情況下，日志檔案中的内容分屬兩類：文檔錯誤和cgi錯誤。但是，錯誤日志中偶爾也會出現配置錯誤，另外還有前面提到的伺服器啟動和關閉資訊。

文檔錯誤和伺服器傳回的400系列代碼相對應，最常見的就是404錯誤——document not found（文檔沒找到）。404錯誤在使用者請求的資源（即url）不存在時出現，它可能是因為使用者輸入的url錯誤，或者因為apache伺服器上原來存在的文檔因故被删除或移動。除了404錯誤以外，使用者身份驗證錯誤也是一種常見的錯誤。

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

[sat aug 10 9 09:18:14 2002] [error] [61.181.52.23] file does not exist: /var/www/html/ij

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

錯誤記錄的開頭是日期/時間标記，注意它們的格式和access_log中日期/時間的格式不同。access_log中的格式被稱為“标準英文格式”。

錯誤記錄的第二項是目前記錄的級别，它表明了問題的嚴重程度。這個級别資訊可能是loglevel指令的文檔中所列出的任一級别，error級别處于warn級别和crit級别之間。404屬于error錯誤級别，這個級别表示确實遇到了問題，但伺服器還可以運作。

錯誤記錄的第三項表示使用者送出請求時所用的ip位址。

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

由于使用者身份驗證問題而出現的錯誤記錄如下所示：

[sat aug 1 22:13:21 2002] [error] [client 61.181.52.23] user

[email protected]: authentication failure for "/cgi-bin/hirecareers/company.cgi": password mismatch

注意，由于文檔錯誤是使用者請求的直接結果，是以它們在通路日志中也會有相應的記錄。

錯誤日志最主要的用途是診斷行為異常的cgi程式。為了進一步分析和處理的友善，cgi程式輸出到stderr（standard error，标準錯誤裝置）的所有内容都将直接進入錯誤日志。這意味着，任何編寫良好的cgi程式，如果出現了問題，錯誤日志就會記錄有關問題的詳細資訊。

然而，把cgi程式錯誤輸出到錯誤日志也有它的缺點，錯誤日志中将出現許多沒有标準格式的内容，這使得用錯誤日志自動分析程式從錯誤日志中分析出有用的資訊變得相當困難。

由于cgi程式運作環境的特殊性，如果沒有錯誤日志的幫助，大多數cgi程式的錯誤都将很難解決。

有不少人在郵件清單或者新聞討論區中抱怨說自己有一個cgi程式，當打開網頁時伺服器卻傳回錯誤，比如“internal server error”。可以肯定，這些人沒有看過伺服器的錯誤日志，或者根本不知道錯誤日志的存在。絕大多數情況下，錯誤日志能夠精确地指出cgi錯誤的所在及如何修正這個錯誤。

apache的日志檔案（2）

定制日志

使用者可以使用日志格式指令控制日志檔案的資訊。在前面已經提到，在httpd.c "%a %l"指令，可以把發出http請求浏覽器的ip位址和主機名記錄到日志檔案。出于安全的考慮，至少應該驗證那些失敗的web使用者，在http.c "%401u"指令可以實作這個目的。這個指令還有其他的許多參數，使用者可以參考apache的文檔。另外，apache的錯誤日志檔案對于系統管理者來說也是非常重要的，錯誤日志檔案中包括伺服器的啟動、停止及cgi執行失敗等資訊。

apache在httpd.c

logformat "%h %l %u %t "%r" %>s %b" common

該指令建立了一種名為“comm

下面是格式串的可用的變量及含義。

l %...a：遠端ip位址。

l %...a：本地ip位址。

l %...b：已發送的位元組數，不包含http頭。

l %...b：clf格式的已發送位元組數量，不包含http頭。例如當沒有發送資料時，寫入“-”而不是0。

l %...{foobar}e：環境變量foobar的内容。

l %...f：檔案名字。

l %...h：遠端主機。

l %...h：請求的協定。

l %...{foobar}i：foobar的内容，發送給伺服器的請求的标頭行。

l %...l：遠端登入名字（來自identd，如提供的話）。

l %...m：請求的方法。

l %...{foobar}n：來自另外一個子產品的注解“foobar”的内容。

l %...{foobar}o：foobar的内容，應答的标頭行。

l %...p：伺服器響應請求時使用的端口。

l %...p：響應請求的子程序id。

l %...q：查詢字元串（如果存在查詢字元串，則包含“?”後面的部分；否則，它是一個空字元串）。

l %...r：請求的第一行。

l %...s：狀态。對于進行内部重定向的請求，這是指原來請求的狀态。如果用“%...>s”，則是指後來的請求。

l %...t：以公共日志時間格式表示的時間（或稱為标準英文格式）。

l %...{format}t：以指定格式format表示的時間。

l %...t：為響應請求而耗費的時間，以秒計。

l %...u：遠端使用者（來自auth；如果傳回狀态（%s）是401則可能是僞造的）。

l %...u：使用者所請求的url路徑。

l %...v：響應請求的伺服器的servername。

l %...v：依照usecan

在所有上面列出的變量中，“...”表示一個可選的條件。如果沒有指定條件，則變量的值将以“-”取代。分析前面來自預設httpd.c

有時候使用者隻想在日志中記錄某些特定的、已定義的資訊，這時就要用到“...”。如果在“%”和變量之間放入了一個或者多個http狀态代碼，則隻有當請求傳回的狀态代碼屬于指定的狀态代碼之一時，變量所代表的内容才會被記錄。例如，如果使用者想要記錄的是網站的所有無效連結，那麼可以使用下列指令：

logformat %404{referer}i brokenlinks

反之，如果想要記錄哪些狀态代碼不等于指定值的請求，隻需加入一個“!”符号即可。

日志分析

盡管日志檔案中包含着大量有用的資訊，但這些資訊隻有在經過深入挖掘之後才能夠最大限度地發揮作用。

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

有許多資訊可以用日志檔案來記錄，其中包括下列内容。

l 遠端主機的位址

“遠端主機的位址”和“誰在浏覽網站”差不多，但并不等同。具體地說，遠端主機的位址顯示了浏覽者來自何方，比如它可能是bright.hacker.com.cn或者suying.pcfriend.com.cn。

l 浏覽時間

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

l 使用者所通路的資源

網站的哪些部分最受使用者歡迎？這些最受歡迎的部分就是應該繼續加以發展的部分。網站的哪些部分總是受到冷落？網站中這些受到冷落的部分或許隐藏得太深，或許确實沒有什麼意思，此時就得想辦法加以改進。當然，網站中的一些内容，比如法律上的聲明，雖然很少有人通路，但卻不應該随便地改動它們。

l 無效連結

日志檔案還能夠顯示哪些東西不能按照使用者所想像的那樣運作。網站中是否存在錯誤的連結？其他網站連結過來時有沒有接錯url？是否存在不能正常運作的cgi程式？是否有搜尋引擎檢索程式每秒發出數千個請求，進而影響了本網站的正常服務？這些問題的答案都可以從日志檔案中找到線索