logback

Java日志体系居然这么复杂?——架构篇

百般思念 提交于 2020-01-07 07:18:22
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文是一个系列,欢迎关注 日志到底是何方神圣?为什么要使用日志框架? 想必大家都有过使用 System.out 来进行输出调试,开发开发环境下这样做当然很方便,但是线上这样做就有麻烦了: 系统一直运行,输出越来越多,磁盘空间逐渐被写满 不同的业务想要把日志输出在不同的位置 有些场合为了更高性能,尽量控制减少日志输出,需要动态调整日志输出量 自动输出日志相关信息,比如:日期、线程、方法名称等等 显然 System.out 解决不了我们的问题,但是我们遇到的问题一定会有前人遇到过,日志也不例外,其中就有一个大牛 Ceki ,整个Java的日志体系几乎都有Ceki参与或者受到了Ceki的深度影响。当然Java日志体系的复杂度也有一部分原因是拜这位大牛所赐。 Java日志的恩怨情仇 1996年早期,欧洲安全电子市场项目组决定编写它自己的程序跟踪API(Tracing API)。经过不断的完善,这个API终于成为一个十分受欢迎的Java日志软件包,即Log4j(由Ceki创建)。 后来Log4j成为Apache基金会项目中的一员,Ceki也加入Apache组织。后来Log4j近乎成了Java社区的日志标准。据说Apache基金会还曾经建议Sun引入Log4j到Java的标准库中,但Sun拒绝了。 2002年Java1

Multiple WARs sharing the same logback.xml

一世执手 提交于 2020-01-07 02:22:11
问题 Is the following logback setup safe and good practice. I have Multiple WARs (deployed WebSphere 8.5.5) and want them to share a single logback.xml -Dlogback.configurationFile=/opt/logback.xml -Dlogback.ContextSelector=JNDI The logback.xml uses a SiftingAppender with JNDIBasedContextDiscriminator so each WAR gets its own log file. <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator">

logback配置文件重新加载VS业务写日志丢失

ε祈祈猫儿з 提交于 2020-01-07 01:19:46
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 首先,普通的一个XML文件解析的路线如下所示: 让我们加上scan的配置如下: <configuration packagingData="false" scan="true" scanPeriod="1 seconds"> 这个时候会生成一个定时任务,具体任务的执行见: stop in ch.qos.logback.classic.joran.ReconfigureOnChangeTask.performXMLConfiguration 这个任务里面会做什么事情吗? 我们知道有一个全局root的Logger对象,会触发这个对象的一些行为: 跟进去看看会发生什么! 通过设置如下断点&执行顺序可以复现: 断点在 stop at ch.qos.logback.core.spi.AppenderAttachableImpl:50 --- 这是为了获取主线程 stop at ch.qos.logback.core.spi.AppenderAttachableImpl:51 stop at ch.qos.logback.core.joran.spi.ConfigurationWatchList:83 stop at ch.qos.logback.core.spi.AppenderAttachableImpl:109

分布式系统中如何优雅地追踪日志(原理篇)

故事扮演 提交于 2020-01-06 13:55:43
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> > 本文只讲原理,不讲框架。 分布式系统中日志追踪需要考虑的几个点? 需要一个全服务唯一的id,即traceId,如何保证? traceId如何在服务间传递? traceId如何在服务内部传递? traceId如何在多线程中传递? 我们一一来解答: 全服务唯一的traceId,可以使用uuid生成,正常来说不会出现重复的; 关于服务间传递,对于调用者,在协议头加上traceId,对于被调用者,通过前置拦截器或者过滤器统一拦截; 关于服务内部传递,可以使用ThreadLocal传递traceId,一处放置,随处可用; 关于多线程传递,分为两种情况: 子线程,可以使用InheritableThreadLocal 线程池,需要改造线程池对提交的任务进行包装,把提交者的traceId包装到任务中 比如,上面这个系统,系统入口在A处,A调用B的服务,B里面又起了一个线程B1去访问D的服务,B本身又去访问C服务。 我们就可以这么来跟踪日志: 所有服务都需要一个全局的InheritableThreadLocal保存服务内部traceId的传递; 所有服务都需要一个前置拦截器或者过滤器,检测如果请求头没有traceId就生成一个,如果有就取出来,并把traceId放到全局的InheritableThreadLocal里面;

Extract info from a Groovy DSL file?

强颜欢笑 提交于 2020-01-06 06:05:12
问题 I recently switched my logback configuration file from logback.xml to logback.groovy. Using a DSL with Groovy is more versatile than XML for this sort of thing. I need to analyse this file programmatically, like I analysed the previous XML file (any of innumerable parsing tools). I realise that this will be imperfect, as a DSL config file sits on top of an object which it configures and must be executed, so its results are inevitably dynamic, whereas an XML file is static. If you want to

spring-boot logback.xml property depending on profile

℡╲_俬逩灬. 提交于 2020-01-06 03:25:27
问题 How can I get Spring Boot to set a property in my logback.xml based on the profile? Here's what I tried: I have an application-default.properties with: log.dir=/var/log And an application-development.properties with: log.dir=target And I want to pass this into my logback.xml : <property scope="context" name="logDir" value="${log.dir}" /> Running with development profile -Dspring.profiles.active=development I get logback issue: RollingFileAppender - Active log file name: log.dir_IS_UNDEFINED

Why are log files commonly flat?

冷暖自知 提交于 2020-01-06 03:03:06
问题 Are log files not meant to be read by machines but by users only? I wonder if there are file appenders for any logging framework that write their output to XML. 回答1: "Logging to XML" is quite a general requirement, because there is no such thing as the standard log file format. But since XML files are text files, which logging frameworks can write, and since many of those frameworks allow configuring log line format, I see no problem in defining your log output with XML tags of choice. For

Using logback with Karaf 3.0.5 running under ServiceMix

馋奶兔 提交于 2020-01-05 18:01:08
问题 I am trying to use logback with Karaf 3.0.5 running under ServiceMix. This is what I have done till now as mentioned in this question. This is what I have done till now:- Removed pax-logging-service by doing uninstall <pax-logging-bundle-id> Removed lib/bin/karaf-client.jar Inside lib placed the following jars:- jcl-over-slf4j-1.7.13 , jul-to-slfj-17.13.jar , logback-classic-1.0.13.jar , logback-core-1.0.13.jar & osgi-over-slf4j-1.7.13.jar From /etc/startup.properties - removed references to

logback doesn't print method or line number

点点圈 提交于 2020-01-05 07:12:42
问题 This is in a Gradle project using Groovy for the app code as well as test code. But I'm using a logback.xml file for configuration. One factor here that may be significant is that I am using the Groovy @Slf4j annotation to provide a logger. The %method and %line conversion words usually get printed out as "invoke" and "-1" respectively (although sometimes "invoke0" with "-2"). Interestingly, it does sometimes print the method and number: for example when it's an ERROR level log with an

How is logback's “prudent mode” implemented?

*爱你&永不变心* 提交于 2020-01-04 12:18:01
问题 The prudent mode in logback serializes IO operations between all JVMs writing to the same file, potentially running on different hosts. In other logging frameworks, logging to a central TCP (or JMS) appender seems to be the only solution if output from many loggers should go to the same file. As I am using a Delphi library which is based on log4j and also can not log to the same file from different instances of the same applications (on a terminal server), it would be interesting to know how