Java日志正确使用姿势

Wesley13
• 阅读 257

前言

关于日志,在大家的印象中都是比较简单的,只须引入了相关依赖包,剩下的事情就是在项目中“尽情”的打印我们需要的信息了。但是往往越简单的东西越容易让我们忽视,从而导致一些不该有的bug发生,作为一名严谨的程序员,怎么能让这种事情发生呢?所以下面我们就来了解一下关于日志的那些正确使用姿势。

正文

日志规范
命名

首先是日志文件的命名,尽量要做到见名知意,团队里面也必须使用统一的命名规范,不然“脏乱差”的日志文件会影响大家排查问题的效率。这里推荐以“projectName_logName_logType.log”来命名,这样通过名字就可以清晰的知道该日志文件是属于哪个项目,什么类型,有什么作用。例如在我们MessageServer项目中监控Rabbitmq 消费者相关的日志文件名可以定义成“messageserver_rabbitmqconsumer_monitor.log”。

保存时间

关于日志保存的时间,普通的日志文件建议保留15天,若比较重要的可根据实际情况延长,具体请参考各自服务器磁盘空间以及日志文件大小作出最优选择。

日志级别

常见的日志级别有以下:

  • DEBUG级别:记录调试程序相关的信息。
  • INFO级别:记录程序正常运行有意义的信息。
  • WARN级别:记录可能会出现潜在错误的信息。
  • ERROR级别:记录当前程序出错的信息,需要被关注处理。
  • Fatal级别:表示出现了严重错误,程序将会中断执行。

建议在项目中使用这四种级别, ERROR、WARN、INFO 、DEBUG。

正确姿势

1、提前判断日志级别

//条件判断
if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}

//使用占位符
logger.debug("server info , id : {}, user : {}",id,user);

对于DEBUG,INFO级别的日志,在我们的程序中是比较高频的存在,当我们的项目大了,日志变多了,这时候为了程序运行的效率,我们必须以条件判断或者占位符的方式来打印日志。为什么呢?假如我们项目中配置的日志级别为WARN,那么对于我们下面的日志输出语句‘ logger.debug("server info , id : " + id + ", user : " + user);’,虽然该日志不会被打印,但是却会执行字符串拼接的操作,这里我们的user是一个实例对象,所以还会执行toString方法,这样就白白浪费了不少系统的资源。

2、避免多余日志输出

在我们的生产环境中,一般禁止DEBUG日志的输出,其打印的频率是非常高的,容易对正常运行的程序造成严重的影响,在我们最近的项目中就有遇到过类似的情况。

那么这时候该学会使用additivity属性

<logger name="xx" additivity="true">

在这边配置成true的话,也就是默认的情况,这时候当前Logger会继承父Logger的Appender,说白了就是当前日志的输出除了输出在当前日志文件以外,还会输出至父文件里。所以一般情况下,我们为了避免重复打印,会将这个参数设置成false,以减少不必要的输出。

3、保证日志记录信息完整

在我们的代码中,日志记录的内容要包含异常的堆栈,请勿随意输出“XX出错”等简单的日志,这对于错误的调试毫无帮助。所以我们在记录异常的时候一定要带上堆栈信息,例如

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

切记在输出对象实例的时候,须确保对象重写了toString方法,否则只会输出其hashCode值。

4、定义logger变量为static

private static final Logger logger = LoggerFactory.getLogger(XX.class);

确保一个对象只使用一个Logger对象,避免每次都重新创建,否则可能会导致OOM。

5、正确使用日志级别

try{
    //..
}catch(xx){
    logger.info(..);
}

这样一来,本来是ERROR的信息,全都打印在INFO日志文件里了,不知情的同事还会在死盯着错误日志,而且还找不出问题,多影响工作效率是吧?

6、推荐使用slf4j+logback组合

logback库里自身就已经实现了slf4j的接口,就无需引入多余的适配器了,而且logback也具有更多的优点,建议新项目可以使用这个组合。 还有一点需要注意,当引入slf4j后,要注意其实际使用的日志库是否是由我们引入的,也有可能会使用了我们第三方依赖包所带入的日志库,这样就可能会导致我们的日志失效。

7、日志的聚合分析

日志的聚合可以把位于不同服务器之间的日志统一起来分析处理,如今ELK技术栈亦或者的EFG(fluentd+elasticsearch+grafana)等都是一些比较成熟的开源解决方案。

