|
前段時(shí)間碰到這么樣一個(gè)事情，有封從外部組織發(fā)送到公司某客服賬戶的郵件，按預(yù)期，應(yīng)該根據(jù)傳輸規(guī)則，將此郵件復(fù)制一份并密抄給另一個(gè)郵箱賬戶，作為備份數(shù)據(jù)。但客服系統(tǒng)的管理員發(fā)現(xiàn)，出現(xiàn)了郵件丟失的情況。就是說(shuō)，按照預(yù)期會(huì)生成的郵件，沒(méi)有收到，導(dǎo)致客服系統(tǒng)，和備份賬戶中的郵件不一致。這個(gè)時(shí)候需要查看這封郵件的跟蹤日志，來(lái)確定郵件到底是在哪個(gè)過(guò)程中，丟失的。。郵件系統(tǒng)的管理員接到這件事情以后就開(kāi)始檢查，Exchange里面已經(jīng)做了郵件跟蹤日志，但結(jié)果發(fā)現(xiàn)不全，一個(gè)星期以前的，都沒(méi)有了。因?yàn)橹坝袀€(gè)習(xí)慣，就是定期將跟蹤日志拷貝出來(lái)保存在另外一個(gè)地方，進(jìn)行存檔。目的有兩個(gè)，一個(gè)是避免占用空間過(guò)多導(dǎo)致服務(wù)器資源緊張以及性能問(wèn)題。第二個(gè)原因就是一旦對(duì)郵件系統(tǒng)進(jìn)行備份，日志將會(huì)自動(dòng)清除，也就意味著使用exchange的管理工具，只能看到上次備份以來(lái)的郵件跟蹤信息。
關(guān)于這件事情，就不多說(shuō)了，反正最后的結(jié)果是，我們通過(guò)找到之前備份的郵件跟蹤日志，查出了問(wèn)題所在。但問(wèn)題解決之后，我有了一個(gè)想法。Exchange的跟蹤查詢工具，是可以滿足我們最基本的跟蹤查詢需求。但是限制因素很多，比如日志的路徑，文件類型的數(shù)據(jù)等。當(dāng)然，不排除像 塵封メ心 或者 cashcat 那樣的Exchange高手，可以通過(guò)很多手段，甚至PowerShell等專業(yè)工具來(lái)實(shí)現(xiàn)郵件的跟蹤查詢。。但是我想，如果能將跟蹤日志做成一個(gè)數(shù)據(jù)庫(kù)，是不是更好呢？比如放到SQL里面，大家都知道光是SQL的查詢，就可以做到非常豐富。還有報(bào)表服務(wù)，可以做出一個(gè)非常友好的查詢界面，供一些非IT專業(yè)人員來(lái)進(jìn)行查詢。如果需要更專業(yè)的分析，SQL還有一個(gè)強(qiáng)大BI功能，絕對(duì)滿足任何要求的查詢。甚至可以變態(tài)的分析出每天公司里面哪個(gè)男同事跟哪個(gè)女同事溝通最密切，他們的郵件都說(shuō)了什么。。
所以，我的想法就是，利用SQL強(qiáng)大的查詢、分析功能，實(shí)現(xiàn)對(duì)郵件的跟蹤。
根本的需求有了，下面就得對(duì)需求，進(jìn)行分析了。首先，把握住需求的核心對(duì)象，就是跟蹤日志，更準(zhǔn)確的說(shuō)，是某一條用于描述郵件傳遞過(guò)程的日志信息。。其次，要理清思路，想清楚整個(gè)信息傳遞的過(guò)程。這個(gè)過(guò)程，簡(jiǎn)單來(lái)說(shuō)的話，就是，最初的數(shù)據(jù)是生成于Exchange跟蹤日志目錄，然后需要被導(dǎo)入到SQL數(shù)據(jù)庫(kù)中，最后通過(guò)SQL查詢被檢索出來(lái)。。
對(duì)象搞清楚了，需要進(jìn)行處理的過(guò)程搞清楚了，下面就是搞清楚應(yīng)該怎么辦。第一，日志數(shù)據(jù)的生成，沒(méi)有問(wèn)題，Exchange本身就會(huì)生成.log的日志文件，或者配置Exchange啟用跟蹤日志功能。第二，將.log文件的內(nèi)容導(dǎo)入到SQL數(shù)據(jù)庫(kù)當(dāng)中，這一步是關(guān)鍵。第三，進(jìn)行信息檢索，這個(gè)也不是問(wèn)題，SQL很容易被查詢。所以，整件事情的唯一需要做的，就是把.log的文件內(nèi)容導(dǎo)入到SQL中。
這里我就不Step-by-Step的講怎么一步一步操作的了，因?yàn)檎麄€(gè)過(guò)程相對(duì)來(lái)說(shuō)，步驟還是很多的。我這里就簡(jiǎn)單介紹一下如何實(shí)現(xiàn)的，只要大家對(duì)SQL有基本實(shí)際經(jīng)驗(yàn)，應(yīng)該都不是問(wèn)題。
先來(lái)用一句話概括：通過(guò)SQL的BCP語(yǔ)句，實(shí)現(xiàn)數(shù)據(jù)的批量導(dǎo)入。。當(dāng)然，前提是要先建表，.log文件中的每個(gè)列，作為表的列，就可以了。
BCP語(yǔ)句的語(yǔ)法，可以查SQL的聯(lián)機(jī)叢書，或者微軟的TechNet網(wǎng)站進(jìn)行查詢，語(yǔ)法還是很簡(jiǎn)單的。我就不多介紹了，這里我只把我用到的貼上來(lái)。。
bcp ExchangeLogs.dbo.[MessageTracking] in "D:\Exchange Logs\Unicode\MSGTRK20100703-1.txt " -T -Slocalhost -t, -r\n -w -e"D:\Exchange Logs\Bulkinsert\error_MSGTRK20100703-1.txt"
看起來(lái)很簡(jiǎn)單吧？但是我還是碰了很多釘子。。所以，我覺(jué)得比寫Step-by-Step的步驟更重要的事情，是把我遇到的這些釘子拔出來(lái)給大家看看。
釘子一：文件格式
有心的朋友可能已經(jīng)看到上面的BCP命令當(dāng)中，是“MSGTRK20100703-1.txt”而不是“.log”的。更有心的，可能發(fā)現(xiàn)路徑里面有個(gè)Unicode的文件夾。這都不是意外啊，這就是最大的一顆釘子。
其實(shí)SQL DB本身就支持從某個(gè)文本中批量的導(dǎo)入數(shù)據(jù)，可以直接用Studio的圖形界面，也可以用“bulk insert”，或者是我用到的BCP命令。但是我碰到了一個(gè)頭疼的問(wèn)題就是，死活數(shù)據(jù)導(dǎo)入不成功，各種方式都用過(guò)了。后來(lái)發(fā)現(xiàn)，Exchange自動(dòng)生成的.log文件，文字編碼是使用的UTF-8標(biāo)準(zhǔn)，而SQL報(bào)錯(cuò)說(shuō)不支持。。怎么辦？答案是，轉(zhuǎn)！
先轉(zhuǎn)格式。。一個(gè)很土的辦法就是，用記事本打開(kāi)log文件，然后什么別改，直接另存為.txt，注意這時(shí)有個(gè)“編碼”選項(xiàng)，記得要選成“Unicode”。。但是這個(gè)土辦法，轉(zhuǎn)一個(gè)兩個(gè)還行，一個(gè)Exchange環(huán)境運(yùn)行個(gè)幾年下來(lái)。。那得有多少.log文件??？所以說(shuō)土嘛。。那怎么樣能夠批量的進(jìn)行編碼轉(zhuǎn)換呢？
釘子二：批量進(jìn)行格式轉(zhuǎn)換
附件里有個(gè)工具，是網(wǎng)上下載的，怕有毒的，就自個(gè)去找Google它老人家要吧。。批量轉(zhuǎn)格式的方法，我相信不止一種，我也相信這個(gè)工具絕對(duì)不是最好的，如果哪個(gè)以后找到更好的，記得回來(lái)通報(bào)一下。。
因?yàn)檫@個(gè)工具，確實(shí)是個(gè)小工具，經(jīng)不起大的工作量。我第一次的時(shí)候，一次性選了一個(gè)文件夾，大概4G左右的日志，有好幾百個(gè).log文件吧。。結(jié)果小工具直接罷工了，試了好幾次，終于摸出門路來(lái)了。。一次選的，不能太多，1G左右的量最好，要不然就把它撐爆了。。呵呵。。
釘子三：生成.bat腳本
經(jīng)過(guò)幾個(gè)回合，我的所有的UTF-8編碼的.log文件，都被轉(zhuǎn)成了Unicode編碼的.txt文件。剩下的，就是往SQL里面導(dǎo)入了。土人的做法是，一次一次的在CMD里面運(yùn)行BCP的這個(gè)命令（題外話：記住，那個(gè)叫CMD，命令提示符，不要再說(shuō)是DOS了，很土的），每次都把另外一個(gè)文件名復(fù)制到上一次運(yùn)行的命令參數(shù)里面，修改掉之前的。
那么多的文件，一次一次運(yùn)行，會(huì)死人的啊。。于是出現(xiàn)了一個(gè)神人，他主張用.bat腳本，把這條命令在一個(gè)TXT文本里面復(fù)制個(gè)萬(wàn)八千行的，一次執(zhí)行完所有命令。這時(shí)又面臨一個(gè)問(wèn)題，就是腳本里面，每一行當(dāng)中的那個(gè)文件名，都是不一樣的，這時(shí)他想到一行一行修改文件名。。但是，如果面對(duì)成千上萬(wàn)個(gè)文件，就意味著要Copy上萬(wàn)次文件名。。所以說(shuō)，能干出這事的，都是神人啊。
那我們不是神，是人，是人就會(huì)使用工具，這時(shí)我們想到了Excel。利用Excel的文本函數(shù)，可以很方便的將一排文字，切割成幾列，然后修改其中一列，最后再組合成一個(gè)完整的文本內(nèi)容。。
如果非要知道怎么做，可以參考這里《巧用Excel函數(shù)，簡(jiǎn)化批量導(dǎo)入AD用戶及密碼修改》 http://bisheng.blog.51cto.com/409831/182286 ，雖然內(nèi)容不一樣，但異曲同工，靈活運(yùn)用嘛。
好，三顆釘子拔完，此事基本搞定。其實(shí)，其間也走過(guò)一些彎路，一些回頭路，還有好多小的釘子。反正最終，成功的將.log文件的內(nèi)容，導(dǎo)入到了SQL數(shù)據(jù)庫(kù)當(dāng)中。后面的事情就好說(shuō)了，我試過(guò)select語(yǔ)句，還是很好用的，而且把幾個(gè)常用查詢語(yǔ)句保存了下來(lái)。
其實(shí)，關(guān)鍵是，只要數(shù)據(jù)進(jìn)入到SQL，后面就都好辦了。無(wú)論是查詢語(yǔ)句，報(bào)表，甚至是BI，能夠?qū)⑧]件跟蹤的分析做到什么樣一種高度，就看你對(duì)SQL的研究深度了。
再說(shuō)說(shuō)遺憾。。遺憾的事情就是，這所有的過(guò)程，除了Exchange或者SQL本身可以完成的工作以外，其他的操作，必須由人手動(dòng)完成。。只不過(guò)我們是用了一些自動(dòng)化的方式，進(jìn)行了一些批量的處理，簡(jiǎn)化了一些工作量而已。。真正的全自動(dòng)化的過(guò)程，還需要進(jìn)一步完善。當(dāng)然，再想進(jìn)一步，光靠SQL已經(jīng)是不夠了。。
最后，我再展望一下，如果希望做到全自動(dòng)化，至少有幾個(gè)方面的問(wèn)題需要解決。
第一，需要對(duì)Exchange生成日志的那個(gè)目錄做監(jiān)控，一旦發(fā)現(xiàn)有日志生成，自動(dòng)將其進(jìn)行轉(zhuǎn)化。當(dāng)然具體的過(guò)程，可能還需要考慮是否先判斷文件已寫完，或者考慮先復(fù)制到另一文件夾，再做處理。
第二，文件格式的轉(zhuǎn)換，就不能用我們那個(gè)小工具了，必須通過(guò)標(biāo)準(zhǔn)的文字編碼轉(zhuǎn)換方式進(jìn)行。
第三，需要自動(dòng)的出發(fā)SQL的數(shù)據(jù)導(dǎo)入進(jìn)程，并校驗(yàn)整個(gè)過(guò)程中的完整性和正確性。
如果能做到這三個(gè)方面的自動(dòng)化處理，基本上，就完美了。
可能有人此時(shí)聽(tīng)得有點(diǎn)犯暈，也可能有人已經(jīng)有所感悟。。這不就是數(shù)據(jù)交換么？這不就是中間件么？這不就是Biztalk么？？
人云：查詢個(gè)日志，把Biztalk都請(qǐng)出來(lái)了？？殺雞焉用牛刀呼？？我曰：閑來(lái)之時(shí)，可以一試。。
全文完。。。^_^....
|
|
|
來(lái)自： 看見(jiàn)就非常 > 《server》
