log4j

解决IntelliJ IDEA控制台乱码问题[包含程序运行时的log4j日志以及tomcat日志乱码] 参考文章： （1）解决IntelliJ IDEA控制台乱码问题[包含程序运行时的log4j日志以及tomcat日志乱码] （2）https://www.cnblogs.com/zhxn/p/8690566.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/stackoom/blog/4958010

一、引入相关包和依赖 我用的是pom文件的引入，我使用的是slf4j+log4j的方式，还有另一种方式为commons-logging+log4j的方式，这里不再多述，需要的朋友可以参考的资料。 <!--slf4j+log4j--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.7.25</version> </dependency> 二、配置log4j.properties文件 关于log4j.properties配置文件的配置网上一抓一大把，我这里只贴出自己的配置： #//注意这里不要用INFO，DEBUG等 改个名字 log4j.rootLogger=infoA,errorA,stdout,DEBUGA #过滤掉spring框架下的额外日志 log4j.category.org.springframework = WARN #输出到控制台 log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.Target=System.out log4j.appender.stdout.layout=org.apache.log4j

首先来看一下比较常用的Logger日志级别（部分未列出）: error - 运行期错误日志记录，应该有专门的error日志文件。； warn - 警告信息，如程序调用了一个即将作废的接口，接口的不当使用，运行状态不是期望的但仍可继续处理等； info - 有必要的事件信息记录。 debug - 调试信息，业务处理进行状态，当前的变量值等； trace - 一些更详细的跟踪信息； 鉴于我们是一个金融系统，流量还是不算很大，我个人认为debug级别和info级别可以统一归为info级别下打印，这是考虑到现在系统稳定性不够，处于一个快速迭代开发的过程中，线上问题可能随时都有，所以将业务流转与部分变量值打印出来还是很有必要的。error记录错误日志，但如果错误是预期会发生的，并且已经有了其他的处理流程，则建议使用warn级别。例如在try-catch中catch块里处理后继续流程的日志记录。 1.Logger对象的定义： <strong> private static final Logger logger = LoggerFactory.getLogger(Test.class);</strong> 2.日志中不出现计算或方法调用，防止在打印日志的时候报错。 之前在上家公司的时候就确实出现过因打印日志而系统RunTimeException的，不应该出现。 3.try

2019新春支付宝红包技术大揭秘在线峰会将于03-07日开始，点击 这里 报名届时即可参与大牛互动。 SOFA Scalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。 本文为《剖析 | SOFATracer 框架》第一篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:TracerLab/ ，文章尾部有参与方式，欢迎同样对源码热情的你加入。 0. 前言 在单体应用时代，我们不需要花费时间去关心调用链路这个东西。 但是链路跟踪不仅仅是在分布式场景下才会有，即使是单体应用，同样也会存在调用链路。 例如，我们把应用中的每个服务接口作为一个链路节点，那么从请求进来到返回响应，把这个过程中多历经的所有的方法接口串联起来，就能组成一条完整的链路，如下图所示： 对于单体应用而言，如果访问一个资源没有成功，那么我们可以很快的锁定是哪一台机器，然后通过查询这台机器上的日志就能定位问题。