① 榪炴帴涓婃湇鍔″櫒鍦ㄦ湇鍔″櫒涓婄殑鎿嶄綔鏈夋病鏈夎板綍鐨
鏈夌殑錛 鍙瑕佹病鏈変笓闂ㄨ劇疆鏃ュ織鐨勮瘽錛
鍦ㄧ郴緇熸棩蹇椾腑鍙浠ョ湅鍒版搷浣滅殑鐩稿叧璁板綍鐨勶紒錛
浣嗘槸鍙鑳戒笉涓瀹氬緢鍏
② linux查看歷史操作記錄
在linux系統的環境下，不管是root用戶還是其它的用戶只有登陸系統後用進入操作我們都可以通過命令history來查看歷史記錄，可是假如一台伺服器多人登陸，一天因為某人誤操作了刪除了重要的數據。這時候通過查看歷史記錄（命令：history）是沒有什麼意義了（因為history只針對登錄用戶下執行有效，即使root用戶也無法得到其它用戶histotry歷史）。那有沒有什麼辦法實現通過記錄登陸後的IP地址和某用戶名所操作的歷史記錄呢？答案：有的。
通過在/etc/profile裡面加入以下代碼就可以實現：
PS1="`whoami`@`hostname`:"'[$PWD]'
history
USER_IP=`who -u am i 2>/dev/null| awk '{print $NF}'|sed -e 's/[()]//g'`
if [ "$USER_IP" = "" ]
then
USER_IP=`hostname`
fi
if [ ! -d /tmp/dbasky ]
then
mkdir /tmp/dbasky
chmod 777 /tmp/dbasky
fi
if [ ! -d /tmp/dbasky/${LOGNAME} ]
then
mkdir /tmp/dbasky/${LOGNAME}
chmod 300 /tmp/dbasky/${LOGNAME}
fi
export HISTSIZE=4096
DT=`date "+%Y-%m-%d_%H:%M:%S"`
export HISTFILE="/tmp/dbasky/${LOGNAME}/${USER_IP} dbasky.$DT"
chmod 600 /tmp/dbasky/${LOGNAME}/*dbasky* 2>/dev/null
source /etc/profile 使用腳本生效
退出用戶，重新登錄
上面腳本在系統的/tmp新建個dbasky目錄，記錄所有登陸過系統的用戶和IP地址（文件名），每當用戶登錄/退出會創建相應的文件，該文件保存這段用戶登錄時期內操作歷史，可以用這個方法來監測系統的安全性。
root@zsc6:[/tmp/dbasky/root]ls
10.1.80.47 dbasky.2013-10-24_12:53:08
root@zsc6:[/tmp/dbasky/root]cat 10.1.80.47 dbasky.2013-10-24_12:53:08
查看在12:53:08從10.1.80.47登錄的root用戶操作命令歷史
③ 如何查看mysql資料庫操作記錄日誌
1、首先確認你日誌是否啟用了mysql>show variables like 'log_bin'。
2、如果啟用了，即ON，那日誌文件就在mysql的安裝目錄的data目錄下。
3、怎樣知道當前的日誌mysql> show master status。
4、看二進制日誌文件用mysqlbinlog，shell>mysqlbinlog mail-bin.000001或者shell>mysqlbinlog mail-bin.000001 | tail，Windows 下用類似的。
④ 如何查看及分析網站IIS日誌文件
1、進入伺服器的管理之後，打開「Internet 信息服務(IIS)管理器」，
2、雙擊信息服務(IIS)管理器，進入管理以後打開信息服務(IIS)管理器，選中要查看的網站，在網站欄目那裡右鍵單擊，選擇「屬性」，
3、在彈出的窗口裡面，點擊「網站」欄目，查看日誌記錄中的「屬性」，
4、通過日誌記錄屬性欄目，即可看到日誌文件目錄了，
上面的日誌文件目錄即是iis的文件存放位置了，IIS日誌文件便在C:\WINDOWS\system32\LogFiles\文件夾內。
IIS日誌文件存儲格式是後綴名為log的文本文件，如下面這些文件就是網站的iis日誌了。
要查看對應站點的IIS日誌，只需要打開對應IIS日誌文件夾找到相對應日誌文件即可，也可藉助IIS日誌分析工具提供查看IIS日誌的效率！
三、如何分析IIS日誌？
知道了IIS日誌的位置了，也看到了IIS日誌的文件了，接下來我們就應該對日誌文件進行分析了，那麼，我們該如果分析IIS日誌呢？
1、如何查看IIS日誌信息
IIS日誌可以用IIS日誌分析工具去大概的去查一查，一般工具都能查出有各種蜘蛛來到網站的總數，以及有沒有失敗，不會把各種的信息都給你，工具分析只是簡單的告訴你一個概況，馬海祥在此就拿出一條信息來為大傢具體的分析一下，如下面的截圖所示：
我們可以分段對這個IIS日誌進行分析：
2010-10-22 05：04：53 表示的是時間；
W3SVC151800 P-0YMR9WW8YX4U9是機器編號；
222.76.213.49為網站的IP；
GET是觸發事件；
80是埠號；
61.135.186.49是搜索引擎蜘蛛的IP；
Baispider是網路的蜘蛛（另外，谷歌蜘蛛：Googlebot；360搜索蜘蛛：360Spider，更多的可查看馬海祥博客《解讀iis日誌中搜索引擎蜘蛛名稱代碼及爬尋返回代碼》的相關介紹）；
200 0 0是訪問成功的返回代碼；
41786 193 6968是蜘蛛與網站對話的時間與下載的數據以及花了多少時間。
連在一起就是2010.10.22的早上5點4分53秒的時候一個編號為W3SVC151800 P-0YMR9WW8YX4U9的蜘蛛通過80埠進入網站成功訪問並下載了47186B的數據，花費了193MS。
2、用excel表格分析網站的iis日誌
先新建一個excel表格，把剛才的ex121129.log文件里的文件粘貼到新建的excel表格裡面，，如下圖所示：
復制之後，選定A，在工具欄里選擇數據→分列，如下圖所示：
選擇分隔符號，點擊下一步：
選擇空格，去掉Tab鍵前面的鉤，點擊完成，如下圖所示：
網站的iis日誌就這樣被拆分出來了，之後自己再調整一下表格的列寬、升降序等即可。
四、詳解IIS日誌參數
一般情況下，IIS日誌文件代碼格式如下所示：
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2009-11-26 06:14:21
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2009-11-26 06:14:21 W3SVC692644773 125.67.67.* GET /index.html - 80 - 123.125.66.130 Baispider+(+http://www..com/search/spider.htm) 200 0 64
2009-11-26 06:14:21 W3SVC692644773 125.67.67.* GET /index.html - 80 - 220.181.7.116 Baispider+(+http://www..com/search/spider.htm) 200 0 64
在此，馬海祥也為大家詳細的解說一下IIS日誌參數：
date：發出請求時候的日期。
time：發出請求時候的時間，注意：默認情況下這個時間是格林威治時間，比我們的北京時間晚8個小時，下面有說明。
c-ip：客戶端IP地址。
cs-username：用戶名，訪問伺服器的已經過驗證用戶的名稱，匿名用戶用連接符-表示。
s-sitename：服務名，記錄當記錄事件運行於客戶端上的Internet服務的名稱和實例的編號。
s-computername：伺服器的名稱。
s-ip：伺服器的IP地址。
s-port：為服務配置的伺服器埠號。
cs-method：請求中使用的HTTP方法，GET/POST。
cs-uri-stem：URI資源，記錄做為操作目標的統一資源標識符（URI），即訪問的頁面文件。
cs-uri-query：URI查詢，記錄客戶嘗試執行的查詢，只有動態頁面需要URI查詢，如果有則記錄，沒有則以連接符-表示，即訪問網址的附帶參數。
sc-status：協議狀態，記錄HTTP狀態代碼，200表示成功，403表示沒有許可權，404表示找不到該頁面，具體說明在下面。
sc-substatus：協議子狀態，記錄HTTP子狀態代碼。
sc-win32-status：Win32狀態，記錄Windows狀態代碼。
sc-bytes：伺服器發送的位元組數。
cs-bytes：伺服器接受的位元組數。
time-taken：記錄操作所花費的時間，單位是毫秒。
cs-version：記錄客戶端使用的協議版本，HTTP或者FTP。
cs-host:記錄主機頭名稱，沒有的話以連接符-表示。馬海祥提醒大家注意：為網站配置的主機名可能會以不同的方式出現在日誌文件中，原因是HTTP.sys使用Punycode編碼格式來記錄主機名。
cs(User-Agent)：用戶代理，客戶端瀏覽器、操作系統等情況。
cs(Cookie)：記錄發送或者接受的Cookies內容，沒有的話則以連接符-表示。
cs(Referer)：引用站點，即訪問來源。
五、搜索引擎蜘蛛爬尋返回代碼
HTTP協議狀態碼的含義，協議狀態sc-status，是伺服器日記擴展屬性的一項，下面是各狀態碼含義：
"100" ：Continue，客戶必須繼續發出請求。
"101" ：witching Protocols，客戶要求伺服器根據請求轉換HTTP協議版本。
"200" ：OK，交易成功。
"201" ：Created，提示知道新文件的URL。
"202" ：Accepted，接受和處理、但處理未完成。
"203" ：Non-Authoritative Information，返回信息不確定或不完整。
"204" ：No Content，請求收到，但返回信息為空。
"205" ：Reset Content，伺服器完成了請求，用戶代理必須復位當前已經瀏覽過的文件。
"206" ：Partial Content，伺服器已經完成了部分用戶的GET請求。
"300" ：Multiple Choices，請求的資源可在多處得到。
"301" ：Moved Permanently，刪除請求數據。
"302" ：Found，在其他地址發現了請求數據。
"303" ：See Other，建議客戶訪問其他URL或訪問方式。
"304" ：Not Modified，客戶端已經執行了GET，但文件未變化。
"305" ：Use Proxy，求的資源必須從伺服器指定的地址得到。
"306" ：前一版本HTTP中使用的代碼，現行版本中不再使用。
"307" ：Temporary Redirect，申明請求的資源臨時性刪除。
"400" ：Bad Request，錯誤請求，如語法錯誤。
"401" ：Unauthorized，請求授權失敗。
"402" ：Payment Required，保留有效ChargeTo頭響應。
"403" ：Forbidden，請求不答應（具體可查看馬海祥博客《403 Forbidden錯誤的原因和解決方法》的相關介紹）。
"404" ：Not Found，沒有發現文件、查詢或URl（具體可查看馬海祥博客《404 Not Found錯誤頁面的解決方法和注意事項》的相關介紹）。
"405" ：Method Not Allowed，用戶在Request-Line欄位定義的方法不答應。
"406" ：Not Acceptable，根據用戶發送的Accept拖，請求資源不可訪問。
"407" ：Proxy Authentication Required，類似401，用戶必須首先在代理伺服器上得到授權。
"408" ：Request Time-out，客戶端沒有在用戶指定的餓時間內完成請求。
"409" ：Conflict，對當前資源狀態，請求不能完成。
"410" ：Gone，伺服器上不再有此資源且無進一步的參考地址。
"411" ：Length Required，伺服器拒絕用戶定義的Content-Length屬性請求。
"412" ：Precondition Failed，一個或多個請求頭欄位在當前請求中錯誤。
"413" ：Request Entity Too Large，請求的資源大於伺服器答應的大小。
"414" ：Request-URI Too Large，請求的資源URL長於伺服器答應的長度。
"415" ：Unsupported Media Type，請求資源不支持請求項目格式。
"416" ：Requested range not satisfiable，請求中包含Range請求頭欄位，在當前請求資源范圍內沒有range指示值，請求也不包含If-Range請求頭欄位。
"417" ：Expectation Failed，伺服器不滿足請求Expect頭欄位指定的期望值，假如是代理伺服器。
"500" ：Internal Server Error，伺服器產生內部錯誤。
"501" ：Not Implemented，伺服器不支持請求的函數。
"502" ：Bad Gateway，伺服器暫時不可用，有時是為了防止發生系統過載。
"503" ：Service Unavailable，伺服器過載或暫停維修。
"504" ：Gateway Time-out，關口過載，伺服器使用另一個關口或服務來響應用戶，等待時間設定值較長。
"505" ：HTTP Version not supported，伺服器不支持或拒絕支請求頭中指定的HTTP版本。