利用SQL數據庫，實現Exchange的郵件跟蹤BI分析

    今年一年都沒有怎麼靜下心寫點東西，事情不少，變故也不少。上半年在老東家，郵件系統的架構作完了，Exchange2010也有了點了解。上個月，又殺回了北京。北京有不少朋友，也有不少51CTO的朋友，之後線下活動，也能夠更多的參與了。。

    最近一直很忙，家裏的，工做的。工做上的事情，也是很凌亂，或者叫多線程，一會幹個這，一會幹戈那。如今有了點時間，也該寫點東西了。前幾天作了件事情，以爲仍是有點收穫的，應該記錄下來，爲本身沉澱點東西。也能夠分享給好多一直還在用站短問候個人朋友們。

    前段時間碰到這麼樣一個事情，有封從外部組織發送到公司某客服帳戶的郵件，按預期，應該根據傳輸規則，將此郵件複製一份並密抄給另外一個郵箱帳戶，做爲備份數據。但客服系統的管理員發現，出現了郵件丟失的狀況。就是說，按照預期會生成的郵件，沒有收到，致使客服系統，和備份帳戶中的郵件不一致。這個時候須要查看這封郵件的跟蹤日誌，來肯定郵件究竟是在哪一個過程當中，丟失的。。郵件系統的管理員接到這件事情之後就開始檢查，Exchange裏面已經作了郵件跟蹤日誌，但結果發現不全，一個星期之前的，都沒有了。由於以前有個習慣，就是按期將跟蹤日誌拷貝出來保存在另一個地方，進行存檔。目的有兩個，一個是避免佔用空間過多致使服務器資源緊張以及性能問題。第二個緣由就是一旦對郵件系統進行備份，日誌將會自動清除，也就意味着使用exchange的管理工具，只能看到上次備份以來的郵件跟蹤信息。

 

    關於這件事情，就很少說了，反正最後的結果是，咱們經過找到以前備份的郵件跟蹤日誌，查出了問題所在。但問題解決以後，我有了一個想法。Exchange的跟蹤查詢工具，是能夠知足咱們最基本的跟蹤查詢需求。可是限制因素不少，好比日誌的路徑，文件類型的數據等。固然，不排除像 塵封メ心 或者 cashcat 那樣的Exchange高手，能夠經過不少手段，甚至PowerShell等專業工具來實現郵件的跟蹤查詢。。可是我想，若是能將跟蹤日誌作成一個數據庫，是否是更好呢？好比放到SQL裏面，你們都知道光是SQL的查詢，就能夠作到很是豐富。還有報表服務，能夠作出一個很是友好的查詢界面，供一些非IT專業人員來進行查詢。若是須要更專業的分析，SQL還有一個強大BI功能，絕對知足任何要求的查詢。甚至能夠變態的分析出天天公司裏面哪一個男同事跟哪一個女同事溝通最密切，他們的郵件都說了什麼。。

    因此，個人想法就是，利用SQL強大的查詢、分析功能，實現對郵件的跟蹤。

    根本的需求有了，下面就得對需求，進行分析了。首先，把握住需求的核心對象，就是跟蹤日誌，更準確的說，是某一條用於描述郵件傳遞過程的日誌信息。。其次，要理清思路，想清楚整個信息傳遞的過程。這個過程，簡單來講的話，就是，最初的數據是生成於Exchange跟蹤日誌目錄，而後須要被導入到SQL數據庫中，最後經過SQL查詢被檢索出來。。

 

    對象搞清楚了，須要進行處理的過程搞清楚了，下面就是搞清楚應該怎麼辦。第一，日誌數據的生成，沒有問題，Exchange自己就會生成.log的日誌文件，或者配置Exchange啓用跟蹤日誌功能。第二，將.log文件的內容導入到SQL數據庫當中，這一步是關鍵。第三，進行信息檢索，這個也不是問題，SQL很容易被查詢。因此，整件事情的惟一須要作的，就是把.log的文件內容導入到SQL中。

    這裏我就不Step-by-Step的講怎麼一步一步操做的了，由於整個過程相對來講，步驟仍是不少的。我這裏就簡單介紹一下如何實現的，只要你們對SQL有基本實際經驗，應該都不是問題。

    先來用一句話歸納：經過SQL的BCP語句，實現數據的批量導入。。固然，前提是要先建表，.log文件中的每一個列，做爲表的列，就能夠了。

    BCP語句的語法，能夠查SQL的聯機叢書，或者微軟的TechNet網站進行查詢，語法仍是很簡單的。我就很少介紹了，這裏我只把我用到的貼上來。。

 

    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"

    看起來很簡單吧？可是我仍是碰了不少釘子。。因此，我以爲比寫Step-by-Step的步驟更重要的事情，是把我遇到的這些釘子拔出來給你們看看。

    釘子一：文件格式

        有心的朋友可能已經看到上面的BCP命令當中，是「MSGTRK20100703-1.txt」而不是「.log」的。更有心的，可能發現路徑裏面有個Unicode的文件夾。這都不是意外啊，這就是最大的一顆釘子。

        其實SQL DB自己就支持從某個文本中批量的導入數據，能夠直接用Studio的圖形界面，也能夠用「bulk insert」，或者是我用到的BCP命令。可是我碰到了一個頭疼的問題就是，死活數據導入不成功，各類方式都用過了。後來發現，Exchange自動生成的.log文件，文字編碼是使用的UTF-8標準，而SQL報錯說不支持。。怎麼辦？答案是，轉！

        先轉格式。。一個很土的辦法就是，用記事本打開log文件，而後什麼別改，直接另存爲.txt，注意這時有個「編碼」選項，記得要選成「Unicode」。。可是這個土辦法，轉一個兩個還行，一個Exchange環境運行個幾年下來。。那得有多少.log文件啊？因此說土嘛。。那怎麼樣可以批量的進行編碼轉換呢？

    釘子二：批量進行格式轉換

        附件裏有個工具，是網上下載的，怕有毒的，就自個去找Google它老人家要吧。。批量轉格式的方法，我相信不止一種，我也相信這個工具絕對不是最好的，若是哪一個之後找到更好的，記得回來通報一下。。

        由於這個工具，確實是個小工具，經不起大的工做量。我第一次的時候，一次性選了一個文件夾，大概4G左右的日誌，有好幾百個.log文件吧。。結果小工具直接罷工了，試了好幾回，終於摸出門路來了。。一次選的，不能太多，1G左右的量最好，要否則就把它撐爆了。。呵呵。。

    釘子三：生成.bat腳本

        通過幾個回合，個人全部的UTF-8編碼的.log文件，都被轉成了Unicode編碼的.txt文件。剩下的，就是往SQL裏面導入了。土人的作法是，一次一次的在CMD裏面運行BCP的這個命令（題外話：記住，那個叫CMD，命令提示符，不要再說是DOS了，很土的），每次都把另一個文件名複製到上一次運行的命令參數裏面，修改掉以前的。

        那麼多的文件，一次一次運行，會死人的啊。。因而出現了一個神人，他主張用.bat腳本，把這條命令在一個TXT文本里面複製個萬八千行的，一次執行完全部命令。這時又面臨一個問題，就是腳本里面，每一行當中的那個文件名，都是不同的，這時他想到一行一行修改文件名。。可是，若是面對成千上萬個文件，就意味着要Copy上萬次文件名。。因此說，能幹出這事的，都是神人啊。

        那咱們不是神，是人，是人就會使用工具，這時咱們想到了Excel。利用Excel的文本函數，能夠很方便的將一排文字，切割成幾列，而後修改其中一列，最後再組合成一個完整的文本內容。。

        若是非要知道怎麼作，能夠參考這裏《巧用Excel函數，簡化批量導入AD用戶及密碼修改》 http://bisheng.blog.51cto.com/409831/182286 ，雖然內容不同，但殊途同歸，靈活運用嘛。

    好，三顆釘子拔完，此事基本搞定。其實，其間也走過一些彎路，一些回頭路，還有好多小的釘子。反正最終，成功的將.log文件的內容，導入到了SQL數據庫當中。 後面的事情就好說了，我試過select語句，仍是很好用的，並且把幾個經常使用查詢語句保存了下來。

    其實，關鍵是，只要數據進入到SQL，後面就都好辦了。不管是查詢語句，報表，甚至是BI，可以將郵件跟蹤的分析作到什麼樣一種高度，就看你對SQL的研究深度了。

    再說說遺憾。。遺憾的事情就是，這全部的過程，除了Exchange或者SQL自己能夠完成的工做之外，其餘的操做，必須由人手動完成。。只不過咱們是用了一些自動化的方式，進行了一些批量的處理，簡化了一些工做量而已。。真正的全自動化的過程，還須要進一步完善。固然，再想進一步，光靠SQL已是不夠了。。

    最後，我再展望一下，若是但願作到全自動化，至少有幾個方面的問題須要解決。

    第一，須要對Exchange生成日誌的那個目錄作監控，一旦發現有日誌生成，自動將其進行轉化。固然具體的過程，可能還須要考慮是否先判斷文件已寫完，或者考慮先複製到另外一文件夾，再作處理。

    第二，文件格式的轉換，就不能用咱們那個小工具了，必須經過標準的文字編碼轉換方式進行。

    第三，須要自動的出發SQL的數據導入進程，並校驗整個過程當中的完整性和正確性。

    若是能作到這三個方面的自動化處理，基本上，就完美了。

    可能有人此時聽得有點犯暈，也可能有人已經有所感悟。。這不就是數據交換麼？這不就是中間件麼？這不就是Biztalk麼？？

    人云：查詢個日誌，把Biztalk都請出來了？？殺雞焉用牛刀呼？？我曰：閒來之時，能夠一試。。

    全文完。。。^_^....