Aert_Log: 设计一个精简易用的日志

日志记录对于应用的维护特别是对于已部署到运行环境之后的应用调试都有着重要的意义。

 

对于一个应用的日志系统而言，首先必须得有一个日志对象，该对象负责记录日志信息。同时该信息可以输出到不同的位置，例如控制台，文件甚至网络中。对于信息的格式，则可以根据不同的需求，可以输出成普通文本，XML 或者 HTML 的格式。同时还需要对日志信息进行不同级别的分类，这样的好处是可以过滤冗余信息，只保留关键的日志。对于一个日志框架而言，日志对象必须是可配置的，它可以按照配置来输出到指定的目标，同时按照配置来决定输出的格式和决定何种级别以上的日志才能输出。

 

在我成为PHP程序员后,我使用过许多的PHP框架,也使用过太多大同小易的日志类,抑或者自己实现一个日志类也是非常简单的,譬如 这个 ,  这个

 

这些看起来都能够记录日志,但是 这真的就是我们需要的日志功能么?

 

接着我去问一个软件测试人员(非程序员),你理解的日志功能到底有哪些?

他给我的答案,大致如下:

 

1. 记录信息: 能够在一个地方查看输出结果
2. 分级输出: 能够过滤指定级别的日志记录
3. 格式输出: 能够以不同的形式来输出,诸如 html,xml,txt等
4. 报警提示: 错误并不能每次都能检测到,对于某些错误应该能够提醒应用维护人员

根据上述 4 条,其实 大部分框架中都基本实现了 1 - 3 这部分功能,比如

 

1. 记录信息到本地文件,SAE环境,等等

2. 过滤特定级别信息

3. 格式输出,大部分使用场景都是 txt 格式的,扩展其它样式应该也不难

 

对于 报警  这一项基本都没有什么体现,而这一点我思索之后觉得其实是很重要的一个环节,拿我们日常开发来讲,假设此场景: 客服童鞋反映 一个线上bug突然出现,请你赶紧解决,

 

我们的解决思路大概是这样: 根据客服童鞋给的bug一些诸如截图,访问地址之类的信息去重现这个bug,如果能够重现成功,那么恭喜你;但是大部分线上bug很难重现,或者说是在某些特定环境下才能重现;

 

此时 我们就会去查应用日志(如果你没有记录,嘿嘿,那你...),我们要从庞大的日志文件中去定位记录的信息(如果按大小进行了分割的话就有"且众多"), 看到这里你是否想到了"报警" 是个多么有用的手段啊,不管是发邮件还是sms,抑或微信等消息....虽然不是个银弹,但是可以节省我们好多时间啊

 

大概是三天前,我个人脑子发热,想搞一个在线幻灯片的应用,因为我实在是不会写好看的PPT,再加上看到了

impress.js 这个小东西,觉得我是不是可以一劳永逸的去解决这个坑爹问题,我可以使用熟悉的 markdown 语法,再加上简单的几个配置操作就能够搞出一个漂亮的PPT去做分享.如果你也有这方面的需求,可以大家一起探讨,当然如果你能给出一些资金来帮助我的话那就更好了,募捐地址

对于资助的童鞋,请留下亲的邮箱,上线之后给亲们高级会员的角色 ....

 

制定计划之后我就准备进行前期的骨架代码的构建,首先选一个开发框架吧,这么多,挑来挑去,说实话没有找到

几个合适的,最后选中3个: qeephp/yaf/ci. 折腾了一下午,还是没有下定使用哪个的原因,因为都有这个那个的问题,最后脑残去oschina去搜,结果看到了 SinglePHP  这个迷你框架,大概通读了下,发现这样的结构差不多才是我想要的简单框架,准备使用它,但是其很弱小,功能很不完善,就决定在其基础上就行修改,结果改来改去改到今天就变成了重造了一个轮子.

 

同步下进展情况,当前完成了如下功能:

目录结构如下:

 

 

框架代码都在Aert.core.php 文件中,加上注释一起目前有1500行不到

实现了一个基于MVC架构的面向移动互联网应用的微型PHP框架,当前完全实现了:

1. MVC 结构

 

2. 自定义错误&异常处理,自带的错误处理方便开发者定位错误原因,已实现PHP fatal 错误

3. ACL 权限控制: 实现了访问权限控制,实现了 角色资源控制

 

4. url路由设置: 实现了 正反向双解析功能的路由

 

## 路由配置信息:
# url 路由配置(key 路由名字, value 路由配置)
			'route_list' => array(
				'post_show' => array(
					'pattern' => 'post/{clz}/{id}-{name}.html',
			        'config'    => array(  
			            'clz'  => '[a-z][a-z_0-9]+',
						'id'    => '[0-9]+',				            
			            'name'  => '[a-z][a-z_\-0-9]+',  
			        ),  
			        'default'   => array(
			        	'controller'    => 'post',
			            'action'    => 'show',  
			            'clz'    => 'life',
			        ),      
				),
				
				'app_entry' => array(
					'pattern' => '{action}.html',
					'config'    => array(  
			            'action'  => '[a-z][a-z0-9]+',  
			        ),
					'default'   => array(
			        	'controller'    => 'application',  
			            'action'    => 'index',
			        ),
				),
				
				# 缺省配置
				'default' => array(
					'pattern' => '{controller}/{action}.html',
					'config'    => array(  
			           	'controller'  => '[a-z][a-z0-9]+',  
			            'action'  => '[a-z][a-z0-9]+',  
			        ),
					'default'   => array(  
			            'controller'    => 'application',
			            'action'    => 'index',
			        ),
				),
			),

## 测试反向url生成
		echo url('default','post_show',array(
			'id' => 456,
			'name' => 'ken-test-123',
			'clz' => 'java',
		));
		echo '<br>';
		echo url('default','default',array(
			'id' => 456,
			'name' => 'ken-test-123',
		));
		echo '<br>';
		echo url('backend','default',array(
			'action' => 456,
			'name' => 'ken-test-123',
		));

## 输出结果如下
/qart-dev/post/java/456-ken-test-123.html
/qart-dev/application/index.html?id=456&name=ken-test-123
/qart-dev/backend/application/456.html?name=ken-test-123

 

## 测试正向url解析

 

 

5. 应用挂载点支持: 以博客为例,我们经常要分成3个部分,比如 前台,后台,再比如多用户的话那么还要加上 用户中心. 对于这些划分,之前比如我们在使用 thinkphp/qeephp/yii/yaf等框架时我们总要考虑在站点根目录下要新建好几个入口文件或者建几个不同的目录.而且还要考虑一个实际问题: 我们如何去公用模型等库对象.

 

通过思索,我觉得这些能否不需要这么麻烦,我们就不能偷懒么,反正都是在一个域下,这些目录无非就是提现到url之上,此时我想到了在linux上使用mount命令时可以将其它的设备挂载到系统上,所以此处我引入了"挂载点"这个概念,我认为 譬如 前台/用户中心/后台/... 这些能否直接给挂载到一个根下面呢,假设应用的基准路径是

http://localhost/qart-dev/,把它影射成应用的根挂载点 '/', 通常我们都把前台作为应用的缺省访问地址,此处可以把 前台想成是 '/'; 而后台一般是 /admin/;用户中心一般是/usercenter/. 

 

而我们只需要拿到 pathinfo 之后,先去进行挂载点的匹配就能定位出访问地址究竟是要访问哪个模块....

 

这样我们就可以肆无忌惮的在配置文件中对非'/'模块的挂载点进行设置,比如按日期进行变化等等,而此处的修改并不会影响应用程序的代码结构

 

此时我们实际上是将多个入口文件进行了合并,只保留一个入口文件,但是此时又引入了一些新的问题,譬如:

