怎么实现的日志选择的顺序 about sofa-common-tools HOT 29 CLOSED

@KevinHe666 默认情况下，我们选择顺序优先级是 logback > log4j2 > log4j。当然我们可以通过系统属性开关，关闭某一个日志实现的选择，如：-Dlogback.middleware.log.disable=true 就不会选择 logback了，只会选择 log4j2 实现找不到再找 log4j 的实现，具体配置可以看下这个文档哈

from sofa-common-tools.

@guanchao-yang 十分感谢,我继续研究 若有问题还需继续麻烦您

from sofa-common-tools.

@guanchao-yang

from sofa-common-tools.

@guanchao-yang 谢谢谢谢,我在代码里跟了好久没发现优先级设置方法 还有那个动态日志级别的我看文档和咱们项目代码也没有具体例子我试了一下的确是可以实现的 但是这个具体作用使用场景还是不太明白能否解答一下 谢谢您

from sofa-common-tools.

@KevinHe666

场景 1：作为一个基础 jar 提供给用户使用，这个基础 jar 要打印独立的日志，但是相关接入方可能有多个，同时对应的日志实现不同的接入方也不同，既有 Logback 也有 Log4j2、Log4j，这个时候就可以在基础 jar 提供方按照我们的这个标准 sofa-common-tools 支持起每一个不同的实现。但是，这个时候如果某一个接入方，虽然引入了 Logback 实现，但是就是期望使用 Log4j2 实现，那么就可以通过 -Dlogback.middleware.log.disable=true 关闭掉。

场景2 ： 单元测试方便，比如你的基础 jar 做了三套日志实现的配置和支持，但是如果在单元测试中没有关闭掉某一个实现的选择，我们的优先级一直 logback > log4j2 > log4j，那么对其他优先级低的测试就不方便，以为我们的测试中每一个日志实现都在 classpath 中，这个时候要测试 log4j,我们就可以在单元测试中把 logback 和 log4j2 关闭掉。

from sofa-common-tools.

@guanchao-yang 您好,继续咨询几个问题:
1.假如我们现在的业务系统中已经引入了三方包,三方包用log4j打印的,我们业务系统准备用logback打印日志,那是说我们的业务系统要用sofa-common-tools打印日志吗?还是要求三方包改用这个框架打印日志?
2.假如好几个三方包有的用log4j打印日志,有的用logback打印日志,怎么解决他们的冲突问题?三方包我们无法要求别人修改代码了.
3.日志隔离的具体应用场景是什么那?我们的业务系统虽然引入了很多三方包,但是也没出现过日志冲突的问题,或者出现了我们可以通过调整配置也能解决他们冲突的问题,实现三方包和我们的业务系统同时打印日志.
4.动态日志级别的具体应用场景是什么那?感觉平时也用不到啊?

from sofa-common-tools.

1. 业务系统还可以继续使用 log4j 去打印日志，不过由于引入你的依赖，并使用 logback 打印。如果一定要达到这个目的的话，就需要业务系统同时引入 logback 和 log4j 的日志实现。另，一般我们的实践经验是，业务系统用了哪个日志实现，你的这个依赖就用 log4j 去打，没必要强制用户还要引入 logback 的依赖，虽然可以做到。因为应用是业务系统的，其他的依赖包应该由业务系统决定日志实现，强制它可能接入成本高些。

2. 我们是实践是，大家统一起来，不应该去面向日志实现编程，而应该通过 sofa-commmon-tools 都面向日志编程接口 slf4j 去编程，需要推动改进。

3. 场景：主要是基础 jar 提供给别人用，要打印日志，如果自己强依赖了日志实现，就要被接入方必须引入相应的日志实现，通过此 sofa-common-tools 保证基础 jar 提供方不去强制绑定一个日志实现，有业务选择实现，我们的基础jar 均能通过其完成日志打印，接入成本和使用成本被变得更低。

