Volkan, Happy to hear that you have recovered! Thank you also for the info on the 2.15.0 release, I'm looking forward to it for several reasons.
I'll try to answer your questions: > How do you purpose JTL? My organization is looking to standardize application logging across our platform. Our goal is to reduce the internal overhead of monitoring, searching, and sense-making with logs. As an early pass toward this, we have developed an application-based log config using Log4j JTL, that conforms to a standard model. > What do you use for the log storage engine? ELK? Splunk is the storage engine that I use most often. > Which appender (pipeline?) do you use to make your way from the application > to your log sink? My main development work for logging right now is on containerized applications, so stdout and the ConsoleAppender are what I use. All stdout logs forward to our aggregators. This follows current Kubernetes guidance that containers should write logs to stdout, for instance. > What is the scale? I hope it's enough to say: we run applications of varying sizes and request volumes in a large-enterprise, service-oriented, cloud-based, containerized architecture. We plan to support thousands of containerized application instances using this standard log format, to include Java applications. > Do you have any Log4j/JTL customizations? Yes, a couple at the moment. To support a numeric field derived from an existing Resolver, we wrote a simple custom Lookup that roughly translates the Resolver's output. The Lookup isn't perfect, because it exclusively renders as a String and the desired value is numeric, and because the mapping between the existing Resolver and the desired value is not 1:1. I would like to rewrite this translation as a custom Resolver in Log4j 2.15.0, to render the value correctly as numeric, to avoid the garbage hit of the Lookup, and maybe to provide additional data. I also would like to implement a custom Resolver to render several nested JSON fields. Right now, we render these nested fields from a combination of fixed environment variable Lookups and the MDC Resolver. We have a regular expression with a simple negative lookahead regex on the MDC Resolver to avoid duplicating MDC values that are rendered elsewhere. It would be nice to simplify these assumptions down to one or two custom Resolvers, which could be dropped in much like the current MDC resolver. I also might have a use-case for the Log4j Kubernetes Lookup in the near future. I hope these responses help. Happy to talk in greater detail as well. Thank you! Andrew
