web测试-日志log

1. 日志简介

日志对于安全来说，非常重要，他记录了系统每天发生的各种各样的事情，你可以通过他来检查错误发生的原因，或者受到攻击时攻击者留下的痕迹。日志主要的功能有：审计和监测。他还可以实时的监测系统状态，监测和追踪侵入者等等。

在Linux系统中，有三个主要的日志子系统：

①：连接时间日志--由多个程序执行，把纪录写入到/var/log/wtmp和/var/run/utmp，login等程序更新wtmp和utmp文件，使系统管理员能够跟踪谁在何时登录到系统。

②：进程统计--由系统内核执行。当一个进程终止时，为每个进程往进程统计文件（pacct或acct）中写一个纪录。进程统计的目的是为系统中的基本服务提供命令使用统计。

③：错误日志--由syslogd（8）执行。各种系统守护进程、用户程序和内核通过syslog（3）向文件/var/log/messages报告值得注意的事件。另外有许多UNIX程序创建日志。像HTTP和FTP这样提供网络服务的服务器也保持详细的日志。

2. log的用途

不管是使用何种编程语言，日志输出几乎无处不再。总结起来，日志大致有以下几种用途：

①： 问题追踪：通过日志不仅仅包括我们程序的一些bug，也可以在安装配置时，通过日志可以发现问题。

②： 状态监控：通过实时分析日志，可以监控系统的运行状态，做到早发现问题、早处理问题。

③：  安全审计：审计主要体现在安全上，通过对日志进行分析，可以发现是否存在非授权的操作。

3. log使用规范

在开发B/S系统时，对于LOG，需要关注：

①：日志信息的集中采集、存储、信息检索：在WEB集群节点越来越多的情况下，让开发及系统维护人员能很方便的查看日志信息

②：日志信息的输出策略：日志信息输出全而不乱，便于跟踪和分析问题

③：关键业务的日志输出：基于度量数据采集、数据核查、系统安全等方面的考虑，关键业务系统对输出的日志信息有特殊的要求，需要做针对性的设计

4. 日志的采集和存储

对于目前存储日志，主要存在2种方式：

本地日志：直接存放在本地磁盘上

远程日志：发往�日志平台，用作数据分析和日志处理并展现。如用户访问行为的记录，异常日志，性能统计日志等。

5. 记录Log的基本原则

5.1日志输出级别（由高到低）

ERROR：系统中发生了非常严重的问题，必须马上有人进行处理。没有系统可以忍受这个级别的问题的存在。比如：NPEs（空指针异常），数据库不可用，关键业务流程中断等等

WARN：发生这个级别问题时，处理过程可以继续，但必须对这个问题给予额外关注。这个问题又可以细分成两种情况：一种是存在严重的问题但有应急措施（比如数据库不可用，使用Cache）；第二种是潜在问题及建议（ATTENTION），比如生产环境的应用运行在Development模式下、管理控制台没有密码保护等。系统可以允许这种错误的存在，但必须及时做跟踪检查

INFO：重要的业务处理已经结束。在实际环境中，系统管理员或者高级用户要能理解INFO输出的信息并能很快的了解应用正在做什么。比如，一个和处理机票预订的系统，对每一张票要有且只有一条INFO信息描述 "[Who] booked ticket from [Where] to [Where]"。另外一种对INFO信息的定义是：记录显著改变应用状态的每一个action，比如：数据库更新、外部系统请求

DEBUG：用于开发人员使用。将在TRACE章节中一起说明这个级别该输出什么信息

TRACE：非常具体的信息，只能用于开发调试使用。部署到生产环境后，这个级别的信息只能保持很短的时间。这些信息只能临时存在，并将最终被关闭。要区分DEBUG和TRACE会比较困难，对一个在开发及测试完成后将被删除的LOG输出，可能会比较适合定义为TRACE级别

推荐使用debug，info，warn，error级别即可，对于不同的级别可以设置不同的输出路径,如debug，info输出到一个文件，warn，error输出到一个带error后缀的文件。

