Scoja client library

The Scoja project has a library for the sending via syslog from Java applications. This library abstracts the protocol's operation, but still lets you select the sending mechanism and configure all the details of a syslog event.

In order to use the library, you have to add the scoja-cc.jar (v1.4.0) and scoja-client.jar (v1.5.1) files to the CLASSPATH.

Example 1 

This is a simple example that sends logs via TCP to a syslog collector listening on port 514 (syslog standard port). Devo In-house Relay listens on that port. 

import org.scoja.client.Syslogger;
import org.scoja.client.ReusingTCPSyslogger;
 
public class Test {
  static final String HOST = "relay";
  static final int PORT = 514;
 
  public static void main(String args[]) throws Exception {
    Syslogger logger = new ReusingTCPSyslogger(HOST, PORT);
    logger.log("Test event");
    logger.close();
  }
}

The ReusingTCPSyslogger class sends the syslog events via TCP to the host and port configured in its constructor. It extends the Syslogger class that accesses the details of the syslog protocol except the transport details.

The log method builds and sends an event with the message that contains its argument. There are several syslogger subclasses for the most common transport protocols including UDP and SSL. There are also subclasses that retry automatically, broadcast, and more in the event of errors.

Using objects like syslogger in the event-sending code makes it easy to change the mechanism you use for sending. 

The syslogger subclasses can be used to send as many events as needed. In fact, it is a good idea to reuse them to send as many events as possible, thereby reducing the costs associated with opening new sessions. We recommend creating the necessary sysloggers at the beginning of the application and keep them open during the execution, using them to send events as needed. However, if the application only needs a syslogger at certain times, you can use the close() method as in Example 1.

All sysloggers are thread-safe, so they can be used in concurrent contexts shared in multiple threads simultaneously.

Details

Let's take syslog events that contain the following fields: when (date), priority (int), and host, tag, and message (all string). 

With the log() method used in the first example, we could only control the message content. However, there's a method you can use to specify the value for each of these fields:

public void log(Date when, int priority, String host, String tag, String message)
throws LoggingException;

Let's look at two ways the library can set appropriate values for the event fields:

First, we can make the call using "empty" values which tells the library that it needs to replace them with fixed values. The empty values are represented as null, except for priority which is using org.scoja.common.PriorityUtils.UNKNOWN_PRIORITY. In this case, the library will calculate fixed values to replace all fields except message. 

logger.log(null, UNKNOWN_PRIORITY, null, null, message);

Second, we can use multiple versions of the log method with fewer arguments, the first being the one used in the first example:

public void log(String message)
throws LoggingException;
 
public void log(int priority, String message)
throws LoggingException;   
 
public void log(int priority, String host, String tag, String message)
throws LoggingException;

You can use values like null or UNKNOWN_PRIORITY in these version of the method as well.

The library can assign a value to an argument in various ways. For example, the event date can be assigned the current time. The host can be assigned from the event source or defined by a method as below:

public Syslogger setHost(String host);

The priority and tag are assigned with values defined using these methods:

public Syslogger setPriority(int priority);
public Syslogger setTag(String tag);

Priority

Syslog priority is a value composed of two parts: facility and level. Facility and level are expressed as numbers that are defined in the syslog specification. Priority is also a number that is build by making certain numerical manipulations on its two parts. The org.scoja.common.PriorityUtils class, names the facilities and legitimate levels with constants, and has a statistic methods to construct a priority from a facility and level and to extract the facility and level from a priority.

• The facilities are: KERN, USER, MAIL, DAEMON, AUTH, SYSLOG, LPR, NEWS, UUCP, CRON, AUTHPRIV, FTP, LOCAL0, LOCAL1, ..., LOCAL7...
• The levels are: EMEG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO and DEBUG.

A priority is built using buildPriority (facility,level). The facility and level are extracted from a priority with getFacility(priority) and getLevel(priority).

Example 2

In the following example, we use some of the elements that we've discussed so far. Assume that you want to send to two collectors: one is a Devo Relay listening on TCP port 514 the other is a standard syslog daemon also listening on UDP port 514.

import org.scoja.common.PriorityUtils;
import org.scoja.client.Syslogger;
import org.scoja.client.UDPSyslogger;
import org.scoja.client.ReusingTCPSyslogger;
import org.scoja.client.SpreadingSyslogger;
 
public class Test {
  static final String HOST1 = "relay1";
  static final int PORT1 = 514;
  static final String HOST2 = "syslog";
  static final int PORT2 = 514;
 
  public static void main(String[] args) throws Exception {
    Syslogger logger = new SpreadingSyslogger(
      new ReusingTCPSyslogger(HOST1,PORT1),
      new UDPSyslogger(HOST2,PORT2));
    logger.setPriority(PriorityUtils.buildPriority(PriorityUtils.LOCAL0,PriorityUtils.INFO));
    logger.setTag("my.app.app1.activity");
    logger.log("Event body");
    logger.close();
  }
}

ReusingTCPSyslogger sends to the Devo Relay via TCP and UDPSyslogger sends to the syslog daemon via UDP. To avoid generating the event twice (once for each destination), we use SpreadingSyslogger to send the event to the two destinations. This way, it's easy to change or add an event destination.