• 不同模块所处的开发进度不一样,有的已经上线了有的仍处于开发测试阶段,不同模块需要设置不同的错误提示级别和错误处理过程
• 模块所需的用户主体不一样,比如前台/用户中心和管理后台其用户主体大多数都不一样
• 模块的acl资源角色可能不一样
• 模块的日志和路由都可能不一样,比如管理后台的日志就不要记录到前台的日志文件中

针对上述种种 ,我认为不同的模块之间可通过不同的配置项进行单独设置,比如不同的用户主体,不同的错误级别,不同的日志,路由,acl权限等等.

 

但是上升到整个应用的层面上来讲,模块的调用归根到底还是提现在url上,为此我将模块这个概念转化成了 "url命名空间",而url真正能映射到应用中的资源只存在 控制器/视图的代码上,也就是说 我们只需要对控制器文件以及视图文件进行划分即可,假设将控制器划分成 "url命名空间/控制器" 这种形式 ,是不是就能实现隔离呢,而那些模型类/代码库等文件是不是就可以通用呢.

 

我想是的,所以我就如此实践了,结果证明完全是可行的.定义一个命名空间最低需要如此设置即可

# 用于单元测试
		'testcase' => array(

			'mountpoint' => '/testcase/',

			# 错误处理
			'error.level' => E_ALL | E_STRICT,
			'error.exception' => 'ErrorHandler::sysHanException',
			'error.userlevel' 	=> 'ErrorHandler::sysHanUserlevel',
			'error.fatal' 	=> 'ErrorHandler::sysHanFatal',
			
			# 权限配置
			'authorized_default' => Aert_ACL::EVERYONE, # EVERYONE || NOBODY
			
			# url 路由配置(key 路由名字, value 路由配置)
			'route_list' => array(
				
				# 缺省配置				
				'default' => array(
					'pattern' => '{action}.html',
					'config'    => array(  
			            'action'  => '[a-z][a-z0-9]+',  
			        ),
					'default'   => array(
			        	'controller'    => 'application',  
			            'action'    => 'index',
			        ),
				),
			),
		),

 

 

6. 日志: 按开篇的日志讨论的结果进行了实现

 

 

class Aert_Log
{
    const TRACE = 1;
    const DEBUG = 2;
    const INFO  = 3;
    const WARN  = 4;
    const ERROR = 5;
    const FATAL = 6;
        
    private $enable = false;
    private $level;
        
    /**
     * 日志存储器
     * @var Aert_LogAppender
     */
    private $appender;
    
    /**
     * 日志存储器
     * @var Aert_LogAppender
     */
    private $alert;
    private $alertLevel;
    private $enableAlert = false;
        
    private static $levelNames = array(
        1 => 'TRACE',
        2 => 'DBEUG',
        3 => 'INFO',
        4 => 'WARN',
        5 => 'ERROR',
        6 => 'FATAL',
    );
	
    /**
     * 返回指定的日志服务对象实例
     *
     * @param string $name
     * @param array $config
     *
     * @return Aert_Log
     */
    static function instance($name, array $config=array())
    {
        static $instances = array();
        if (!isset($instances[$name]))
        {
            $instances[$name] = new self($config);
        }
        return $instances[$name];
    }
    
    private function __construct(array $config)
    {
        $this->level = intval(val($config, 'level', self::WARN));
        $this->enable = (bool) val($config ,'enable' ,TRUE);
        
        if ($this->enable)
        {
        	do {
	        	if ( empty($config['appender']) || empty($config['appender']['class']) )
		        {
		        	$this->enable = false;
		        	break;
		        }
		        $class = $config['appender']['class'];
		        $params = (array) val($config['appender'], 'config', NULL);
				
		        $this->appender = new $class($params);
		        
		        if ( !empty($config['alert']) || !empty($config['alert']['class']) )
		        {
		        	$this->enableAlert = TRUE;		        	
		        	$this->alertLevel = (int) val($config['alert'] ,'level' ,self::ERROR);
		        	
		        	$class = $config['alert']['class'];
		        	$params = (array) val($config['alert'], 'config', NULL);
		        	
		        	$this->alert = new $class($params);
		        }
		        
        	} while (false);
        }
        
    }
	
