日志级别【sl4j】-简单回顾

软件中总免不了要使用诸如 Log4net, Log4j, Tracer 等东东来写日志,不管用什么,这些东东大多是大同小异的,一般都提供了这样5个日志级别:

Debug

Info

Warn

Error

Fatal

一个等级比一个高,但是在具体开发中,关于应该如何选择适应的等级,却没有找到好的文章进行说明。记录一下自己的一些看法,以便日后使用吧。

=== Debug ===

这个级别最低的东东,一般的来说,在系统实际运行过程中,一般都是不输出的。

因此这个级别的信息,可以随意的使用,任何觉得有利于在调试时更详细的了解系统运行状态的东东,比如变量的值等等,都输出来看看也无妨。

当然,在每一个 Debug 调用之前,一定要加上 If 判断。

=== Info ===

这个应该用来反馈系统的当前状态给最终用户的,所以,在这里输出的信息,应该对最终用户具有实际意义,也就是最终用户要能够看得明白是什么意思才行。

从某种角度上说,Info 输出的信息可以看作是软件产品的一部分(就像那些交互界面上的文字一样),所以需要谨慎对待,不可随便。

=== Warn、Error、Fatal ===

警告、错误、严重错误,这三者应该都在系统运行时检测到了一个不正常的状态,他们之间的区别,要区分还真不是那么简单的事情。我大致是这样区分的:

所谓警告,应该是这个时候进行一些修复性的工作,应该还可以把系统恢复到正常状态中来,系统应该可以继续运行下去。

所谓错误,就是说可以进行一些修复性的工作,但无法确定系统会正常的工作下去,系统在以后的某个阶段,很可能会因为当前的这个问题,导致一个无法修复的错误(例如宕机),但也可能一直工作到停止也不出现严重问题。

所谓Fatal,那就是相当严重的了,可以肯定这种错误已经无法修复,并且如果系统继续运行下去的话,可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常,而是尽可能地保留系统有效数据并停止运行。

也就是说,选择 Warn、Error、Fatal 中的具体哪一个,是根据当前的这个问题对以后可能产生的影响而定的,如果对以后基本没什么影响,则警告之,如果肯定是以后要出严重问题的了,则Fatal之,拿不准会怎么样,则 Error 之。

=== 一些疑惑 ===

不过在实际使用中,基于上面的这种考虑,也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢?

例如在应用中有一个输出窗口,一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低,所以为了让用户能够看到有效的输出信息,必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高,所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定,Warn 信息其实并不影响系统的正常运行,这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌,系统发出警告了,该怎么办?

个人观点,Info 的级别应该比 Warn 更高才对,Warn 信息和 Debug 一样,应该在产品测试和调试时使用,而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。

目前我所采用的解决方法是,对于 Warn、Error、Fatal 都添加一个相应的系统断言,这样,可以保证当发生这种问题时,在调试阶段,可以立即得到提示。在软件发布以后,这些信息也能被记录到日志文件中去。

时间: 2024-11-02 12:33:33

日志级别【sl4j】-简单回顾的相关文章

Log4J日志配置详解和自定义log4j日志级别及输出日志到不同文件实现方法

Log4J日志配置详解 一.Log4j简介 Log4j有三个主要的组件:Loggers(记录器),Appenders(输出源)和Layouts(布局).这里可简单理解为日志类别,日志要输出的地方和日志以何种形式输出.综合使用这三个组件可以轻松地记录信息的类型和级别,并可以在运行时控制日志输出的样式和位置. 1.Loggers Loggers组件在此系统中被分为五个级别:DEBUG.INFO.WARN.ERROR和FATAL.这五个级别是有顺序的,DEBUG < INFO < WARN <

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 本篇文章是系列文章中的第三篇,前两篇的地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先

Log4j日志管理的简单实例

