Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Fallback Logger for Windows 10 IoT Core

DZone's Guide to

A Fallback Logger for Windows 10 IoT Core

What happens when your IoT solution's network fails? A hard reboot probably means lost data. Implementing an offline fallback logger can keep your data safe.

· IoT Zone
Free Resource

We love to use our favorite logging solutions as much as possible, but if external storage or external services are involved, we cannot guarantee that logging works in a crisis situation. This blog post introduces a wrapper or fallback that uses the main logger to log all messages and a secondary logger to kick in when the main logger fails. Implementation is easy, but there’s a good chance that log messages doesn’t get completely lost when main logging service goes down.

Note: The source code shown here is taken from my TemperatureStation solution on GitHub. My loggers for Windows 10 IoT Core are in the Loggers folder of the Windows 10 IoT Core background service. To make ETW logging work on Windows 10 IoT Core, please read my blog post Using ETW Tracing on Windows 10 IoT Core.

Why Use a Fallback Logger?

We want to use a logger that is familiar to us and that puts its logs somewhere we're familiar with. Here are some examples of loggers that write logs to external storage:

But what happens when the network goes down or the Wi-Fi driver crashes at the same time something interesting happens in our IoT solution? It’s possible we have to power down our Raspberry Pi to make it restart. If that happens, there's a high probability that the latest logs are gone forever. A fallback logger is here to help us out.

Architecture of a Fallback Logger

All loggers in the TemperatureStation background service use the same ILogger interface. It makes the code easier to handle if ILogger is known and the concrete type of logger is just a matter of configuration.

Loggers of TemperatureStation

FallbackLogger is a special case. It also follows the ILogger interface, but it also uses two loggers:

  1. Main logger: This is the logger that is tried first
  2. Secondary logger: This logger is used when the main one fails.

To illustrate the fallback logger better, let's try an example. Our main logger is SyslogLogger, which logs events to a Syslog server in the local network. If the network goes down or the Syslog server is not available for any other reason, then the ETW trace logger is used because it works locally and doesn’t need any external resources.

Implementing a Fallback Logger

Here is the raw and unpolished implementation of FallbackLogger. I know the code can be better and more compact because of the repeating try-catch pattern, but let’s stick with this implementation, as it is easier to understand.

internal class FallbackLogger : ILogger
{
    private readonly ILogger _mainLogger;
    private readonly ILogger _fallbackLogger;

    public FallbackLogger(ILogger mainLogger, ILogger fallbackLogger)
    {
        _mainLogger = mainLogger;
        _fallbackLogger = fallbackLogger;
    }

    public void Debug(string message)
    {
        try
        {
            _mainLogger.Debug(message);
        }
        catch (Exception ex)
        {
            _fallbackLogger.Debug(message);
            _fallbackLogger.Critical(ex.ToString());
        }
    }

    public void Info(string message)
    {
        try
        {
            _mainLogger.Info(message);
        }
        catch (Exception ex)
        {
            _fallbackLogger.Info(message);
            _fallbackLogger.Critical(ex.ToString());
        }
    }

    public void Warn(string message)
    {
        try
        {
            _mainLogger.Warn(message);
        }
        catch (Exception ex)
        {
            _fallbackLogger.Warn(message);
            _fallbackLogger.Critical(ex.ToString());
        }
    }

    public void Error(string message)
    {
        try
        {
            _mainLogger.Error(message);
        }
        catch (Exception ex)
        {
            _fallbackLogger.Error(message);
            _fallbackLogger.Critical(ex.ToString());
        }
    }

    public void Critical(string message)
    {
        try
        {
            _mainLogger.Critical(message);
        }
        catch (Exception ex)
        {
            _fallbackLogger.Critical(message);
            _fallbackLogger.Critical(ex.ToString());
        }
    }
}


The simple code above makes sure that logging works when the main logger we all love can’t do its job for some reason.

Wrapping Up

Monitoring IoT solutions is important, especially when custom hardware is involved. We must be ready to react to problems we were not ready to expect in the first place. Still, we want to use familiar logging systems and services. But some problems, like network problems and service outages, may leave us with a situation where our solution is not able to log  important information. This is where a fallback logger comes in, with some logger that works locally and that doesn’t use any external resources. Although the fallback logger implementation here is primitive, it still works well in practice.

Topics:
iot ,windows 10 iot core ,logging ,iot data ,tutorial

Published at DZone with permission of Gunnar Peipman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}