5.2 日志对性能影响

不管是多么优秀的日志工具，在日志输出时总会对性能产生或多或少的影响，为了将影响降低到最低，有以下几个准则需要遵守：

l  如何创建Logger实例：创建Logger实例有是否static的区别，在log4j的早期版本，一般要求使用static，而在高版本以及后来的slf4j中，该问题已经得到优化，获取（创建）logger实例的成本已经很低。所以我们要求：对于可以预见的多数情况下单例运行的class，可以不添加static前缀；对于可能是多例居多，尤其是需要频繁创建的class，我们要求要添加static前缀。

l  判断日志级别：

n对于可以预见的会频繁产生的日志输出，比如for、while循环，定期执行的job等，建议先使用if对日志级别进行判断后再输出。

n对于日志输出内容需要复杂的序列化，或输出的某些信息获取成本较高时，需要对日志级别进行判断。比如日志中需要输出用户名，而用户名需要在日志输出时从数据库获取，此时就需要先判断一下日志级别，看看是否有必要获取这些信息。

l  优先使用参数，减少字符串拼接：使用参数的方式输出日志信息，有助于在性能和代码简洁之间取得平衡。当日志级别限制输出该日志时，参数内容将不会融合到最终输出中，减少了字符串的拼接，从而提升执行效率。

5.3 什么时候输出日志

日志并不是越多越详细就越好。在分析运行日志，查找问题时，我们经常遇到该出现的日志没有，无用的日志一大堆，或者有效的日志被大量无意义的日志信息淹没，查找起来非常困难。那么什么时候输出日志呢？以下列出了一些常见的需要输出日志的情况，而且日志的级别基本都是>=INFO，至于Debug级别日志的使用场景，本节没有专门列出，需要具体情况具体分析，但也是要追求“恰如其分”，不是越多越好。

5.3.1 系统启动参数、环境变量

系统启动的参数、配置、环境变量、System.Properties等信息对于软件的正常运行至关重要，这些信息的输出有助于安装配置人员通过日志快速定位问题，所以程序有必要在启动过程中把使用到的关键参数、变量在日志中输出出来。在输出时需要注意，不是一股脑的全部输出，而是将软件运行涉及到的配置信息输出出来。比如，如果软件对jvm的内存参数比较敏感，对最低配置有要求，那么就需要在日志中将-Xms -Xmx -XX:PermSize这几个参数的值输出出来。

5.3.2 异常捕获处

在捕获异常处输出日志，大家在基本都能做到，唯一需要注意的是怎么输出一个简单明了的日志信息。这在后面的问题问题中有进一步说明。

5.3.3 函数获得期望之外的结果时

一个函数，尤其是供外部系统或远程调用的函数，通常都会有一个期望的结果，但如果内部系统或输出参数发生错误时，函数将无法返回期望的正确结果，此时就需要记录日志，日志的基本通常是warn。需要特别说明的是，这里的期望之外的结果不是说没有返回就不需要记录日志了，也不是说返回false就需要记录日志。比如函数：isXXXXX()，无论返回true、false记录日志都不是必须的，但是如果系统内部无法判断应该返回true还是false时，就需要记录日志，并且日志的级别应该至少是warn。

5.3.4 关键操作

关键操作的日志一般是INFO级别，如果数量、频度很高，可以考虑使用DEBUG级别。以下是一些关键操作的举例，实际的关键操作肯定不止这么多。

n  删除：删除一个文件、删除一组重要数据库记录……

n  添加：和外系统交互时，收到了一个文件、收到了一个任务……

n  处理：开始、结束一条任务……

n  ……

5.4 日志输出的内容

l  ERROR：错误的简短描述，和该错误相关的关键参数，如果有异常，要有该异常的StackTrace。

l  WARN：告警的简短描述，和该错误相关的关键参数，如果有异常，要有该异常的StackTrace。

l  INFO：言简意赅地信息描述，如果有相关动态关键数据，要一并输出，比如相关ID、名称等。