大型项目中很多情况下要分析程序的日志信息,如何管理自己的日志信息至关重要.在应用程序中添加日志记录总的来说基于三个目的 , 监视代码中变量的变化情况,周期性的记录到文件中供其他应用进行统计分析工作: 跟踪代码运行时轨迹,作为日后审计的依据: 担当集成开发环境中的调试器的作用,向文件或控制台打印代码的调试信息. 最普通的做法就是在代码中嵌入许多的打印语句,这些打印语句可以输出到控制台或文件中,比较好的做法就是构造一个日志操作类 来封装此类操作,而不是让一系列的打印语句充斥了代码的主体. 这篇文章主

java log4j基本配置及日志级别配置详解

java log4j日志级别配置详解 1.1 前言 说出来真是丢脸,最近被公司派到客户公司面试外包开发岗位,本来准备了什么redis.rabbitMQ.SSM框架的相关面试题以及自己做过的一些项目回顾,信心满满地去面试,结果别人一上来就问到了最近项目使用的日志系统是什么?日志级别是怎么配置的?当时我都蒙X了,平时都是项目经理搭的,我自己也是随便上网一搜往配置文件一黏贴就OK了.我就这么说完后面试官深深定了我一眼,当时我的内心羞愧到...... 1.2 闲话少说,讲讲日志的发展故事(如果已经了解的

Spark日志级别修改

摘要 在学习使用Spark的过程中,总是想对内部运行过程作深入的了解,其中DEBUG和TRACE级别的日志可以为我们提供详细和有用的信息,那么如何进行合理设置呢,不复杂但也绝不是将一个INFO换为TRACE那么简单. 主要问题 调整Spark日志级别的配置文件是$SPARK_HOME/conf/log4j.properties,默认级别是INFO,如果曾经将其改为DEBUG的朋友可能会有这样的经历,有用的信息还没看完,就被大量的心跳检测日志给淹没了. 解决办法 只将需要的日志级别调整为_TRAC

Logback日志配置的简单使用

Logback介绍 Logback是由log4j创始人设计的又一个开源日志组件.logback当前分成三个模块:logback-core,logback- classic和logback-access.logback-core是其它两个模块的基础模块.logback-classic是log4j的一个 改良版本.此外logback-classic完整实现SLF4J API使你可以很方便地更换成其它日志系统如log4j或JDK14 Logging.logback-access访问模块与Servlet

SpringBoot系列十一:SpringBoot整合Restful架构(使用 RestTemplate 模版实现 Rest 服务调用、Swagger 集成、动态修改日志级别)

1.概念:SpringBoot整合Restful架构 2.背景 Spring 与 Restful 整合才是微架构的核心,虽然在整个 SpringBoot(SpringCloud)之中提供有大量的服务方便整合,但是这些 整合都不如 Rest 重要,因为 Rest 是整个在微架构之中进行通讯的基础模式.那么对于 Rest 首先必须对其有一个最为核心的解释: 利用 JSON 实现数据的交互处理.而且 Spring 里面提供有一个非常强大的 RestTemplate 操作模版,利用此模版可以非常轻松的实

springBoot日志快速上手简单配置

默认配置 日志级别从低到高分为: TRACE < DEBUG < INFO < WARN < ERROR < FATAL. 如果设置为 INFO ,则低于 INFO 的信息都不会输出其他的依次类推 默认情况下,Spring Boot会用Logback来记录内部日志,并用INFO级别输出到控制台你不用做任何设置 从上图可以看到,日志输出内容元素具体如下: 时间日期:精确到毫秒 日志级别: 进程ID 分隔符:--- 标识实际日志的开始 线程名:方括号括起来(可能会截断控制台输出)

log4j动态日志级别调整

1. 针对root logger的设置 log4j.rootLogger=INFO, CONSOLELogger.getRootLogger().setLevel(org.apache.log4j.Level.DEBUG) 2. 针对Appender的Appender设置 log4j.appender.CONSOLE.Threshold=DEBUG((org.apache.log4j.ConsoleAppender)Logger.getRootLogger().getAppender("CONS