拿ELK来说,可以在我们的服务器上直接通过logstash来读取应用打印的日志文件,或者也可以在我们项目中的日志配置文件里配置好相关的socket信息,打印的时候直接把日志信息输出至logstash。再交由elasticsearch存储,kibana展示。

结语

好了,关于日志先聊这么多~ 大家有需要补充或者交流的可以在下方留言哦。


推荐阅读

使用ConcurrentHashMap一定线程安全?
大白话搞懂什么是同步/异步/阻塞/非阻塞
Java异常处理最佳实践及陷阱防范
论JVM爆炸的几种姿势及自救方法

有收获的话,就点个赞吧

关注「深夜里的程序猿」,分享最干的干货

Java日志正确使用姿势

点赞
收藏
评论区
推荐文章
DevOpSec DevOpSec
2年前
nginx配置系列-日志切割
nginx配置系列日志切割背景nginx日志中我们希望日志能够每天或者每小时自动切割,nginx本身没有提供自动切割的机制,但是我们可以通过脚本或者稍加改造让其具备这种能力。下面让我们看看怎么操作吧。日志切割常见做法有四种,在我们做之前我们来学习一下nginx日志中常用的内置变量字段都是什么意思nginx内置变量
DevOpSec DevOpSec
2年前
日志切割之Logrotate
1、关于日志切割  日志文件包含了关于系统中发生的事件的有用信息,在排障过程中或者系统性能分析时经常被用到。对于忙碌的服务器,日志文件大小会增长极快,服务器会很快消耗磁盘空间,这成了个问题。除此之外,处理一个单个的庞大日志文件也常常是件十分棘手的事。  logrotate是个十分有用的工具,它可以自动对日志进行截断(或轮循)、压缩
Stella981 Stella981
2年前
Linux——定时清空日志内容和删除日志文件
前言最近在做性能压测试,会生成大量的日志,导致后续越压越慢,最终磁盘空间占满之类的问题。老是要手动删除日志文件,为避免此类问题发生,编写一个Linux日志定时清理的脚本,一劳永逸。1、shell脚本创建脚本并赋权touch/home/mppay/autotruncatelog.shchmod u
Stella981 Stella981
2年前
Guava库学习:学习Guava Files系列(一)
  对程序开发人员来说,文件的读写是很重要的一项技能。但是令人惊讶的是,尽管Java提供了一个丰富而健壮的I/O库,进行一些基本的文件操作却显得很繁琐。不过在Java7中已经发生了一些改变,但那些使用Java6的就不那么好运了。幸运的是,Guava做了一些我们期望I/O库做的事情,提供了一系列的工具,让我们能够更方便的进行I/O操作。本篇,我们就开
Stella981 Stella981
2年前
Redis的正确使用姿势
!(https://oscimg.oschina.net/oscnet/fce6a916371ff12e208a168eb4c27e665ca.jpg)前言说到分布式缓存,可能大多数人脑海浮现的就是redis了,为什么redis能够在竞争激烈的缓存大战中脱颖而出呢?原因无非有一下几点:性能好,丰富的特性跟数据结构,api操作简单。但是用的
Wesley13 Wesley13
2年前
Java系统架构
如果你所在的公司/团队还没有应用监控基础设施,如何让系统在上线后及时知道发生了问题?其中一个非常简单的方案就是对日志进行实时扫描监控.怎么做?不管你用的是什么框架,你的日志库应该可以设置日志级别.将日志级别打印在日志行的最开始.例如:ERRORxxxWARNxxx
人间小土豆 人间小土豆
2年前
请问日志审计什么意思呢?
这里的“日志”和我们日常生活中的理解大有不同。什么是日志?简单的说,日志就是计算机系统、设备、软件等在某种情况下记录的信息。具体内容取决于日志的来源。例如:unix操作系统会记录用户登录和注销等信息的日志防火墙会记录访问控制协议acl通过和拒绝等消息的日志有些系统在用户登录时或者在系统本身认为会发生一些故障时发出带有告警信息的日志有些产品会在本身存储不足时发
京东云开发者 京东云开发者
2个月前
小小的日志,大大的坑 | 京东云技术团队
在任何系统中,日志都是非常重要的组成部分,它是反映系统运行情况的重要依据,也是排查问题时的必要线索。绝大多数人都认可日志的重要性,但是又有哪些场景可能导致性能问题?今天就让我们来聊聊Java日志性能那些事。