Time is relative in Log4View

2011/05/17

When two logging events both have a time stamp of 2010-1-1 10:20:30,456, does that mean that both events happened at the same time?

Not necessarily. It depends on some factors:

  • The location, where the events happened and their time zone.
  • The current daylight saving settings in the country.
  • The logging framework, which can use Universal or local time.
  • The accuracy of the clock in the computer, which generated the event.
  • The precision of the time’s storage format.
  • The precision of the time’s display format.

Log4View 2011.1 tries to address all this aspects and has added some extra settings and time representations.

Log4View stores the message time in a DateTimeOffset structure, which preserves the time zone and the daylight savings settings. If the log data is sent in log4net XML format, this is no problem, because the XML layout presents the time with the time zone information. However, the original log4j XML format stores times as ticks without any time zone information. For this and other cases, where no time zone information comes with the log data, you can set the time zone in the receiver settings.

By default, Log4View shows the message time in the time zone, where it was stored. Thus, a message with the time stamp 10:00:00+01 (CET) will be shown as “10:00:00”. This is what normally is expected when dealing with just time zone.

However, when you are working with log files or streams from different time zones, things become more complicated. As long as you don’t change the sort order, all messages in a message window are sorted by their UTC time. Thus it can happen, that a message with timestamp 10:20:00+01 is shown before a message with timestamp 10:00:00+00, because the later message was actually created 40 minutes after the first message.

Another issue is computer clocks, which are not in sync. This can be quite disturbing when you want to compare log output from different machines. To correct this, you can specify a time offset when configuring a log receiver. This offset will be applied to every message from this receiver.

Dealing with all that time zones and offsets can be quite confusing and that’s why Log4View has different time representations. For this example, we assume that we are viewing a log message with timestamp 12:14:40,000+02 (IDT, Jerusalem) in summer in Munich, Germany (CET) with an offset of 650 ms to compensate the slow Jerusalem computer’s clock:

  • Time: The time as local time where it was created with the offset applied: 12:14:40,650
  • Local Time: The time converted to current local time with offset applied: 11:14:40,650
  • Universal Time: The time converted to UTC with offset applied: 10:14:40,650
  • Original Time: The time as it was stored without offset: 12:14:40,000

All time representations can be shown as extra columns in the message view by right-clicking a columns header, selecting the column chooser from the context menu and dragging the respective columns to the desired location.

Precision Matters

By default, Log4View shows all times with a resolution of milliseconds. This is enough, especially when considering, that the resolution of the normal log4net or NLog timestamp is approx. 10 milliseconds. However, when using your own time source, you can create timestamps with a resolution of microseconds.

You can increase the time resolution of Log4View to microseconds by entering “HH:mm:ss,ffffff” into the Time Format field in the Log4View settings.


Log4View 2011.1 Beta released

2011/04/28

We have finally released the Beta of Log4View 2011.1. The release has been delayed for a couple of months because the internal changes, which became necessary to enable receiver and logging-framework plugins, turned out to be larger than initially expected.

However, the result was worth the effort, because we have laid down a good foundation for the future things to come.

For the moment, Log4View 2011.1  will bring

  • Full support for the NLog logging framework
  • Support for Log4View receiver plugins; this enables everyone to add new receivers to Log4View
  • Support for Log4View logging framework plugins; thus you can enable Log4View to read the configuration of your own custom logging framework
  • A separate Log4View control which allows developers to seamlessly integrate Log4View into their own application
  • Better support for times, time zones and time offsets
  • A large number of bug fixes and detail improvements

I will describe the main features and concepts in further blog posts within the next few days.

In the meantime, please download Log4View 2011.1 Beta and check it out.


Future Developments for Log4View

2011/01/22

Having released the (hopefully) last bug fix release of Log4View 2010.3 this morning, it’s time to speak about new features in Log4View 2011.1.

Log4View 2011.1 will have full support for NLog, a .NET based logging framework with a lot of new features compared to log4net. Although the current version of Log4View can read XML formated files created by NLog, Log4View now can’t parse NLog configurations so that it isn’t possible to have bound NLog receivers.

The support of NLog does not mark a shift away from log4net. Instead, it opens Log4View to other logging frameworks. Developing NLog support for Log4View made it necessary to implement a plugin model for logging frameworks. This allows the development of future Log4View plugins for other frameworks as well. The NLog plugin for Log4View will use the Managed Extensibility Framework (MEF) in .NET 4.0 and will be also published as source code to allow other developers to write their own plugins for Log4View.

Log4View 2011.1 will also support receiver plugins. Thus every developer can write his own plugin for Log4View to read logging data from almost any data source. Of course, there will be source code of a sample receiver plugin.

Log4View 2011.1 is scheduled for the first quarter of 2011.


Beta of Log4View 2010.3 now online

2010/03/28

In the last weeks, there was a lot of refactoring under the hood.

In the past, we used a special docking engine, while all other UI controls came from DevExpress. We now switched to the docking engine of DevExpress which gives us the opportunity to offer more than 30 different and very stylish skins for Log4View.

For example, what do you think about Summer 2008?

 

I like this one a lot, perhaps because after a long and cold winter, spring is now coming to southern germany.

But of course, there are also more serious skins available.

Of course, we also did a lot of bug fixing. You can find a list of all changes in the Release Notes.


Don’t worry about lost messages with the TCP appender

2010/03/23

As soon as the TCP receiver is configured and started, it tries to connect to the configured TCP appender. Theses connection attempts are repeated every second until the connection is established.

But what happens, if Log4View is already running before the logging application is started. Depending on when the last connection attempt was made, there is a delay of up to 1000 ms until Log4View successfully connects to the newly started application.

Are the messages lost, which had been sent before the connection was made?

No!

The TCP appender is using an internal buffer, which stores the messages of the last 5 seconds and sends them prior to any new messages as soon as a new connection is made. This makes sure, that you don’t lose messages when Log4View is running before you start your logging application. If you start Log4View afterwards, you get at least the last 5 seconds before you started Log4View.

BTW: You also don’t have to worry about long periods where the logging application doesn’t send log messages. The TCP appender sends a short dummy message, if no log messages were sent in the last second. This makes sure, that the TCP connection stays open as long as the logging application and Log4View is running.


Log4View 2010.2 and the UDP appender

2010/03/19

After having published Log4View 2010.2, some users told me, that they had difficulties with the UDP appender.

As a matter of fact, the new field “Hostname”, which we added to the UDP receiver form, can only accept IP addresses (e.g. “127.0.0.2”). There is no DNS resolution for the host name in the UDP receiver.

Even worse, the host name is empty by default, which makes the UDP receiver fail. So please make sure, that you provide a valid IP address.

We will fix this in the next release.