SkyWalkingAgent 端⽇志插件的编写历程与使⽤说明
概述
前⼀段时间顺利完成了SkyWalking Agent 端logger-plugin 插件的开发，在此做个总结。⼀⽅⾯给插件的使⽤⽅法写⼀中⽂说明，另⼀⽅⾯分享⼀下该插件开发过程中的⼀些考量以及收获。
logger-plugin 插件，主要作⽤实现将将程序在调⽤过程中产⽣的⽇志⽐如错误⽇志信息，存⼊到span log 中。然后可以通过web 端直接查询，便于开发者排错与分析。同时为了提⾼使⽤的灵活性，我们还提供了配置⽂件，通过配置⽂件可以对需要存⼊到span log 的⽇志来源（log4j2、logbak 、log4j ）、包名、⽇志级别、内容进⾏控制。但同时需要提醒的⼀点是，由于该插件直接作⽤于agent 端，可能会造成⼀定程度的性能损失，请谨慎使⽤。
相关PR 地址如下：，以供参考。
使⽤⽅式基于性能的考量，该插件在设计之初定位为可选插件，因⽽默认情况下该插件的功能并不会启动。如需使⽤，需要在8.4.0发布之后，将插件从⽬录下复制到下，⽅能⽣效。
配置⽂件
⾸先需要说明的⼀点是，发布时默认是没有配置⽂件的，插件会按照如下默认配置内容运⾏:
上述配置⽂件含义如下：该插件默认会对所有⽀持的⽇志框架⽣效，包括log4j 、log4j2、logbback 。
插件之后将⾼于级别的⽇志信息存⼊到span log 中，⽽对, , , 级别的⽇志信息不⽣效。
默认情况下，会收集所有包级别的⽇志信息。.如果需要⾃定义插件的配置信息，需要在⽬录下创建⽂件进⾏配置。配置⽂件可配置内容及其含义如下：
packages 含义：指定需要转存的⽇志信息的包名，默认匹配所有包。
取值：包名：例如org.apache 。若有多个包名中间需⽤逗号隔开
*：匹配所有包级别的⽇志信息。
Level 含义：所需转存的⽇志信息的级别，默认情况是级别的⽇志信息
⽇志级别从⼩到⼤排列如下：
<  <  <<  < 同时我们在⾃定义配置信息的时候需要注意，由于logback 不⽀持级别的⽇志信息，因⽽如果错误的进⾏如下配置：
则会造成针对logback 的配置失效，也即不会收集任何关于logback ⽇志插件产⽣的⽇志信息，并会产⽣
错误⽇志，以供⽤户排查。
设计思路
其实这个插件刚开始插件之初，由于个⼈⼯程经验不⾜，当时考虑想要实现功能很多，⽐如需要⽀持正则表达式⽤以过滤，⽀持⽇志的格式化配置等等。但在和其他社区成员的讨论过程中发现，需要功能其实和该插件的定位不同，⽐如过滤⽇志信息的功能，⽇志系统中已经⽀持了。如果该插件再增加该功能⼀⽅⾯会增加插件使⽤的复杂程度，另⼀⽅⾯，也会造成更⼤的性能损耗。⽽针对另⼀功能⽇志的格式化，这与该插件的定位也是不符合的，apm 系统本⾝就是为了实现追踪和快速定位，对收集到的⽇志信息希望尽量简练，有效，许多格式化的信息，根本⽆需收集。因⽽该功能最终也被废⽌。
同时针对⽇志转存到span 的格式，和社区成员也进⾏仔细的沟通，为了适应未来SkyWalking 的⽇志查询功能，因此在转存⽇志信息时，存储到OAP 端的span log ⽇志是结构化的类似于下⾯的形式：
apache-skywalking-apm-
bin/agent/optional-plugins/apache-skywalking-apm-bin/agent/plugins/log4j.packages=*
log4j.level=error
log4j2.packages=*
log4j2.level=error
logback.packages=*
logback.level=error error trace debug info warn apache-skywalking-apm-bin/agent/config/logger-plugin/logconfig.properties error trace debug info warn error fatal
fatal logback.level=error
"logs": [
{
"time": 1605225365711,
"data": [
{
"key": "event",
"value": "warn"
},
{
"key": "log.kind",
"value": "org.apache.skywalking.oap.server.ace.parser.listener.MultiScopesAnalysisListener"
},
{
"key": "message",
"value": "span {} has illegal status code {}"
},
{
"key": "param.1",
"value": "*span*"
},
{
"key": "param.2",
"value": "*Value()*"
}log4j与log4j2
]
}
]
便于后续Web端实现灵活的查询。关于⽇志格式详细的讨论过程，可以参考
同时在设计的过程中，刚开始到插⼊点也是不合理的，⽐如刚开始选择的直接增强sl4j.Logger接⼝，
这回造成⼀个问题，⼀旦⽤户没有使⽤Log4j创建Logger对象就会造成⽇志插件失效，最终在BFergerson的帮助下，换成了⼀个更加合理的插⼊点。
总结
这篇⽂章更多的可能是个⼈在开发logger-plugin插件过程中踩过坑的总结吧，在整个开发过程中，其实收获蛮多的，⽐如并⾮⼀个软件功能越多越好。这个需要从该软件本⾝的定位出发，兼顾性能和易⽤性，做到⼀种平衡。同时简单写了写logger-plugin插件的使⽤⽅法，希望能够给感兴趣的同学以帮助。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。