    function log($level, $msg)
    {
    	if (!$this->enable) return;
    	if ($this->enableAlert && ($level >= $this->alertLevel))
    	{
    		$this->alert($level, $msg);
    	}
    	if ($level < $this->level) return;
    	$this->appender->append(self::$levelNames[$level], $msg);
    }
    
    private function alert($level, $msg)
    {
    	$this->alert->alert(self::$levelNames[$level], $msg);
    }
}

/**
 * 日志存储器
 */
class Aert_LogAppender
{
	function __construct(array $config)
	{
		$this->init($config);	
	}
	
	protected function init(array $config)
	{
		
	}
	
	function append($level, $msg)
	{
		
	}
}

/**
 * 日志警报器
 */
class Aert_LogAlert
{
	function __construct(array $config)
	{
		$this->init($config);	
	}
	
	protected function init(array $config)
	{
		
	}
	
	function alert($level, $msg)
	{
		
	}
}

 以url命名空间 default 的配置为例

 

将日志的存储以及警报进行了分离,可以大大简化自定义日志处理的复杂度以及增强处理的多样性.比如可以单独实现File存储,SAE存储等,对报警器则可以实现控制台(一般是浏览器)输出,邮件,SMS,QQ,微信,SMS等多种.

 

此处给出 控制台(一般是浏览器)输出 以及 火狐插件FirePHP 的实现

<?php
/**
 * 日志警报器 -- Console
 * 
 * 监听指定错误级别,并直接打印到控制台
 */
class LogAlert_Console extends Aert_LogAlert
{
	function alert($level, $msg)
	{
		if (AERT_ISCLI)
		{
			fwrite(STDOUT, PHP_EOL . "[$level]: " . print_r($msg,true) . PHP_EOL);
		}
		else
		{
			if (is_string($msg))
			{
				echo "<BR />[$level]: " . print_r($msg,true);
			}
			else
			{
				dump($msg,"[{$level}]");					
			}				
		}		
	}
}

 

 

<?php
#{{{
app_import_file('/Lib/FirePHP.class.php');
#}}}

/**
 * 日志警报器 -- FirePHP
 * 
 * 监听指定错误级别,并通过火狐扩展 FirePHP 通知开发人员
 */
class LogAlert_FirePHP extends Aert_LogAlert
{
	function alert($level, $msg)
	{
		if (is_object($msg) && $msg instanceof TableRows)
		{
			/* @var $msg TableRows */
			$caption = $msg->getCaption();
			if (empty($caption)) $caption = $level;
			
			FirePHP::getInstance(true)->table($caption, $msg->combingRows());
			return;
		}
		
		switch ($level)
		{
			case 'TRACE':
				FirePHP::getInstance(true)->log($msg,$level);
				break;
			case 'DBEUG':
				FirePHP::getInstance(true)->log($msg,$level);				
				break;
			case 'INFO':
				FirePHP::getInstance(true)->info($msg);
				break;
			case 'WARN':
				FirePHP::getInstance(true)->warn($msg);
				break;
			case 'ERROR':
				FirePHP::getInstance(true)->error($msg);
				break;
			case 'FATAL':
				FirePHP::getInstance(true)->error($msg,$level);
				break;
		}
	}
}

 

 

本文大体能算完结了... 谢谢诸位的阅读,3q.

 

 

评论

2 楼 vb2005xu 2014-04-23  

http://www.chinaz.com/program/2008/0614/31068.shtml  php 表网关

1 楼 vb2005xu 2014-04-23  

http://medoo.huoxr.com/doc.php 借鉴实现Aert_Db的工具集