l  DEBUG：简单描述，相关数据，如果有异常，要有该异常的StackTrace。

在日志相关数据输出的时要特别注意对敏感信息的保护，比如修改密码时，不能将密码输出到日志中。

5.5 什么时候使用J2SE自带的日志

我们通常使用slf4j或log4j这两个工具记录日志，那么还需要使用J2SE的日志框架吗？当然需要，在我们编写一些通用的工具类时，为了减少对第三方的jar包的依赖，首先要考虑使用java.util.logging。

考虑到slf4j等日志框架提供了日志bridge工具，为java.util.logging提供了Handler，所以普通应用的开发过程中也可以考虑使用J2SE自有日志，这样不但可以减少项目的编译依赖，同时在应用实施时可以更灵活的选择日志的输出工具包。

6 典型问题分析

6.1 该用日志的地方不用

上图对异常的处理直接使用e.printStackTrace()显然是有问题的，正确的做法是：要么通过日志方式输出错误信息，要么直接抛出异常，要么创建新的自定义异常抛出。

另：对于静态工具类函数中的异常处理，最简单的方式就是不捕获、不记录日志，直接向上抛出，如果认为异常类型太多，或者意义不明确，可以抛出自定义异常类的实例。

6.2 啰嗦重复、没有重点

首先上面不应该有error级别的日志。

其次在日志中直接输出e.toString()，为定位问题提供的信息太少。

另外需要明确一点：日志系统是一个多线程公用的系统，在两行日志输出之间有可能会被插入其他线程的日志记录，不会按照我们的意愿顺序输出，后面有更典型的例子。

最后，上面的日志可以简化为：

logger.debug(“从properties中...{}...{}...”,name, value, e);

logger.warn(“从properties中获取{}发生错误：{}”,name, e.toString());

或者直接一句：

logger.warn(“从properties中...{}...{}...”,name, value, e);

或者更完美的：

if(logger.isDebugEnabled()){

logger.warn(“从properties中...{}...”, name, e);

}else{

logger.warn(“从properties中获取{}发生错误：{}”, name, e.toString());

}

6.3 日志和异常处理的关系

首先上面的日志信息不够充分，级别定义不够恰当。

另外，既然将异常捕获并记录的日志，就不应该重新将一个一模一样的异常再次抛出去了。如果将异常再次抛出，那在上层肯定还需要对该异常进行处理，并记录日志，这样就重复了。如果没有特别原因，此处不应该捕获异常。

6.4 System.out方式的日志

上面的日志形式十分随意，只适合临时的代码调试，不允许提交到正式的代码库中。

对于临时调试日志，建议在日志的输出信息中添加一些特殊的连续字符，也可以用自己的名称、代号，这样可以在调试完毕后，提交代码之前，方便地找到所有临时代码，一并删除。

6.5 日志信息不明确

上面的“添加任务出错。。。”既没有记录任务id，也没有任务名称，软件部署后发现错误后，根据该日志记录不能确认哪一条任务错误，给进一步的分析原因带来困难。

另外第二个红圈中的问题有：要使用参数；一行日志就可以了。

还有一些其他共性的错误，就不多说了。

6.6 忘记日志输出是多线程公用的

如果有另外一个线程正在输出日志，上面的记录就会被打断，最终显示输出和预想的就会不一致。正确的做法应是将这些信息放到一行，如果需要换行可以考虑使用“\r”，如果内容较多，考虑增加if (logger.isDebugEnabled())进行判断。而第二个例子中的输出有System.out的习惯，相关内容应该一行完成。

6.7 多个参数的处理

对于多参的日志输出，可以考虑：

public voiddebug(String format, Object... arguments);

但是在使用多参时，会创建一个对象数组，也会有一定的消耗，为此，在对性能敏感的场景，可以增加对日志级别的判断。

参考链接：https://www.jianshu.com/p/8551fe9c6354

                  https://www.jianshu.com/p/01eb0995cfcb

                       http://blog.chinaunix.net/uid-11053507-id-2916036.html