mycat的日志文件配置MYCAT_HOME/conf/log4j.xml,结构为： 
日志配置是标准的log4j配置，其中：
是日志文件的存放目录。
是日志的级别，生成环境下建议将级别调整info/ware,如果是研究测试，特别是碰到异常可以通过开debug模式观察日志的信息查找异常原因。
warpper日志目前Mycat的启动是经过warapper封装成启动脚本，所以日志也会有其相关的日志文件：${MYCAT_HOME}/logs/warapper.log,再启动时候如果系统环境配置错误或缺少配置时，导致Mycat无法启动，可以通过查看warrpper.log查看具体错 误原因。
正常启动状态的warpper日志为： 
如果启动异常会有对应的异常信息，比如： 
日志显示异常原因为java.net.BindException: Address already in use,也就是端口占用，很有可能是原有服务未停止，或者Mycat默认端口被其他程序占用，正常启动成功后会有mycat.log日志，如果服务未启动成功不会有对应的日志。
下面看一下info级别小成功启动的日志。 
该部分日志可以看到配置的数据源相关信息，上面是两个数据源连接datahost。 
该部分描述了Mycat的缓存信息及动态类加载信息。 
该部分描述了Mycat线程池、buffer、连接池等等所有的配置信息，通过该启动项可以得知当前运行的Mycat个参数调整情况，生产环境下需要做部分参数调整，可以根据该日志分析参数情况。 
该部分描述了Mycat启动端口。 
该部分描述了Mycat时后端连接池的初始化过程。
如果某个连接断掉或异常心跳检测会有对应的日志如： 
该日志是心跳检测到连接异常关闭后端连接的日志，可以通过该日志查看后端数据连接状态。
下面分析sql：select * from t_user t; 的执行。 
通过该日志可以看到Mycat整个执行的计划。 其中最重要的是sql路由的计划，可以看到sql具体被分配到那个分片执行： 
该部分描述了该条sql被分配到到了分片dn1、dn2上同时执行，如果某个某个sql通过缓存、分片规则或者注解指定只会在某个分片执行，则sql只会被分配到到某个分片，例如： sql=select * from t_user t where t.user_id=121;该条数据只在分片1上。 
从日志可以看出sql只被路由到dn1节点执行。
如上面日志异常原因为sql错误导致sql解析器无法解析sql，通过分析错误日志可以找到具体的出错原因。Mycat日志很重要，当发现SQL执行有异常的时候，大多数情况下，都可以通过分析Mycat日志来定位错误，当发现Bug存在的时候，也建议把相关日志信息附上，一并提交github issue。
