利用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都请出来了？？杀鸡焉用牛刀呼？？我曰：闲来之时，能够一试。。

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