日志总结

收集日志日志管理的第一件事，就是日志的收集。日志收集是开发者必备的技巧，不管是哪个开发语言，哪个开发平台，日志收集的插件都是有很多选择的。例如：.net 平台大家钟爱的log4net,支持多种存储方式（文件、数据库），多种格式，多种日志拆分方式。java 平台主流的log4j、slf4j、logback，多种选择。日志收集的组件这里就不一一说明了，使用都是很简单的，这里重点说明一下，日志我们收集应该注意的地方：
    1.日志等级一定要规范等级说明debug调试信息info用来收集关注的信息warn警告信息error错误信息好多开发工程师记录日志总是喜欢用info级别来记录日志，一般的组件默认级别都是info,所有info默认都是会被记录的，而debug信息发布后，是不会被记录的。这是一种偷懒的做法，但这也是很普遍的做法。正确的方式应该根据日志本身的特性去设置日志的级别，其实规范的日志级别是非常重要的：正确的级别便于运维。便于统一调整系统日志级别，如特殊情况可以只记录error错误没有正确的级别，对后期日志分析和处理是留下很大的隐患。error是需要去关注，并且处理掉的问题。info是普通日志的记录，大部分时候是无需关注的。
    
    2. error日志内容一定要详实 ,info日志要简洁易懂运营过大型系统的人都知道，除了数据库存储外，日志、图片、附件是存储的三大债主，他们是会占用非常非常大的空间，所有记录info的日志，要简洁易懂，避免空间浪费。 而对于error级别的错误，记录一定要详实，因为error的所有问题，是后期都要去解决的。请求的地址请求的参数请求的ip请求的用户error具体信息输出的内容......为了能很好的反馈当时error产生场景，以上的这些内容都应该被记录，而且越详细越好。
    
    3. error日志一定是全局统一收集的前文说过，error的日志，不仅是我们需要关注的，还是我需要解决掉的问题，所有error日志非常重要。错误日志的收集，必须是全局统一收集的，AOP是你最好的伙伴，如果你发现你的error日志收集是在每个类中，到处是try
{
......
}
catch()
{
    log.error("......")
}
这个一定要避免，不管你用那种语言，错误的处理，都是可以通过全局进行统一的处理，错误日志也要通过全局统一收集。管理日志每个开发人员对日志的收集，都是非常熟悉的，基本都是将日志按照日期的方式进行保存，

    日常使用日志的时候，也是有一些要求：
    1. 单个文件的大小要控制因为大家都是通过日期方式保存的，但是因为有的人不重视日志，经常会看到有的系统单个日志文件上百M，有的甚至是几G，而实际大家处理问题关注的都是最近的日志，所以控制单个日志文件的大小，对日志的性能以及后期的运维都是非常便利的。
    2. 日志要便于浏览日志文件小才便于浏览，日志最好能通过网址直接访问到，而不需要一波三折登录服务器，花10分钟下载下来，再来分析。
    3.日志的安全性要得到保障日志内容有时会包含敏感信息，特别是error日志，直接把系统的具体错误抛出来，所以日志除了查看方便，还需要确保日志文件的安全。如果是日志文件是html或者txt，请一定记得把你的日志文件权限修改下，特定用户才能访问，不要随便开放，所有人都能访问。
    4.日志要定期清理日志是非常占用存储的空间，日志太大对存储的性能也有一定的影响，所有日志要定期进行清理。空间充足可以保留半年空间不足最少也要保留3个月当然，这个也不是一定的，根据每个系统的情况去制定清理计划就可以了。
    如果大家是小型网站，一个系统一台服务器，日志管理就简单了。如果系统是做了高可用，后端用了均衡负载，那么，日志存在当前服务器是不太明智的做法，日志一定要统一存储，因为均衡负载随时都可能会切换服务器，当出现故障，你需要去找日志究竟存在哪个服务器，也是件很浪费时间的事情。日志文件也可以通过：共享虚拟目录来存储定时进行文件同步来存储日志存储也是对性能有一定影响的，文件同步虽然看起来麻烦一定，但是比共享虚拟目录的方式来说，性能会好，推荐使用这种方式。说到日志的同步，就不得不提Logstash这个日志组件。Logstash是现在应用最广的日志收集组件，基于java平台。其实很多java平台的组件，是不用去了解java开发的，只要简单的配置就能使用。Logstash支持文件同步，也可以结合rsyslog进行文件同步，当然，也支持通过tcp协议，与第三方对接，好伙伴当然是Elasticsearch。Elasticsearch下文也会做简单的介绍。Logstash中文手册：点击这里分析日志日志的分析也是一个很大的概念，可能对于运维和安全人员关注的是系统的所有日志，包括访问日志、系统监测的日志等，但是开发人员对于日志更多的是：监控系统运行错误，并获取错误时的相关数据包记录重要的信息，某些时候便于后期检查所以，开发人员对日志的需求相对而言简单一点，但是处理不当也会面临挑战。如果要根据某些关键字找日志，没有一个靠谱的系统处理，那么大家只能一直在ctrl+f 或者 find 命令中来回查找自己需要的信息，使用过的人都知道，这绝对不是一个很好的体验。那么是否有很好的工具来处理呢？有，这里就介绍另外的两个工具：Elasticsearch——一个基于lucene的搜索引擎工具，解决日志的搜索问题。当然，也能解决系统的搜索问题，而且是分布式的哦。Kibana——一个可视化的日志操作引擎，结合Elasticsearch可以达到更好的效果。

