網絡技術是從1990年代中期發展起來的新技術,它把互聯網上分散的資源融為有機整體,實現資源的全面共享和有機協作,使人們能夠透明地使用資源的整體能力并按需獲取信息。資源包括高性能計算機、存儲資源、數據資源、信息資源、知識資源、專家資源、大型數據庫、網絡、傳感器等。 當前的互聯網只限于信息共享,網絡則被認為是互聯網發展的第三階段。 {2} 日志的輪循機制:讓我們關心一下數據源問題:webalizer其實是一個按月統計的工具,支持增量統計:因此對于大型的服務,我可以按天將apache的日志合并后送給webalizer統計。WEB日志是如何按天(比如每天子夜00:00:00)截斷呢? 如果你每天使用crontab:每天0點準時將日志備份成accesserials_log_yesterday mv /path/to/apache/log/accesserials_log /path/to/apache/log/accesserials_log_yesterday 的話:你還需要:馬上運行一下:apache restart 否則:apache會因為的日志文件句柄丟失不知道將日志記錄到哪里去了。這樣歸檔每天子夜重啟apache服務會受到影響。 比較簡便不影響服務的方法是:先復制,后清空 cp /path/to/apache/log/accesserials_log /path/to/apache/log/accesserials_log_yesterday echo >/path/to/apache/log/accesserials_log 嚴肅的分析員會這樣做發現一個問題: 但cp不可能嚴格保證嚴格的0點截斷。加入復制過程用了6秒,截斷的accesserials_log_yesterday日志中會出現復制過程到00:00:06期間的日志。對于單個日志統計這些每天多出來幾百行日志是沒有問題的。但對于多個日志在跨月的1天會有一個合并的排序問題: [31/Mar/2002:59:59:59 +0800] [31/Mar/2002:23:59:59 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] 要知道[01/Apr/2002:00:00:00 這個字段是不可以進行“跨天排序”的。因為日期中使用了dd/mm/yyyy,月份還是英文名,如果按照字母排序,很有可能是這樣的結果:排序導致了日志的錯誤 [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [01/Apr/2002:00:00:00 +0800] [31/Mar/2002:59:59:59 +0800] [31/Mar/2002:59:59:59 +0800] [31/Mar/2002:23:59:59 +0800] [31/Mar/2002:59:59:59 +0800] [31/Mar/2002:23:59:59 +0800] 這些跨天過程中的非正常數據對于webalizer等分析工具來說簡直就好像是吃了一個臭蟲一樣,運行的結果是:它可能會把前一個月所有的數據都丟失!因此這樣的數據會有很多風險出現在處理上月最后一天的數據的過程中。 問題的解決有幾個思路: 1 事后處理: 所以一個事后的處理的方法是:用grep命令在每月第1天將日志跨月的日志去掉,比如: grep -v "01/Apr" accesserials_log_04_01 > accesserials_log_new 修改SORT后的日志:所有跨天的數據去掉。也許對日志的事后處理是一個途徑,雖然sort命令中有對日期排序的特殊選項 -M(注意是:大寫M),可以讓指定字段按照英文月份排序而非字母順序,但對于apache日志來說,用SORT命令切分出月份字段很麻煩。(我嘗試過用 "/"做分割符,并且使用“月份” “年:時間”這兩個字段排序)。雖然用一些PERL的腳本肯定可以實現,但最終我還是放棄了。這不符合系統管理員的設計原則:通用性。 并且你需要一直問自己:有沒有更簡單的方法呢?還有就是將日志格式改成用TIMESTAMP(象SQUID的日志就沒有這個問題,它的日志本身就是使用TIMESTAMP做時間時間戳的),但我無法保證所有的日志工具都能識別你在日期這個字段使用了特別的格式。 2 優化數據源: 最好的辦法還是優化數據源。將數據源保證按天輪循,同一天的日志中的數據都在同一天內。這樣以后你無論使用什么工具(商業的,免費的)來分析日志,都不會因為日志復雜的預處理機制受到影響。 首先可能會想到的是控制截取日志的時間:比如嚴格從0點開始截取日志,但在子夜前1分鐘還是后一分鐘開始截取是沒有區別的,你仍然無法控制一個日志中有跨2天記錄的問題,而且你也無法預測日志歸檔過程使用的時間。 因此必須要好好考慮一下使用日志輪循工具的問題,這些日志輪循工具要符合: 1 不中斷WEB服務:不能停apache=>移動日志=>重啟apache 2 保證同一天日志能夠按天輪循:每天一個日志00:00:00-23:59:59 3 不受apache重啟的影響:如果apache每次重啟都會生成一個新的日志是不符合要求的 4 安裝配置簡單 網絡的神奇作用吸引著越來越多的用戶加入其中,正因如此,網絡的承受能力也面臨著越來越嚴峻的考驗―從硬件上、軟件上、所用標準上......,各項技術都需要適時應勢,對應發展,這正是網絡迅速走向進步的催化劑。 |
溫馨提示:喜歡本站的話,請收藏一下本站!