4. 这个能力，可以通过 API 动态的设置日志级别完成切换，而不需要重启，当然调用方需要有不同的触发条件触发；之后我们会慢慢开放动态配置中间件，配合起来效果会更好。现在是 API 层面提供了这个能力。

@KevinHe666 如果代码中有不合理的地方，可以讨论列出 issue，然后给我们 PR 上来哈，热烈欢迎。

from sofa-common-tools.

@guanchao-yang 假如我们的二方依赖包和业务系统都面向slf4j接口编程那就不需要用 sofa-common-tools了吧？ sofa-common-tools包和我们直接面向slf4j接口编程有什么区别和优势哪？

from sofa-common-tools.

@magicyang918

假如我们的二方依赖包和业务系统都面向slf4j接口编程那就不需要用 sofa-common-tools了吧？以及优势？

答：还是非常需要的。假设大家都面向了 slf4j 编程接口了，对于一个二方依赖包，如果想打印日志的话，被接入方还是需要按照二方jar 提供的配置，在自己的 logback.xml 或者使用其他的实现的 xxx.xml 中，按照二方 jar 的文档标准都配置进去，如果二方 jar 都这样做的做，而应用的依赖的二方 jar 又比较多的话，对被接入方来说接入成本、维护成本都变得非常高，而且一旦升级了二方 jar 有新增加了对应的日志打印，还要业务接入方再配置文件中配置对应的 appender 和 logger ，这样对这个系统的稳定性和可持续的维护性都会造成非常大的隐患。

优势：1. 升级维护体验更优：二方 jar 通过引入 sofa-common-tools 来打印日志，只会使用接入方选择的日志实现，而对于后面的升级等配置文件的改变对被接入方没有任何侵入性，接入方只需要升级版本就 ok 了。2.更大的灵活性：二方 jar 同时不会绑定具体的日志实现，因为常用的 logback、log4j2 和 log4j 多做了适配 3.用户体验好：对被接入方来说，在也不用关系二方 jar 要用哪一个日志实现，要配置怎样的 loggger 和 appender ,也没有了后期改变的维护成本。

from sofa-common-tools.

@guanchao-yang 不过我们实际的代码中依赖了很多第三方包如spring,mybatis，还有公司的二方包如自己公司封装的mq客户端包，任务调度的客户端包，里边都有打日志的功能。
在我们使用中也没出过什么问题哪，日志都能正常打印。

我们业务代码中也没有特殊配置过二方包和三方包的日志，感觉你上边回答的场景在我们项目中一直没遇到过

from sofa-common-tools.

@magicyang918 像一些三方包，也提供了类似的策略去打印日志，没有绑定日志实现如 mybatis 根据不同场景去适配（自包含了）。二方包你们是如何解决的呢，是直接通过依赖日志实现的 API 的去构造 Appender 去打印的吗？

from sofa-common-tools.

@guanchao-yang 我们公司的二方包使用的是slf4j， 本身不指定具体日志框架，根据使用方的log走，如果使用方不对二方包进行特殊配置，二方包日志就默认打印到使用方的info日志里了。

还有一种是假如二方包使用log4j,使用方用logback，那么需要在使用方引入log4j和logback的包，如果是maven依赖二方包的话，会自动引入log4j的包，这样打日志也没啥问题。

from sofa-common-tools.

@magicyang918 那二方包所打印的日志文件和目录，你们是如何抉择的呢？还是说所有的二方包的日志都打印在一个 default 的日志里面

from sofa-common-tools.

@guanchao-yang 二方包日志就打印在业务代码的info日志里，或者可以通过properties文件给二方包单独配置日志路径

from sofa-common-tools.

@magicyang918 如何区分不同的日志打印文件呢，比如调度有几个文件要打印，消息也有几个文件要打印，每一个文件的打印都是让用户在配置文件中自己去配置的吗？

from sofa-common-tools.

@guanchao-yang 是的，需要使用方在配置文件里配置二方包的输出日志位置，一般每一个二方包配置一个总路径就行了。有的不用配置，直接打印到使用方的info日志里

