日誌分析與我之緣
——日誌分析(new-access-log)專案開發的總結
日誌分析是我接觸比較深的，從開始專案經理提出需求，評審，相關主管構思其可行性，並對實現其功能所需的技術進行佈線，我都有所參與。
那時才參加工作不久，專案經驗嚴重不足，對於主管開發任務的描述，我理解的似是而非，總是在開發中摸索，在摸索中前行。當時一心完成主管安排的任務就行，沒有什麼執行效率、效能優化等概念，對於開發中會出現的問題也沒有乙個清晰的認識，在領導的推動中，我渾渾噩噩的完成了這項開發任務。
總得來說，我的任務是完成模組訪問統計和使用者模組訪問統計，遇到了幾個承需解決的問題：
1.訪問url的子父級關係的遞迴疊加；
2.訪問url對帶引數的url的同一url和子父級關係之間的界定定義；
3.大規模操縱資料庫，對資料庫的影響，以及如何合理的使用cpu資源。
這幾個問題在磕磕絆絆中解決了，其中大規模操縱資料庫，任務執行緒池的使用，使系統cpu資源得到大規模提高，但是在更多時候，壓力集中於資料庫，資料庫併發激增，仍然存在。
隨後我擔任日誌分析的運維，進行cmp和商用車親情服務的日誌分析，給其季度報告提供一定的資料支援。在此過程中，又陸陸續續發現一些問題:
1.在整個分析過程中，主要壓力集中於資料庫，在高峰期，資料庫的cpu使用率達到700%(8核cpu);
2.在應用流量統計中，需要讀取並執行awstats的配置檔案，由於多執行緒執行，該檔案被第乙個進行的執行緒占用，導致其他執行緒訪問該檔案，會報出此檔案不存在的異常；
3.在cmp日誌分析中，由於模組對映表中定義的url是一些url的父級url，而這些父級url本身又不是頁面，所以其頁面停留時間統計的沒有任何資料，一度以為是生成環境的日誌分析專案出現問題，經過梳理才發現其問題根源；
4.通過awstats分析日誌，該軟體對日誌的分析能力有一定的限制，即只能分析乙個節點固定一天的日誌，而cmp有八個節點，會產生八份日誌，所以其統計的資料僅僅只是真實資料的1/8。
隨著業務的調整，一次性上傳大量的日誌檔案，需要耗費大量的時間，從節約人力成本的角度出發，對日誌分析進行一定程度的公升級更新，最大程度的節約運維的人力成本。其相關功能最大的改變就是由人力上傳日誌檔案然後分析，變成現在的定時從掛載的日誌檔案機器上讀取檔案，然後分析，考慮到會出現一些異常，增加一段時期內的日誌分析和日誌分析出現異常後的強制分析。
在主管提出相應需求之後，我和同事編寫了<《日誌分析公升級更新》概要設計說明書》,在主管確認之後，我將概要設計說明書以及以前日誌分析的完整專案發給業務方，讓其進行開發，我負責聯絡跟進，在一定程度上扮演著專案經理的角色，雖然這是乙個很小的專案。
在負責跟進此專案時，由於經驗嚴重欠缺，對於專案開發遇到問題的複雜性沒有乙個清晰的認識，導致出現了很多錯誤，對專案開發的進度、專案的部署都產生了很大程度上的消極影響。
遇到的問題主要有：
1.在溝通過程中，針對某一問題，臨時安排業務方按照要求去做，沒有形成文件或者保留文本性資料，導致其忘記，造成其業務過錯的推諉；
2.在開發過程中，針對某一里程碑事件，沒有較為清晰的定義，沒有進行合理的規劃，放羊式的專案管理導致開發進度拖沓；
3.在專案的審查上，沒有進行嚴格的階段性的專案驗收，在沒有看到其開發成果的前提下，只聽其描述就認為其完成了相應的開發任務，結果在專案最終的測試中，開發過程中的問題井噴式爆發，在很短時間內，出現超過20個較為嚴重的bug；
4.對於專案驗收沒有進行比較清晰的定義，只是依著感覺，可以接受就讓其合格，沒有乙個可行性文字描述性的標準。
在部署執行之後，仍然出了一定的問題，由於需要記錄每批次日誌分析的結果，需要將之前的多執行緒執行應用改為單執行緒應用執行緒，而單執行緒對於資料庫持續操作，分析三天(3*8)的日誌24小時之內都不能完成。隨後考慮引入快取機制，儘量減少資料庫壓力，同一批次的分析結果，暫時存入快取，在分析結束後，一次性存入資料庫中。
目前，正在除錯其各項效能，有幾個變數，本地快取、遠端快取、入庫的時機選擇、定時排程的執行頻率等幾個事件的組合。目前在使用的是只使用本地快取+每天的日誌分析結束後入庫(8個日誌)+定時排程日誌分析頻率為沒兩天一次。
這個選擇充分考慮了效能優化，適用節約的特徵，由於分析本地的日誌沒有遠端的呼叫，只使用本地快取就可以滿足要求，快取中資料量越大，快取的讀取耗時越長，考慮到這一因素，將之前的同一批次的一次性入庫改為一天的日誌一次性入庫，這樣可以加快快取中讀寫的速率，cmp7天歸檔一次，考慮其日誌規模，大致在兩天的時間可能分析完畢。
目前，該專案處於部署除錯階段，估計還是陸續出現問題，勤記錄，多思考，善於總結分析，善於在複雜的環境中找到解決問題的關鍵，爭取較大的發展。
GC之CMS GC日誌分析
最近在學習jvm和gc調優,今天總結下cms的一些特點和要點,首先貼上乙個實際的cms gc log,先來解讀下各個元素。從下面的gc日誌可以看出,當前最新版本 jdk1.8 中的cms大致分為6步 1.cms initial mark 初始標記 2.cms concurrent mark 併發標記...
網路之緣，妙不可言
在很久很久以前，人們已經發現 緣份這個東西，真是妙不可言。很久很久以後，當他們在網上相見。再次印證了預言，經典就是經典。中國人口千千千萬，為何他會與她連線。是誰暗中操縱，聯接寂寞的繩。像天使手中的魔杖，像魔鬼臉上的笑容。在不知不覺中，將他們朝同乙個方向靠攏。當他在暗中雀躍，當她在悄悄慶幸，緣份卻又化...
分析nginx日誌指令碼之python
為了對每個月的切割過的 個日誌檔案統計出訪問最多的ip位址進行排序，整理了下面的指令碼，主要思路是處理每乙個日誌檔案的ip排序，最後進行字典合併，計算出月ip排序。usr bin env python import osimport sysimport commands import reipsor...