二.日志级别log4j定义了8个级别的log（除去OFF和ALL，可以说分为6个级别），优先级从高到低依次为：OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、 ALL。ALL 最低等级的，用于打开所有日志记录。
    TRACE designates finer-grained informational events than the DEBUG.Since:1.2.12，很低的日志级别，一般不会使用。
    DEBUG 指出细粒度信息事件对调试应用程序是非常有帮助的，主要用于开发过程中打印一些运行信息。
    INFO 消息在粗粒度级别上突出强调应用程序的运行过程。打印一些你感兴趣的或者重要的信息，这个可以用于生产环境中输出程序运行的一些重要信息，但是不能滥用，避免打印过多的日志。
    WARN 表明会出现潜在错误的情形，有些信息不是错误信息，但是也要给程序员的一些提示。
    ERROR 指出虽然发生错误事件，但仍然不影响系统的继续运行。打印错误和异常信息，如果不想输出太多的日志，可以使用这个级别。
    FATAL 指出每个严重的错误事件将会导致应用程序的退出。这个级别比较高了。重大错误，这种级别你可以直接停止程序了。
    OFF 最高等级的，用于关闭所有日志记录。如果将log level设置在某一个级别上，那么比此级别优先级高的log都能打印出来。一般来说测试环境会设置为DEBUG级别，客户正式环境会设置为ERROR级别。
   

JDK的Logging定义了7个日志级别，从严重到普通：
    - SEVERE
    - WARNING
    - INFO
    - CONFIG
    - FINE
    - FINER
    - FINEST
因为默认级别是INFO，因此，INFO级别以下的日志，不会被打印出来。使用日志级别的好处在于，调整级别，就可以屏蔽掉很多调试相关的日志输出。
日志是为了替代System.out.println()，可以定义格式，重定向到文件等；
    日志可以存档，便于追踪问题；
    日志记录可以按级别分类，便于打开或关闭某些级别；
    可以根据配置文件调整日志，无需修改代码；
    Java标准库提供了java.util.logging来实现日志功能。
    
Commons Logging定义了6个日志级别：
    - FATAL
    - ERROR
    - WARNING
    - INFO
    - DEBUG
    - TRACE
默认级别是INFO。
注意到实例变量log的获取方式是LogFactory.getLog(getClass())，虽然也可以用LogFactory.getLog(Person.class)，但是前一种方式有个非常大的好处，就是子类可以直接使用该log实例。

虽然配置Log4j比较繁琐，但一旦配置完成，使用起来就非常方便。对上面的配置文件，凡是INFO级别的日志，会自动输出到屏幕，而ERROR级别的日志，不但会输出到屏幕，还会同时输出到文件。并且，一旦日志文件达到指定大小（1MB），Log4j就会自动切割新的日志文件，并最多保留10份。
    SLF4J和Logback可以取代Commons Logging和Log4j；
    始终使用SLF4J的接口写入日志，使用Logback只需要配置，不需要修改代码。