还有动态日志在什么时候需要哪？我们的系统中都是打印info级别包括info级别以上日志

from sofa-common-tools.

@magicyang918 按照目前和你沟通的，你们的做法，应该有两个局限：1.虽然可以指定位置，但是相区分具体的日志文件，比如某个组件要具体输出三个文件，而每个二方 jar 都要输出到自己期望指定的日志文件中（就像接入的业务系统一样打印日志），目前你们的做法是存在局限性的，无法很好的定制 2.所有的日志文件，看似都打印在一个里面，没有区分也是有很多问题的，如造成日志量过大，同时没办法很好的区分出各个组件，对排查问题等有很多干扰信息

还有动态日志在什么时候需要哪？
场景：想临时排查一些问题时候，可以将动态调整级别为 DEBUG ，打印较多的日志来进行问题的排查。而平常为了日志过多是关闭掉的。

@magicyang918 建议试用下我们的工具，看看能否给你带来更好的体验哈。有问题随时沟通

from sofa-common-tools.

@guanchao-yang 好的，多谢了哈，明白了。

from sofa-common-tools.

@magicyang918 互相学习。客气哈

from sofa-common-tools.

@guanchao-yang 还有个问题，现在我们业务系统使用的二方包已经开发完很长时间了，有的已经没人维护了，那这种情况怎么使用sofa-common-tools 哪，是我们业务系统自己使用sofa-common-tools 隔离我们自己吗？

还有 是二方包里用sofa-common-tools打日志还是业务系统（使用方）用sofa-common-tools打印日志，还是二方包和业务系统都需要用sofa-common-tools打日志哪？

from sofa-common-tools.

@magicyang918

还有个问题，现在我们业务系统使用的二方包已经开发完很长时间了，有的已经没人维护了，那这种情况怎么使用sofa-common-tools 哪，是我们业务系统自己使用sofa-common-tools 隔离我们自己吗？

对于这种情况，二方包还是要找到 owner 统一维护管理起来，如果这个二方包被很多业务接入的话，未来可能就会出现日志实现冲突或者配置复杂难以维护的请。业务系统直接按照原有的方式去打印日志即可，没必要隔离自己哈，这样业务系统是体量大的系统去适配一个没有维护的二方包，成本有些高。建议：让别人接入的二方包，统一使用 sofa-common-tools 打印日志，并提供给接入方接入。

还有 是二方包里用sofa-common-tools打日志还是业务系统（使用方）用sofa-common-tools打印日志，还是二方包和业务系统都需要用sofa-common-tools打日志哪？

sofa-common-tools 主要是方便二方包在业务系统（使用方）中打印日志，业务系统原来使用哪一个日志实现打印在接入二方包后不必做改变，因不必主动配置二方包如何打印的。业务系统按照原有方式配置打印即可。

from sofa-common-tools.

@guanchao-yang 那如果业务系统想使用动态日志的功能就得也用sofa-common-tools打印日志了吧？

from sofa-common-tools.

那如果业务系统想使用动态日志的功能就得也用sofa-common-tools打印日志了吧？

你说的动态日志，应该是能够动态的调整级别是吧。如果是的话，而你们是面向 slf4j 接口编程，而 slf4j 没有提供动态设置级别的能力，这个时候 sofa-common-tools 也是很不错的选择。

from sofa-common-tools.

@guanchao-yang 就是动态的调整日志级别。那如果这样的话就是业务系统和二方包都得用sofa-common-tools了

from sofa-common-tools.

@magicyang918 二方包我们的最佳实践是全部使用 sofa-common-tools 的，这样可以让接入方最快和方便的使用。而业务系统由于有的历史包袱很重，改造成本比较高，有的容忍了这一点。当然 sofa-common-tools 都可以帮你解决你期望的这个问题。

from sofa-common-tools.

