anchor.diff:      </root>
   </configuration>
   ----
  -<1> Propagation between slf4j and java.util.logging is needed
  -<2> We put logging directory outside of domain directory, and controlled by environment variable. `instanceName` is a JVM argument, that is unique for every instance in our system.
  -<3> We keep the JSON formatted logs on disk with greater retention period than our elasticsearch does. If we need we can re-upload those to analyze past events.
  -<4> Mutliple destinations in form of `host:port[,host:port]` can be defined for logstash socket appender. We keep then in an environment variable.
  -
  -We have similar configuration for `logback-access.xml`
  +The following points should be noted:
  +
  +<1> Propagation between `slf4j and `java.util.logging` is needed
  +<2> We put the logging directory outside of the domain directory, and controlled by an environment variable. `instanceName` is a JVM argument, that is unique for every instance in our system.
  +<3> We keep the JSON formatted logs on disk with greater retention period than our Elasticsearch does. If we need to, we can re-upload those to analyze past events.
  +<4> Mutliple destinations in form of `host:port[,host:port]` can be defined for the Logstash socket appender. We keep then in an environment variable.
  +
  +We have similar configuration for `logback-access.xml`:
   
   [source,xml]
   ----
  
positive.code: :hp-tags: Payara, Logback, Elasticsearch
  // :hp-alt-title: My English Title
  
  When running multiple instances of an application server it is quite hard to see the correlations between the events.
  One of the best tools to enable that is the ELK stack - Elasticsearch for building fulltext index of the log entries, Logstash for managing the inflow the events, and Kibana as a user interface on top of that.
  
  Solutions for Payara exist, that use better parseable log format (TODO: link to JSON log formatting article) which can be then processed by Logstash filebeats in order to have this log entries processed by remote logstash server.
  
  In our project, we chose different path -- we replaced all logging in the server and our applications with Logback, and make use of logback-logstash-appender to push the events directly to logstash over TCP socket.
  The appender uses LMAX disruptor internally to push the logs, so the processes is not blocking the application flow.
  
  This article will show you how to have this configured for your project as well.
  
  == Log everything via Logstash
  
  In first step, we replace backend for Payara's logging with logstash.
  
  https://github.com/goodees/goodees[Project goodees] was started by me to collect useful small components for Java EE, and Payara in particular.
  First released component is https://github.com/goodees/goodees/tree/master/payara-logback[payara-logback], that includes all libraries properly packaged to use logback as logging backend in Payara and also includes an installation script.
  Follow its instructions there to have your logging switched.
  
  
  == Logback and logstash configuration
  
negative.code: == Adapt your application
  
  Your application also needs small tuning now to prevent various class incompatibility errors.
  Both `slf4j-api`, and `logback-classic` should now be _provided_ dependencies of your application. 
  In other words, they should *not* be included in your _.war_ or _.ear_ build.
  
  == Downsides
  
  It is important to note that `asadmin set-log-levels` no longer works with this configuration, as logback is the one filtering the levels. You will need a different way of controlling log levels with this kind of configuration.
  
  == Give feedback
  
  Let us know how this setup works for you in the comments below.
  You're also invited to share your projects' https://github.com/goodees/goodees[goodees]!
  