Errors

The sending of an event can fail. The syslogger will produce a SysloggerException exception that must be captured and treated.A syslogger that failed to send an event probably has run into an inoperative state. You have to restart it by calling the reset() method, which will make it ready to continue sending events.If the error happens due to network problems; the errors will be repeated and you should opt for an alternative action.All this logic (trap errors, retry and choose an alternative action) is encapsulated in syslogger subclass called RetryingSyslogger. This is an example that retries 3 times and, in case of persistent failure, it shows the log through the standard output.

import java.util.Calendar;
import org.scoja.common.PriorityUtils;
import org.scoja.client.LoggingException;
import org.scoja.client.Syslogger;
import org.scoja.client.ReusingTCPSyslogger;
import org.scoja.client.RetryingSyslogger;
import org.scoja.client.LoggingErrorHandler;
 
public class Test {
  static final String HOST = "relay1";
  static final int PORT = 514;
  static final int RETRIES = 3;
 
  public static void main(String[] args) throws Exception {
    Syslogger base = new ReusingTCPSyslogger(HOST,PORT);
 
    LoggingErrorHandler onError = new LoggingErrorHandler() {
      public void log(Syslogger logger, LoggingException error,
          Calendar when, int priority, String host, String tag, String message)
      throws LoggingException {
        ilog(logger, error, when, priority, host, tag, message);
      }
      public void ilog(Syslogger logger, LoggingException error,
          Calendar when, int priority, String host, String tag, String message)
      throws LoggingException {
        System.err.println("Cannot log to " + logger + "; failed with " + error
          + " while sending " + when + " " + priority + " " + host + " " + tag + " " + message);
      }
    };
    base.setTag("my.app.app1.activity");
    Syslogger logger = new RetryingSyslogger(base, RETRIES, onError);
 
    logger.setPriority(PriorityUtils.buildPriority(PriorityUtils.LOCAL0,PriorityUtils.INFO));
    logger.log("Event body");
    logger.close();
  }
} 

The  RetryingSyslogger class is built with a delegate (base) Syslogger, a number of retries (RETRIES) and an action in case the error persists after the retries (onError). In case of error, the action can do several things with the event that caused the error: discard it, throw an exception, send it to another destination with another logger...

When the transport is UDP, there's usually no error or crashes because the problem usually involves packages in some point of the connection network; but with TCP, the link between the client and the collector is stronger: if the collector is heavily loaded or fallen, or there are network problems that makes it inaccessible, you'll see various anomalous behaviour in your application as exceptions or recurring, or, what is worse, as blocks. 

Java's TCP sockets don't have time-outs for the writing, you can only configure a time-out for the connection. The ReusingTCPSyslogger class makes that property visible with the method setConnectionTimeout(millis).

Non-blocking connections

With the Scoja library, it's possible to build a Syslogger with a more sophisticated behaviour on the transport layer. We'll focus on how to build a Syslogger that operates in a non-blocking manner, both during the connection negotiation as well as the sending; so the calls to log(...) methods will just last long enough to copy the data (either to operating systems or internal buffers). Before getting into the example, it's worth mentioning that we'll achieve the prevention of blocking by sacrificing other things. In this case, we'll have to assume that, if something misbehaves, some events will be lost.

import org.scoja.common.PriorityUtils;
import org.scoja.util.ByteFall;
import org.scoja.util.MemoryByteFall;
import org.scoja.client.Syslogger;
import org.scoja.client.ReusingTransportSyslogger;
import org.scoja.trans.Transport;
import org.scoja.trans.tcp.TCPConf;
import org.scoja.trans.nbtcp.NBTCPTransport;
 
public class Test {
  static final String HOST = "relay1";
  static final int PORT = 514;
  static final int BUFFER_SIZE = 64*1024*1024;
 
  public static void main(String[] args) throws Exception {
    Transport<TCPConf> trans = new NBTCPTransport(HOST,PORT);
    ByteFall buffer = new MemoryByteFall(BUFFER_SIZE);
    Syslogger logger = new ReusingTransportSyslogger(trans, buffer);
 
    logger.setPriority(PriorityUtils.buildPriority(PriorityUtils.LOCAL0,PriorityUtils.INFO));
    logger.setTag("my.app.app1.activity");
    for (int i = 0; i < 1000; i++) {
      logger.log("Event body");
      Thread.sleep(1);
    }
    logger.close();
  }
}

The Syslogger construction is now done in 3 steps. A ReusingTransportSyslogger is a Syslogger that doesn't understand about transportation and expects to be given a Transport type object that will take care of that problem. It does know that the sending via a Transport may fail or jam, in which case, it'll save the events in a buffer waiting for the Transport to recover.

In this example, the Transport is a NBTCPTransport (transport via TCP and non-blocking). All of this transport operations are performed in a non-blocking manner, both the connection and the sending. This is not achieved with a separate thread, but putting the socket in a non-blocking mode. It has the advantage that it coexist well with any application server that doesn't introduce new threads, but it has the disadvantage that it can't progress by itself and needs to receive a request to advance in the connection and sending process. The connection is not fully established until it has processed a few events and are visible in the syslog collector. In practice, this procedure is not visible because there are events continuously.

