[osgi logging] part 8 – viewing log events (Lilith)

This is part 8 of my blogseries about ‘Logging in OSGI Enterprise Applications‘ – you’ll find all parts here.

Now our Logging Framework is up and running, catching all Log Events from classic Frameworks or OSGI (Extended)LogServices and we can change the configuration dynamically while the app is running.

Using different Appenders our Logs are persisted in databases, printed to console, stored in (rolling) files  or sent as email using SMTP.

Log Event Viewer

But one thing is missing: viewing log messages from a UI with easy methods to filter. If you’re coming from Log4J then you perhaps have worked with ‘Apache Chainsaw‘. If you’re using Logback then (thanks to Jörn Huxhorn) there’s Lilith – a Log Event Viewer Application. (Curious about the name ‘Lilith’ or the Splash Screen / Logo ? find it out here at wikipedia)

Download Lilith

Lilith can be downloaded here. There’s a special version for OSX.

lilith download files

Starting Lilith

on OSX simply start the Lilith.app  – on other systems double-click on lilith.jar.

If you want to change memory allocation or use JDK 1.6 on OSX, then you have to modify th Info.plist. As default Lilith is running on Java 1.5 – switching to 1.6 is recommended because its faster.

lilith_info_plist

Lilith consumes usually less memory – if Lilith is open, then hover on bottom-right corner you can control memory allocations.

lilith_memory

Lilith Preferences

After starting Lilith you should open Preferences and configure Lilith the way you like it.

lilith_prefs_general

The Application Path is important, because it points to the directory where Lilith will store all Log Files, so its important for your Backup strategy.

Lilith can receive Log Events from different Sources at the same time, so its a good idea to name your sources:

lilith_prefs_sources

Lilith also can work using Black- or White-Lists of Sources – this is great if running on a remote Server.

Log Events -List and Details

Lilith opens for each Connection a new window and closes this window if the Connection was closed. There’s a Menubar, a Toolbar, the List of Events coming in, a Details View:

lilith_remote_server

In one of the next versions you can hide the Toolbar and also Zoom-in and -out.

The different Levels are colored and you’ll see the Message itself, the LogLevel, Name of the Logger, Thread, Timestamp, Throwable and even the CallStack.

Markers are used to get the BundleName where the LogEvent was produced. The last two columns in the example above show you the Application Name and the IP from where the Log Event comes.

To use an Application Name is very handy – per ex. if some RCP Client Apps are running, an Equinox OSGI Server and also Logs from the hosting IDE are received, then its good to know which window belongs to which application. (see below how to configure this)

The order and width of columns can be customized and the layout can be saved:

lilith_savelayout

All Log Messages are stored in files and you can later re-open them:

lilith_open_inactive_log

IDE Integration

You can copy event, message, logger name, throwable, Markers and more:

lilith_copy

Lilith needs you ! there’s an IDEA integration to jump directly from Lilith to Java. Jörn needs someone looking at his IDEA plugin and writing an Eclipse Plug-In. If there’s someone out please tweet @lilithapp

Filtering Log Events

Lilith allows you to filter Log messages:

lilith_filter

You can get a list only containing filered Log Events or you can jump to next / previous found from Filter where other messages are greyed out:

lilith_filtered_log_w_throwable

Statistic

Lilith even gives you a statistic chart where your Log Events are colored based on Log Level, so you can see how healthy your system is.

Lilith in OSGI world

If you’re using Lilith only the Logback – classic – way (which means you’re using the Logback classic socket appender), then there’s nothing more to do: Lilith automatically is listening on the default Port. (see below about Configuration)

If you like to use Lilith Classic Appender then you need a OSGI Fragment. I already described the use of a Fragment and the reasons why to use Lilith Appender in Part4 of this blog series.

Inside the Fragment (at Root Level of the project) I included all needed Lilith Jar’s to make the ClassicMultiplexSocketAppender run:

lilith  fragment manifest rt classpath

Lilith Configuration

Logback Configuration File

If you like to use the Lilith ClassicMultiplexSocketAppender, then you must add the Appender to your configuration file:

<!-- RemoteHost can be set as ${host} refers per ex. to -Dhost=localhost
	you can use more then one hosts: localhost, 10.42.42.42 -->
 <appender name="multiplex"
	class="de.huxhorn.lilith.logback.appender.ClassicMultiplexSocketAppender">
	<Compressing>true</Compressing>
	<!-- will automatically use correct default port -->
	<ReconnectionDelay>10000</ReconnectionDelay>
	<IncludeCallerData>true</IncludeCallerData>
	<RemoteHosts>localhost, 92.51.143.94</RemoteHosts>
	<ApplicationIdentifier>${logback.application}</ApplicationIdentifier>
	<encoding>UTF-8</encoding>
 </appender>

System Properties

If you want to set the Application Name, then we need to set a System Property

-Dlogback.application=abcRCP

lilith  application name

Ports

the server where Lilith is running needs some Ports open:

  • 4560 (standard Logging Event from Logback)
  • 10000 (Lilith Logging Event Server Socket – compressed-)
  • 10001 (Lilith Logging Event Server Socket – uncompressed-)

Our configuration example above only needs Port 10000. There are some other ports if working with Access Events from Servlet Containers, which isn’t part of this blog series.

Summary

Lilith is a powerful and easy to use Log Event Viewer to analyze and monitor your running OSGI Applications.  The Lilith Multiplex Socket Appender runs very fast and robust and I can recommend to use it.

you’ll find the overview of this blog series here. stay tuned… part9 follows…

Update: there was a typo: the developer of Lilith is Jörn Huxhorn (not Jörg) and Lilith has an IDEA pluging (not NetBeans) – but its right: Jörn was looking for someone writing an Eclipse plugin.

2 responses

  1. mea culpa – the name of the Lilith developer is Jörn Huxhorn (not Jörg) and there’s an IDEA integration (not NetBeans), but its right; Jörn is looking for someone wrinting an Eclipse plug-in to directly jump from log messages into Eclipse JDT.
    ekke

  2. Pingback: Logging in OSGI Applications – Monitor Log Messages (Lilith) « ekkes-corner: eclipse | osgi | mdsd | erp

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: