最近參與了了乙個日誌和告警的資料探勘專案，裡面用到的一些思路在這裡和大家做乙個分享。
專案的需求是收集的客戶系統乙個月300g左右的的日誌和告警資料做乙個整理，主要是歸類(grouping)和關聯(correlation)，從而得到告警和日誌的一些統計關係，這些統計結果可以給一線支援人員參考。
得到的資料主要分為兩部分，一部分是告警的歷史資料，這部分資料很少，只有50m左右，剩下的全部都是日誌資料。日誌資料大概有50多種不同型別，對應系統中不同的模組。每種型別的檔案每天產生乙個日誌檔案，所以總數大概是1500個左右的日誌檔案。檔案大概都是這樣的：a_2016-04-15.log, b_2016-04-15.log, ..., a_2016-05-14.log, b_2016-05-14.log。每個檔案在10m-1g之間不等。
通過檢視日誌，發現所有的log每一行基本都是類似這樣的pattern:
yyyy-mm-dd hh:mm:ss [模組名] [具體日誌]
每類日誌的模組名都是一樣的，基本可以忽略。有價值的就是時間戳和具體日誌。
而且可以發現，很多日誌只是極少部分動態內容不同，在**中屬於同乙個位置的輸出，這些資料後面我們會分為一類資料。比如：
2016-04-26 00:30:38.795 55637 resourcemanager free ram (mb): 244736
2016-04-26 00:34:38.795 55637 resourcemanager free ram (mb): 244748
有某些型別日誌每個時段都有出現，諮詢後得知基本沒有任何分析價值，這些日誌後面我們會加入黑名單，不加分析。
由於每類日誌都有30個檔案，每個檔案基本都有100萬行，我們的第一步工作就是去除上面提到的無用日誌。去掉無用日誌後，我們要分析的日誌大概減少了30%。
接著我們要做的就是每一行的日誌進行歸類（grouping）。這裡有很多的方法可以選擇，比如k-means，但是我們這麼多的日誌，很難去定義乙個合適的k。經過一番嘗試後我們放棄了k-means。但是k-means的思想還是可以用的。最後我們使用的是啟發式的方法來歸類。
首先定下的基本思路是： 對於每一類檔案，我們分別做歸類，最後再一起和告警檔案做關聯（crrelation）。我們作了不同類別檔案的日誌肯定不在一類的假定。
對於每一類檔案的每一行日誌，我們我們通過對具體日誌的字串的相似度進行歸類，演算法如下：
1）初始化將最終類別陣列設定為空，類別陣列的每一行的格式是 [index] [類別裡第一次出現的具體日誌內容] [該類日誌出現的所有時間形成的陣列]
2）初始化字串相似度閾值，相似度超過閾值的字串即為一類。專案裡面我們相似度閾值取80%。
3）初始化歸類的時間間隔，在乙個時間間隔內的相似日誌僅僅記錄一次時間。也就是說如果某類日誌已經有這段時間的記錄，再次在這段時間出現的類似日誌將會被忽略。取的過大，後面關聯時精確度降低，取的過小，後面關聯時計算量會很大。專案裡我們取10分鐘作為日誌間隔。也就是一天劃分成了24*6個時間間隔。
4）對於某一種類別， 對於每一行的具體日誌我們去和該類別的最終類別陣列的每一行的具體日誌做相似度比較：
a) 如果和最終類別裡的某行具體日誌的字串的相似度超過了閾值，則這兩個字串即歸為一類，僅僅把這個要分析的具體日誌的時間點存入該類別，停止該行日誌的分析。
b) 如果和最終類別裡的任何一行具體日誌的字串的相似度都低於閾值。則我們發現了乙個新的類別。在最終類別裡加入一行記錄。並把該日誌的時間間隔對應的點作為該類別的時間陣列的第一條時間記錄。
5） 對於所有其他的類別，分別執行上面的第4步。得到所有類別的最終類別陣列。最終我們的50多個類別陣列一共只剩下100多m，每個陣列平均有100多種類別。
這個演算法產生的類別陣列中每一行是這樣的內容：
1 resourcemanager free ram (mb): 244736 [[2016-04-26 00:30],[2016-04-26 10:40], ...]
上面的演算法中，我們用到了字串相似度演算法。這裡我們用到是python的字串下相似度演算法庫：python-levenshtein。計算相似度我們用了python-levenshtein庫的ratio函式，即萊文斯坦比。如果大家對python-levenshtein的字串相似度計算有興趣，可以參考python-levenshtein的官方文件：
現在我們有了50多種日誌的類別資料，每個類別也有在時間分布上的資料，同時，回到告警，每個告警也有在時間分布上的資料。現在我們可以在時間維度上做關聯演算法。
我們的日誌類別陣列和告警在時間維度一共有30*24*6=4320個點。我們的目標是找到和每個告警在時間維度上關聯度比較高的一組日誌。這裡我們採用的是基於余弦相似度的演算法。我們選擇了所有的和告警在時間維度上相似度超過80%的日誌類別。這些類別作為最終的統計結果作為我們輸出的一部分。
這部分工作主要是研究告警和告警之間的統計關係。主要是基於統計的在時間維度上的父子關係。
由於告警資料較少，我們將時間間隔精確到1分鐘。對於每一種告警，我們檢查在該告警和其他告警在時間維度上的關係。我們檢查3種情況。
第一種情況是在相同時間間隔出現的兄弟告警和該告警的統計關係，我們選擇在時間維度上和該告警相似度超過80%的所有告警，這些告警和該告警有時間上同步的關係，也就是這些告警統計上總是和該告警同時出現。
第二種情況是在該告警出現前一分鐘內的所有父親告警和該告警的關係，我們選擇在時間維度上和該告警相似度超過80%的所有告警，這些告警和該告警有時間上先後的關係，也就是這些告警統計上總是在該告警之前出現。
第三種情況是在該告警出現後一分鐘內的所有兒子告警和該告警的關係，我們選擇在時間維度上和該告警相似度超過80%的所有告警，這些告警和該告警有時間上先後的關係，也就是這些告警統計上總是在該告警之後出現。
功能和效能測試經驗談
可以說，誰掌握了功能測試和效能測試的精髓，誰就能在測試外包市場中佔據技術制高點。本文正是為這類軟體服務型企業出謀劃策 提供測試技術決策參考。雖然功能測試是絕大多數軟體都無法迴避的，但多數開發企業不諳其中滋味，所以，測試外包市場才會如此繁榮而且規模日益壯大。目前，功能測試已跨越了單靠手工敲敲鍵盤 點點...
主資料管理經驗談
主資料管理經驗談 2005.08.29 來自 zdnet 在公司中，主資料管理系統 mdms 的主要作用在於可以有乙個單一的系統作為所有公有資料項的乙個參考點。在剛剛過去的一年中，builder.com公司一直沒有很好的解決帶有多個客戶端的主資料的管理問題，為此，根據我的經驗，針對這個問題我為他們寫...
資料庫設計經驗談 下
資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...