apache上跑的日誌一直沒有去管。基本就是一個文件走天下，好處在於不需要再去其它地方找了，找一個文件就好了
。問題在於日誌越來越大，打開查看就要好幾十分鐘了，要具體的查詢某一個時間點的日誌再去分析——這基本上屬於不可能的工作。So，這個工作到了必須要處理一下的時候了。
其實這個事情已經開始幾天了，但年紀大了學東西有點慢，又不願意搞個半懂不懂。所以可能會有點慢。分上下兩部分吧。
這一部分主要講配置和模板的格式分析。
一、最簡單的apache日誌設置。
直接在虛擬主機設置裏添加
ErrorLog "/路徑/error_log"
CustomLog "/路徑/access_log" common
即可針對每個虛擬主機設置單獨的日誌文件。
不過問題是，這還是僅僅是把單個虛擬主機的日誌從總體日誌裏分離出來，要具體管理還是不可能。
二、對日誌進行分割管理
apache提供了日誌管理程序rotatelogs，主要用來把日誌文件分割管理。
這個命令提供了兩種分割的方法，
第一種是按時間，以秒爲基準算的，86400就是一天。
第二種是以文件大小，給出的例子是5M。
正常情況下一般是採用日期對日誌進行管理的。所以在虛擬主機配置中加入以下的設置
ErrorLog "| /apache安裝路徑/bin/rotatelogs /路徑/%Y_%m_%d_error_log 86400 480"
CustomLog "| /apache安裝路徑/bin/rotatelogs /路徑/%Y_%m_%d_access_log 86400 480" common
%Y，%m，%d這三個都很明顯，分別表示的是年月日。
在86400後面的480其實是UTC的時間偏移量，畢竟我們的時區是東八區和日界線UTC時間差了八小時，如果沒有寫480，會按最原始的時候進行分割，這和我們要記錄的時間不一樣。這裏的時間單位是分鐘，8小時，即480分鐘。
common，其實是access_log的模板名稱。這個在http.conf文件裏有記錄。規定了access_log文件的記錄格式。如：
OK，保存好配置之後，重啓apche，對相對應的虛擬主機訪問一下，日誌文件就會產生了。
三、關於模板的解讀和access_log記錄的對照分析。
下面分析一下access_log和error_log兩個日誌的內容，畢竟日誌寫了如果看不懂基本等於無用功。
先access_log，沒別的，這個文件有一個默認模塊，識圖認字比較容易。
common模板（好吧。再出現一次）
如上所示。我們對上面八個選項逐個分析，分別是：
%h，%l，%u，%t，%r（不是\"%r\"，那兩個\其實就是轉譯符，兩個"是當字符出現的），%>s，%b
%h 主要顯示的是訪問的域名/IP，一般來說是IP地址
%l 遠程登錄的名字，不過是由identd提供，所以一般都是空
%u 登錄用戶，這個有可能不是空，但我沒見過
%t 這個是訪問時間
%r 這個是訪問的方法+資源+協議，有點難懂吧？等下看過日誌就明白了，不過看過之後更加不明白了。
%>s 內部重定向的請求，如果沒加>是原來的請求，加了>是後來的請求。比如200是確認的正常返回碼，404是頁面無法訪問
%b 已經發送的字節數（這個最好懂）
OK。進入日誌具體分析
115.236.140.12 - - [07/Jan/2016:11:21:41 +0800] "GET / HTTP/1.1" 200 1933
以此條日誌信息爲例，得出的日誌分析是
115.236.140.12 在 北京時間(+0800) 2016年1月07日，上午11:21:41 訪問了站點的 / 協議爲HTTP/1.1 請求狀態碼是200，已發送字節 1933。
這裏除了登錄用戶名（第三項）爲空之外（第二個遠程登錄名一般是由identd提供的郵箱，常年爲空，當不存在了），其它的都好理解，相對比較麻煩的就是 訪問的方法+資源+協議這項，即 "GET / HTTP/1.1" 。其實協議也好辦，最難理解的是第一個方法，這整個一項也是日誌最核心的東西——也就是對方到底做了什麼。
分析如下的日誌
第一行，其實是我對站點進行訪問——自然也就訪問了站點的 / ，所以這裏用方法是GET，因爲是訪問所以發出的字節是 1933
第二行，是我在頁面登錄，提交了登錄信息。這裏很奇怪沒有登錄用戶名，但可以看到方法已經變成了POST，訪問是資源是/index.php——其實就是在index.php。由於是提交所以發出的字節是0。（之前傳出的1933，應該就是index.php）
而登錄完成之後的日誌如下：
系統後來直接跳轉訪問的其它頁面陸續出來，不過用的也是方法GET。
不過方法GET並不僅僅表示系統對頁面的直接訪問和加載，其實更直接的是對某個頁面的直接訪問，這個無論是系統還是其它人爲。爲什麼這麼說？因爲網絡還是很危險的，某位朋友對我的服務器好像採取了摸魚式的掃描。
用的自然也是GET方法。當然，這些最後返回的全是404，網絡世界真可怕。
從這幾天的觀察，方法值在GET居多，POST時有，還出現CONNECT和HEAD，但是還出現了一個不知道什麼鬼的\x16\x03\x03\x03\x0c\x01。
現在POST和GET 方法內容基本清楚，CONNECT，HEAD還有\x16\x03\x03\x03\x0c\x01，以及還未出現的其它方法，估計要查詢之後再才能得出答案。
error_log
這個文件的格式是固定的，相對簡單一點
錯誤時間 錯誤類型 對方地址 具體的錯誤信息
前面這三個基本上一目瞭然，最關鍵的最後後的具體錯誤信息，一天之內找到了如下的幾個
File does not exist: 這種一般是找不到文件，後面接的一般是服務器內真實的絕對路徑。
script 'XXX.php' not found or unable to stat 這種和上面差不多都是找不到文件，但文件腳本本身是apache可以加載識別的
client denied by server configuration 這種錯誤一般和服務器的配置有關，錯誤都比較直接可以很快找到問題所在。但要明白的是，如果是配置過而錯誤，那是配置的問題；如果沒有配置還出現錯誤，那就是被人家掃描了。
還有兩個不知道什麼意思：
client sent HTTP/1.1 request without hostname
Invalid URI in request \x16\x03\x01\x03\x0c\x01
這一節大概到這裏吧。大概搞清了日誌的分割設置方法和基本的解讀。下一節分析一下模板的可選項，自己做一個模板然後是日誌的備份。