现场故事：从Log4J迁移到Log4J2

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。参加AppDynamics APM导览！

与许多Java应用程序一样，AppDynamics Java代理广泛使用日志记录。多年来，我们一直使用Log4J作为日志记录框架。虽然Log4J的最新版本是2012年–并且Apache基金会于2015年8月宣布Log4J的生命周期终止 –但我们没有升级到Log4J2，因为需要维护对Java 5 VM和其他竞争优先级的支持。。但是，我们最近从整体存储库转移到特定于产品的存储库使升级成为可能。

Log4J2充满了诱人的功能。例如，该框架通过提供无垃圾记录，极大地提高了记录速度并减少了内存使用。通过对异步日志记录的本机支持，我们可以进一步减少在客户应用程序上运行时花费在日志记录上的时间。由于压缩也是本机功能，因此我们的代理可以承受更多日志记录，同时减少文件存储需求。这两个功能使我们能够添加更频繁，质量更高的日志记录，其中包含可为我们的客户成功提供可行信息的信息，以及可帮助客户的开发团队。

迁移目标和挑战

那么，我们想通过迁移完成什么？在迁移过程中我们面临什么挑战？
让我们从挑战开始：

–我们必须对框架包进行命名空间，以将Log4J的使用与客户的日志记录框架隔离开来，并且我们还需要使源Java 5兼容，因为标准Log4J2需要Java 1.6及更高版本。

–由于几乎每个班级都使用日志记录，因此我们必须找到一种方法来使这些更改递增，并且（相对）易于检查，以保持生产监控代理所需的高质量。

–万一Log4J2初始化失败，我们必须能够使用Log4J（已被证明可以工作）。
我们的首要目标是用Java 5兼容源重新打包jar。这一步很容易。我们以编程方式重构了所有类，以为其包命名空间。我们手动修复了一些涉及仅Java 6及更高版本支持的API的问题，例如String.isEmpty（）。

第二步是在兼容环境中测试框架。我们使用了一个已安装Java 5的docker容器，并创建了一个反映我们代理结构的测试应用程序。这一步很耗时，因为我们需要弄清楚配置和自定义如何与我们的代理一起使用。例如，我们拥有的功能之一就是代理错误安全性。如果代理代码遇到太多内部错误，我们将使日志静音并删除检测。我们拥有的另一个功能是重用节点名称。我们缓冲日志事件，仅在从UI知道节点名称后，才将其写入文件。使用测试应用程序，我们能够模拟所有这些功能，为迁移做准备。

为了实现可逆性，我们仍然同时存在两个框架。我们使用桥接模式将日志记录提取到单独的共享包中。这使我们在代码库中拥有多个日志记录框架，并且我们可以在运行时轻松地在它们之间进行切换。它还允许我们将来升级日志记录框架，从而提供高度的灵活性和可变性。这一步很重要，因为我们必须更改构建脚本并更改使用记录器的每个文件。

最后，我们简单地移动了从第二步创建的自定义附加程序的Log4J2版本，复制了配置代码，并由此成功地升级了日志记录框架！

4.4中的Log4J2日志关联支持

在使用Log4j2时，我们还借此机会在日志关联功能中增加了对它的支持。
日志关联使用户可以在其日志附加器模式中指定一个地点，以便我们在运行时插入我们的业务交易（BT）请求guid。在BT上下文中对记录器的任何调用都将动态地插入guid，而不管该行最终是在文件中还是在控制台中结束。

这些向导在日志输出中的存在可增强日志处理应用程序的功能，包括我们自己的Log Analytics产品，还包括诸如Splunk之类的其他产品。使用它们，我们可以将单个交易记录的任何行与我们在APM端针对该请求收集的快照数据相关联，而无需对客户应用程序进行任何更改。相反，它也使我们Controller的用户可以轻松地从BT快照过渡到日志中该BT请求期间发生的确切行。

除了对Log4J2的新支持之外，受支持的日志记录框架还包括Log4J，Logback和Slf4J。