@guanchao-yang 还有一个问题需要请教:
假如我们使用方使用二方包，二方包使用了sofa-common-tools,使用方想要改变二方包日志的日志路径和强制二方包使用log4j,应该怎么处理那？因为二方包的jar包我们是无法修改的。

from sofa-common-tools.

使用方想要改变二方包日志的日志路径

sofa-common-tools 默认的打印路径为 -Dlogging.path 配置的值，同时对应 log-conf.xml（以 log4j 配置为例）配置的 appender 时，包含日志路径的配置：

<appender name="ROOT-APPENDER" class="org.apache.log4j.DailyRollingFileAppender">
        <param name="file" value="${logging.path}/sofa-component/common-default.log"/>
        <param name="append" value="true"/>
        <param name="encoding" value="${file.encoding}"/>
        <param name="threshold" value="${logging.level.com.alipay.sofa.component}"/>
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d %-5p %-32t - %m%n"/>
        </layout>
    </appender>

如示例， <param name="file" value="${logging.path}/sofa-component/common-default.log"/> 配置。log4j 默认会读取系统属性进行变量替换。这样使用方可以最简单的方式设置到系统属性即可。我们建议，所有的日志都统一放到一个目录下面，如 /home/admin/logs 下。

强制二方包使用log4j,应该怎么处理那？

从你的上下文中了解到，这个二方包已经接入了 sofa-common-tools ，但是只提供了 log4j 的打印能力，这个是不建议的，作为二方包应该把 logback/log4j2/log4j 都接入哈，这样方便使用方，也是做基础 jar 提供者给人接入的便利。

如果一定强制使用 log4j，两种办法：

1.使用方在 classpath 中不引入其他日志实现即可，即只引入 log4j 的日志实现
2.如果有了其他的日志实现，还想使用 log4j，那么就需要显示关闭掉 logback 和 log4j2 的选择逻辑，即设置系统属性：-Dlogback.middleware.log.disable=true -Dlog4j2.middleware.log.disable=true

from sofa-common-tools.

@guanchao-yang 对于使用方想要改变二方包日志的日志路径的回答还有一些疑问
你说第一种方法通过-Dlogging.path改变日志路径，假如我们使用方引入了好几个二方包，如果指定了-Dlogging.path，那会不会所有的二方包日志都打印到了这里，区分不出是哪个二方包的日志了。
第二种方法是通过修改二方包log-conf.xml，可是这个文件在二方包的jar包里吧，使用方是无法修改的吧？
还有两个问题：
假如使用方用了好几个二方包，使用方可以给每个二方包日志配置到不同的位置输出吗？
假如使用方用了好几个二方包，使用方可以给每个二方包配置不同的日志实现吗？

from sofa-common-tools.

@magicyang918

那会不会所有的二方包日志都打印到了这里，区分不出是哪个二方包的日志了。

配置日志路径文件的时候，除了要配置一个日志路径，后面还要配置上一个标示当前二方包的标识的，如 <param name="file" value="${logging.path}/sofa-component/common-default.log"/> ，sofa-component 就是具体打印的路径（文件夹）。通过路径区分开来

使用方是无法修改的吧？

是的。需要使用方发布版本统一支持上的。

假如使用方用了好几个二方包，使用方可以给每个二方包日志配置到不同的位置输出吗？

使用方理论上可以。但是我们是不建议的，因为对使用方应该最简单，二方包的提供者应该提供了默认可能，使用方最多定制下日志路径即可。

假如使用方用了好几个二方包，使用方可以给每个二方包配置不同的日志实现吗？

使用方应该有一个自己的日志实现，使用方决定用哪一个实现，二方包通过 sofa-common-tools 完成日志打印实现的自动适配。这里不建议给每一个二方包配置不同的日志实现，应用系统应该是易维护和日志实现确定的，应该是二方包去适配使用者接入时的各种场景，而使用者应该是最少成本的去接入，这个也是 sofa-common-tools 当时的初衷。

PS : 这个 issue 太长了，如果是新的问题，我们新开一个 issue 讨论哈。

from sofa-common-tools.