On Wed, Feb 12, 2020 at 11:51 PM Ralph Goers <[email protected]> wrote: > > > > On Feb 12, 2020, at 9:25 PM, Christopher <[email protected]> wrote: > > > > On Wed, Feb 12, 2020 at 7:01 PM Ralph Goers <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> > >> > >>> On Feb 12, 2020, at 4:14 PM, Christopher <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> I noticed that the log4j2 SocketServer and related utilities were > >>> moved away from log4j-core and into log4j-tools awhile back. However, > >>> there hasn't been a release of log4j-tools, as far as I can tell. Is > >>> there any plan to do so? I'm having trouble migrating some custom > >>> appender/receiver stuff from log4j1 without the classes, and I'd > >>> prefer to use the newer log4j-core, rather than an out-of-date one > >>> from before the move of these classes. > >>> > >>> (I just now subscribed to the list, and haven't had time to thoroughly > >>> search the backlog for related discussions, so apologies if this has > >>> already been covered recently.) > >>> > >>> Thanks, > >>> > >>> Christopher > >>> > >> > >> > >> You are correct. It hasn’t been released. There is some work that would be > >> need to do the release although I don’t believe it is much. > >> > >> However, you should be warned that we don’t recommend sending Java > >> serialized objects over the network as this has several problems, security > >> being one of them. Instead, using something like JSON is a better choice. > >> > > > > Thanks, I'm aware of that recommendation. It is the primary reason I > > am motivated to investigate the alternatives in Log4j2. Unfortunately, > > many of those alternatives appear to now exist only in the log4j-tools > > repo. For example, my understanding is that the TcpSocketServer and > > the SocketAppender can be configured to use the JSON layout, instead > > of the Java Serialization layout, but I'm still in the early stages of > > figuring out how to configure it all properly, and not having a > > released jar in Maven Central has made it slightly difficult to > > experiment with. > > > > I'm not 100% sure a release would even help me, as I may not even need > > anything out of that repo. I was considering using the HttpAppender > > instead, but there doesn't appear to be any server-side tooling at all > > to help with that one. > > > > Ultimately, what I'm trying to do is have a custom appender forward to > > a destination server whose location is subject to change over time. I > > wanted this custom appender to be asynchronous, but did not want users > > to have to configure the AsyncAppender wrapper themselves. I currently > > have this for Log4j 1.2 > > (https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/server/monitor/src/main/java/org/apache/accumulo/monitor/util/AccumuloMonitorAppender.java > > > > <https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/server/monitor/src/main/java/org/apache/accumulo/monitor/util/AccumuloMonitorAppender.java> > > and > > https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/assemble/conf/log4j-service.properties#L35-L36 > > > > <https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/assemble/conf/log4j-service.properties#L35-L36>), > > but am having difficulty migrating to Log4j2. > > Creating an AccumuloAppender for Log4j2 wouldn’t be terribly hard if that is > really what you want to do. But I wouldn’t have it be an asynchronous > appender. Instead, I would use asynchronous Loggers as they perform better. > That said, I would have very little motivation to implement an > AccumuloAppender myself. We use Logstash, Fluentd, and Flume for forwarding.
Using asynchronous loggers, instead of trying to make the appender asynchronous will make the implementation a bit easier. I'll try that route. I actually would prefer our users use something like Logstash or some other dedicated log aggregation, but I fear some have become dependent on our "most recent 50 warn/error logs across the cluster" feature we have on our cluster-monitoring web service. While I still recommend users use dedicated log aggregation, I'm not ready to kick this particular crutch out from under our users just yet. I've actually gone a slightly different route, though. Instead of using the SocketServer, I'm trying out a custom appender that writes to a custom HTTP REST endpoint. My biggest concern now is performance. Well, that, and I'm struggling to figure out how to properly configure multiple appenders in the log4j2.properties, but I'm sure I'll figure that out over time. > > > I should point out that the SocketAppender, when configured for TCP allows > for the location to change. Just configure it with a DNS name. It will > perform a DNS lookup whenever it needs to reconnect. Our use case is for an HA/standby service that doesn't rely on DNS changes. We have a custom service advertisement in ZooKeeper, using an ephemeral lock, and whichever service holds the lock is the currently active destination. It works well enough. > > Ralph
