MongoDB在电子商务网站（Magento）中实际应用的设想之log文件日志

        Magento系统核心类提供了记录文件型日志的函数，记录的日志以文件形式保存在根目录下的var/log目录，系统自带功能模块利用这个函数来记录一些系统日志（system.log）和异常日志（exception.log）。

        

        除了自带的system.log和exception.log，通常我们会在开发中利用这个函数来对一些业务做日志的记录，以供出问题时的查错等作用，比如在支付宝的通知接收函数中添加日志代码，记录支付宝返回的通知信息等等：Mage::log($log,null,'alipay.log')，这样就会在var/log目录下生成文件名为alipay.log的日志文件了。原理详见app目录下的Mage.php文件

    

public static function log($message, $level = null, $file = '', $forceLog = false)
    {
        if (!self::getConfig()) {
            return;
        }

        try {
            $logActive = self::getStoreConfig('dev/log/active');
            if (empty($file)) {
                $file = self::getStoreConfig('dev/log/file');
            }
        }
        catch (Exception $e) {
            $logActive = true;
        }
        .......................
     }

        在实际网站运行中，文件日志的使用遇到了一些问题，首先，有很多人（包括我自己）会忽视掉system.log和exception.log这俩日志文件的存在，特别是在网站表面上看起来没问题的情况下。实际上说不定水底下暗流涌动，系统正疯狂的往这俩日志文件里写入新日志，直到磁盘空间报警才发现文件已经大到无法想象的程度。与存在数据库log表的日志不同的是，Magento没有提供自动清理文件日志的功能，用户要么手动清理，要么通过在Linux下设置计划脚本来清理。其次，日志文件积累在一个文件里，需要查看的时候发现里面堆积了从去年到今年的所有日志信息，无论是想要按时间段查看信息，还是想要查找搜索指定字符串的信息，都不是很方便。最后一个问题只有生产环境才会遇到，网站流量高了以后，一般都会通过负载均衡，用多台web服务器来分担并发的压力，这样的结果就是，日志文件也被分散到了各台web服务器上，当网站出现问题想要查看日志信息的时候就抓瞎了，只能一台一台的找过来。

        通过分析这些遇到的情况，我计划用MongoDB来代替文件作为日志存储的基质，来解决上面提到的几个问题。针对日志文件的无限制膨胀，使用MongoDB的固定集合来作为存储日志的集合类型，限制集合的总容量。自定义日志（比如alipay.log）的内容希望永久保留，又需要方便查询，可以用普通集合类型，然后将记录时间单独放一个字段来方便未来的区间查询。多服务器负载均衡时日志分散的问题，在启用MongoDB作为存储介质之后自然就不存在了，所有web服务器都会将日志写到同一个我所指定的MongoDB里面。

        从程序角度，为了在转换之后不改变一线开发人员的编码标准，保留正常的记录日志书写方式，即Mage::log($log,null,'alipay.log')这种写法，需要对核心代码Mage.php的log函数做一些修改，计划是将原来的文件名参数作为MongoDB里的集合名，将时间，级别（level），内容（message）作为三个文档的字段。也就是说，一个新的自定义文件名的日志类型在MongoDB里就是一个新集合，默认情况下的两个集合名就是system.log和exception.log。这样子，前端的开发人员甚至可以在不知道日志记录方式以及变动的情况下，继续按正常的习惯编码。

      有一点没提到的是，在做了这个转换之后，可以降低web服务器直接在磁盘上写文件的io压力（压力转移了）。另外，在网站实际运行的生产环境中，服务器的权限一般是掌握在专人手中的，一线的开发人员想要查看服务器的上文件内容，还不是那么方便，转换到MongoDB存储后，就可以简单的通过设置一些只读账户而把浏览权限放开给所有需要的人员。

        PS1：针对system.log和exception.log这俩，还是要及时根据里面的内容（警告和异常信息），对代码做出修复，理论上只要系统不报任何警告和异常，这俩的数据就不会增长，虽然在网站的迭代开发中很难做到百分百没问题。

        PS2：MongoDB不允许“system.”开头的字符串做集合名，所以这个system.log还的改个名先

        PS3：Magento的代码结构机制，允许对所有功能模块里的php类文件进行重写，也就是说可以不修改原生代码就实现各种自定义的功能，可惜作为一个入口性质的php类，Mage.php没法被重写，要实现上头讲的，只能直接改核心代码了- -