The log4mongo-java project includes several Log4J appenders for storing log messages in a MongoDB collection.
- MongoDbAppender - stores the LogEvent in a BSONified form
- ExtendedMongoDbAppender - Extends MongoDbAppender by allowing you to add top level elements
- MongoDbPatternLayoutAppender - supports logging data in a custom format
- Download and install MongoDB from http://www.mongodb.org/downloads
- Start mongod running on localhost on the default port
- Download the Mongo Java driver jarfile
- Download Log4J jarfile
- Download log4mongo-java jarfile
- Place these three jar files in your classpath
- Create a file called log4j.properties in your classpath
- Add the following lines to the log4j.properties file
- log4j.rootLogger=INFO, MongoDB
- Create a Java class like:
Compile and run the class. Then, start a mongo shell and confirm that an event was logged.
An abstract BsonAppender class (introduced in 0.5) provides basic functionality for serializing a Log4J LogEvent to a BSON DBObject. The MongoDB specific appenders extend this class. This abstract class is useful if you want to store the same information outside of MongoDB.
MongoDbAppender stores the Log4J LogEvent object as a document in a MongoDB collection. The document is serialized in a format that is very similar to the structure of the LogEvent class. Where possible, the data is stored as appropriate BSON objects, rather than just strings.
A future enhancement will optionally store the Map in the MDC (Mapped Diagnostic Context) as part of the document.
MongoDbPatternLayoutAppender stores a log message as a document in a MongoDB collection based on a user-specified conversion pattern using the standard Log4J pattern layout, parser and converter functionality. While requiring some additional configuration, this appender allows significant flexibility over the format of the stored document. The MongoDbPatternLayoutAppender also allows custom information to be stored with the document. The custom values are determined at the time an event is logged.
The root directory of the project distribution contains a sample properties file named log4j.properties.sample. All of the properties used by log4mongo-java are documented in the sample file.
The log4mongo-java 0.6 release added full support for replica sets. While earlier releases would work with replica sets, you could specify only one host in the hostname property. If the appender happened to be initialized when that host was not available, the appender would not be able to connect to other members of the set.
With the 0.6 release, you should specify the names of all the hosts that can become master. The Mongo Java driver will automatically find the current master. For example:
If MongoDB is listening on the same port on each host, you can specify just that port. If it's the default port of 27017, you can omit the property.
If the same port is not used by each host, then you must specify the port for all hosts. For example, if the hosts mongo1 and mongo2 are listening on 27000 and 28000, respectively:
When a master becomes available, the next attempt to log will fail and the insert will be lost. The Mongo driver will then check for the new master and the next insert should go to the new master. Log inserts between the time of the original master's failure and the election of the new master will be lost.
Although events can be logged to any MongoDB collection, it's common to use a capped collection. Capped collections provide very high performance and automatic removal of old information. One drawback, though, is that the collection is capped by size in bytes or in objects, rather than by a time period. A common desire is to keep logs for a certain period of time. Capped collections cannot be used for this purpose, though. If you are confident that logging data will rarely exceed a certain size over the desired period of time, though, capped collections can be a big win.
Another advantage of capped collections is that they allow you to control the amount of disk space used for logging. History is full of sad stories of apps grinding to a halt because the log files filled up a disk partition to which the app needed to write other data.
Assuming you are using a database named appname and a collection named log, you can use the following commands in the mongo shell to create a capped collection of size 100,000,000 bytes.
MongoDB authentication is optional. If the userName property is specified, the appender will attempt to authenticate against the specified MongoDB database using the values for the userName and password properties. (TODO: Add description of behavior and a test case for when userName is specified, but password isn't).
For example, if an appender is defined as:
and the host, database, user name and password are specified as:
then when the appender is initialized, it will attempt to authenticate as user open with password sesame against the appname database in a MongoDB instance listening on the default port on localhost.
The 0.7.3 adds support for setting the write concern when logging. The default is UNACKNOWLEDGED. You can override the write concern in your log4j properties file. For example, if you named your appender MongoDB in the properties file and you wanted the driver to wait for log event data to be written to disk on at least the primary:
You should definitely do performance testing, though, since I found FSYNCED to be 1 to 2 orders of magnitude slower than UNACKNOWLEDGED when writing 1000 consecutive log events.
When logging an event, this exception is thrown - java.lang.NoSuchMethodError: com.mongodb.DBCollection.insert(Lcom/mongodb/DBObject;)
If you use log4mongo-java 0.3.2 or earlier with MongoDB Java driver 2.1 or later, you will probably get this error.
A source compatible, but binary incompatible, change was made in the 2.1 driver to the DBCollection.insert() method used by log4mongo-java. That method now takes a varargs argument instead of a single DBCollection object. In client code, the Java compiler converts the varargs argument to an array whether you pass one DBCollection or more. However, log4mongo-java 0.3.2 was compiled against the 2.0 Java driver, so it passes a standalone DBCollection, instead of the array that is expected by the compiled 2.1 driver code.
The workaround is to either upgrade to log4mongo-java 0.4.0+ or to compile your own log4mongo-java jarfile against MongoDB Java driver 2.1+.
When logging an event, this exception is thrown - java.lang.NoSuchMethodError: java.util.Arrays.copyOf([Ljava/lang/Object;I)[Ljava/lang/Object;
Versions of log4mongo-java up to and including 0.6.0 contain Java 1.6 specific code. You may see the above exception if you are using Java 1.5 or earlier. This has been fixed on GitHub and will be included in the next release of log4mongo-java, likely to be 0.6.1.
The MongoDB Java Driver 2.2 has a bug, JAVA-180, that causes a NullPointerException if you call Mongo.close() and are not using MongoDB in a replica set. The bug is fixed in Robert's fork of the 2.2 driver, as well as in the trunk for the 2.3 release. The bug was not present in the 2.1 driver.
Libraries such as Hibernate may use libraries like CGLib for generating class proxies. In your code it will look like you are passing a regular object to one of the Logger methods for logging a message, but at runtime a proxy will be passed. The BSONEncoder can't serialize this proxy.
Here's an example stack trace:
The simplest workaround is usually to call .toString() on the object before passing it to one of the Logger methods.
- Performance improvements