The buffer where data is stored must be limited, if not, a connectivity problem may cause the client to overflow. The MemoryByteFall class implements a buffer in memory, that occupies as much the size as it has been defined and discards the other data when full.

It should be noted that although this solution may lose packages, it has a better behavior than a sending based on UDP. First, it can work in a very congested network without losses, where package retransmission are necessary. In addition, by selecting a suitable size for the buffer, it'll be possible to restart the collector without losing events.

Encrypted sending

Once you've come to the capabilities of Scoja library to configure the transport layer, there's a world of possibilities. Next, we'll explore the sending with SSL.

When working with Devo, there are multiple ways to send events: In-house Relays, public relays, relays in a cloud provider's safety zone, etc. These alternatives are simple intermediaries for Devo's central collectors, they're designed to facilitate the sending; but, sometimes, it can be interesting to have a program that sends directly to the central collectors.

All the logs must get to the central collector through a SSL channel, which forces the double authentication by certificates: the server presents its certificate to the client, but the client must show the certificate to the server. This ensures that the traffic is encrypted when transmitted through internet and that it's not possible to do impersonations in either of the 2 extremes.

We'll adapt the example to send directly to logtrust central collectors via SSL:

import java.io.File;
import org.scoja.common.PriorityUtils;
import org.scoja.util.ByteFall;
import org.scoja.util.MemoryByteFall;
import org.scoja.client.Syslogger;
import org.scoja.client.ReusingTransportSyslogger;
import org.scoja.trans.Transport;
import org.scoja.trans.tcp.TCPConf;
import org.scoja.trans.nbtcp.NBTCPTransport;
import org.scoja.trans.ssl.SSLConf;
import org.scoja.trans.ssl.SSLTransport;
import static org.scoja.trans.ssl.SSLClientAuthenticationMode.REQUIRE;
import static org.scoja.trans.ssl.SSLUtils.loadTrusts;
import static org.scoja.trans.ssl.SSLUtils.loadKeys;
 
public class TestSSL {
    static final String TRUSTJKS = "logtrust.jks";
    static final String MEJKS = "me.jks";
    static final String HOST = "eu.public.relay.logtrust.net";
    static final int PORT = 443;
    static final int BUFFER_SIZE = 64*1024*1024;
 
    public static void main(String[] args) throws Exception {
        char[] password = args[0].toCharArray();
         
        Transport<TCPConf> tcp = new NBTCPTransport(HOST,PORT);
        Transport<SSLConf> ssl = SSLTransport.tls(tcp);
        SSLConf sslConf = ssl.configuration();
        sslConf.setClientAuth(REQUIRE);
        sslConf.setTrustManagers(loadTrusts(new File(TRUSTJKS)));
        sslConf.setKeyManagers(loadKeys(new File(MEJKS), password));
     
        ByteFall buffer = new MemoryByteFall(BUFFER_SIZE);
        Syslogger logger = new ReusingTransportSyslogger(ssl, buffer);
 
        logger.setPriority(PriorityUtils.buildPriority(PriorityUtils.LOCAL0,PriorityUtils.INFO));
        logger.setTag("my.app.app1.activity");
        for (int i = 0; i < 1000; i++) {
            logger.log("Event body");
            Thread.sleep(1);
        }
        logger.close();
    }
}

As you can see, we've added a new transport build with SSLTransport.tls(tcp). It's a transport element that makes a TLS negotiation over the tcp; which at the same time is a non-blocking TCP transport. The result is a non-blocking SSL transport.

As mentioned above, the communication with Devo's central collectors has to be (necessarily) via SSL with client authentication. To do so, the client must have a private key to communicate with logtrust; you can generate and download that key on the Devo application. In this code, we assume this has been done and is saved in the file me.jks.

It's also desirable to authenticate our central servers (to avoid a man-in.the.middle attack). To do so, you must have the central collectors public certificate, which you can also download from our web application. We assume this has been done and is saved in the file logtrust.jks.

A SSL Transport default configuration doesn't know which type of authentication it has to negotiate, neither the certificates and private keys to work with. All this is indicated with the corresponding sslConf methods. Specifically, the collector certificate and our private key are given with setTrustManagers and setKeyManagers, that wait for an array from javax.net.ssl.TrustManager and javax.net.ssl.KeyManager, respectively. There are different ways to build these arrays. Since we're assuming that we have information on JKS files, it's best to use the loadTrusts and loadKeys methods of the org.scoja.trans.ssl.SSLUtils class.

In the description of the non-blocking sending we've explained that the negotiation of the TCP connection is also made in a non-blocking manner, which usually means that the first elements sent through the Syslogger doesn't arrive immediately and are delayed until the connection is established. For TCP it's usually a couple of events. When SSL Transport operates on a non-blocking layer, it performs its own negotiation and subsequent data sending also in a non-blocking manner. Since the SSL negotiation consumes way more resources than the TCP, with several exchanges that require computation, the initial block of events that can't be sent immediately is usually larger (between 5 and 10 events).