1月22日,自己收到自己公司的产品包装盒三份(自己没下过订单),追查系统日志,最后发现公司内一同事ecstore本地开发环境的订单信息同步到了matrix上,接着matrix又推送到oms系统上。。。和同事确认近半年没有改过本地对联表内一切数据,那么真相只有一个,那就是商派matrix方的代码动过了,修改过验证机制,导致不是授权域名发送到matrix的请求也能正常接收了,这尼玛的真坑啊,这改的人可以扔出去火化了。
事情已经过去,期间追查系统时,由于需要查看日志,所以看了一遍日志模块的源码,顺便记录下来。
1.日志类文件路径在/base/lib/static/logger.php
2.一开始怀疑是创建订单时数据意外回滚了,所以追查了db方面的代码,精确到/base/lib/db/connections.php中的exec方法,这是所有sql执行调用的方法,包含回滚事务。该方法最后代码如下,
if($rs = mysql_query($sql,$db_lnk)){ self::$mysql_query_executions++; logger::debug('sql:'.self::$mysql_query_executions.'.'.$sql); $db_result = array('rs'=>$rs,'sql'=>$sql); return $db_result; }else{ logger::error($sql.':'.mysql_error($db_lnk)); trigger_error($sql.':'.mysql_error($db_lnk),E_USER_WARNING); return false; }
无论执行结果如何,都调用了logger的方法,虽然事后原因根本和logger无关,但这里还是具体看了一下。
3.logger类中的log方法首先判定了当前系统的默认日志级别,如没有在config中额外配置的话,应该是’info’级别,所以上面代码中成功部分的logger::debug是不会显示在日志文件里的,除非有必要调试,否则没有必要开始debug模式,这样会造成大量的I/O,后果很严重。
紧接着通过下面代码生成日志格式。
if(defined('LOG_FILE')){ $logfile = str_replace('{date}', date("Ymd"), LOG_FILE); $ip = ($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : '127.0.0.1'; $ip = str_replace(array('.', ':'), array('_', '_'), $ip); $logfile = str_replace('{ip}', $ip, $logfile); }else{ $logfile = DATA_DIR . '/logs/all.php'; }
4.确认一下config里是否开启了以下定义:
// 按日期分目录,每个ip一个日志文件。扩展名是php防止下载。 define('LOG_FILE', DATA_DIR.'/logs/site/{date}/{ip}.php');
如果有的话,那么log文件会以IP的形式存放在已当前日期为文件夹的路径下。
以上,是所有ecstore默认的logger类的工作原理,over!