Logging for Cloud-Native Apps

When it comes to building and running applications that are native to the cloud, a number of old habits must die and make way for modern alternatives. One of these is traditional file-based logging.

The days of using tail -f to watch logs scroll by in five different terminals are over.

This becomes even clearer as you move to cloud-native applications running on images like those generated by Boxfuse. Boxfuse intelligently analyzes your application and generates secure minimal images in seconds. There is no general purpose operating system and no tedious provisioning. Boxfuse images are lean, secure, and efficient. In fact, they don’t even let you log in as there is no ssh on board. All that is left is the most efficient machine to run your application on both VirtualBox and AWS.

So how do traditional instances compare with modern cloud-native instances?

Traditional Instances (General-Purpose OS)	Cloud-Native Instances (Boxfuse)
Long lived	Disposable
Reconfigured on change	Regenerated on change
Persistent storage	Ephemeral storage
Multiple GBs	Few MBs
Ability to log in via SSH	No SSH

Quite different worlds indeed.

However, no matter how different these two worlds are, logging remains invaluable in both of them.

Why Is Logging Invaluable?

Here at Boxfuse, we view logs as our great forensic tool in case of trouble. We do not see logging as a general-purpose data sink. If you need structured access to large amounts of data in your logs, you should probably consider other data stores instead. But when it comes to system behavior and error root-cause analysis, solid logging combined with proactive monitoring are critically important.

So, what are the needs a logging solution must fulfill?

• It must be durable for a certain period of time (the value of log data decreases exponentially with time).
• It must be searchable (to quickly find related needles in the haystack).
• It must be centralized (all instances of an application send their logs to the same place).
• It must be integrated with the application (no mandatory clunky detours via disk or syslog).
• It must be fast with little overhead (no substantial performance degradation).

What to Log

In addition to regular application logs, we want to be able to capture early system logs in case our application fails to start or can’t connect to the centralized logging facility.

We therefore want to distinguish between instance boot logs (low volume, instance-specific, for diagnosing startup issues) and application logs (high volume, application-level, for diagnosing application behavior issues).

Instance Boot Logs

The instance boot logs collect information from the earliest stages of instance startup (kernel boot) all the way to the point where the application is fully up and running. They are great for identifying environment-specific network and application configuration issues that might prevent proper startup or for connecting to a central log server.

Luckily, all virtualization and cloud platforms make this information available. If you are using Boxfuse, you have a unified and convenient way to access it.

Application Logs

On the application side of things, you want direct integration with your logging framework of choice for your platform. And this is why we at Boxfuse highly recommend Loggly: a solid service with native integrations for almost all major platforms out there.

Messages are sent directly and securely by your logging framework via HTTPS to Loggly’s back-end connectors where they are ingested, aggregated, indexed, stored redundantly, and made available via nice web-based dashboards.

So how does cloud-native logging with Loggly compare with traditional file-based logging?

Traditional Logging (File-Based)	Cloud Native Logging (Loggly)
Spread over many files on many machines	Available from one central place
Tedious and time-consuming search	Instant search via web dashboard
Reading requires SSH access to machine	No SSH access required to machine
Lost when server dies	Always stored redundantly
Difficult to configure alerts	Easy alert creation via web dashboard

As you can see, traditional file-based log rotation not only is outdated and risky but also just doesn’t make sense anymore for modern cloud-native instances that don’t give you the ability to log in.

Integrating Logback with Loggly

At Boxfuse, our primary focus is JVM apps, and we love to make things incredibly convenient for our customers. And so for us, recommending Loggly’s Logback (successor to Log4J) integration is a no-brainer. Let’s look at how simple it is to integrate them both.

Start by creating a free Loggly account and add a Java Logback source:

Now all you need to do is add the Loggly Logback appender dependency to your build (it is available on Maven Central):

You can then configure the appender in your logback.xml (don’t forget to make it async to avoid a performance hit):

That’s it! Almost immediately you will see the logs appearing in the Loggly UI:

You can now start to search them, generate graphs, define alerts, create custom dashboards, and more!

Debugging Boxfuse Configuration Issues with Loggly

One of the most frequent sources of errors with Boxfuse is port misconfiguration. This happens when the application is configured to start on a specific port (say, http on 8080), yet the Boxfuse image has been configured to map that port differently (say http on 80). Boxfuse then uses its configuration for a number of things, including load balancer configuration, AWS security group creation, and health check setup. Having a misconfiguration here will either cause the application to be unreachable or the health checks to fail. Debugging this becomes a lot easier with Loggly on board. All you need to do is peek at your logs and compare them with your configuration.

Let’s look at this in practice. Suppose we have our app accidentally configured to start on port 8080 and Boxfuse set up to expose http as port 80 on the image. By launching an instance of the image on AWS we get the expected health check failure:

Turning to Loggly, all we need to do is a quick search to find the culprit:

Even though the app came up correctly, it is now trivial to spot the configuration mismatch. And sure enough, we’ll be able to fix the issue in no time. This is just one of the benefits of a solid central logging infrastructure with great search capabilities.

Summary

It’s time to say goodbye to the days of using tail -f to watch logs scroll by. Logging for cloud native applications is a breeze, but you need to use the right tools. Simply combine your cloud provider’s support for instance boot logs with Loggly’s powerful hosted service for your application logs. Add Loggly’s Logback integration to the mix and you have a comprehensive, robust, and highly available solution up and running in no time.

Are you running a cloud native app on the JVM? Boxfuse intelligently analyzes your application and generates minimal images in seconds. There is no general purpose operating system and no tedious provisioning. Boxfuse images are lean, secure, and efficient. You can run them on VirtualBox for development and deploy them unchanged and with zero downtime on AWS for test and production.

If you haven’t already, sign up for your Boxfuse account now. All you need is a GitHub user and you’ll be up and running in no time. The Boxfuse free plan aligns perfectly with the AWS free tier and the Loggly free plan, so you can deploy your cloud-native application to EC2 and enjoy the pleasures of great logging without even paying a dime.

---

About Axel

Axel Fontaine is the founder and CEO of Boxfuse. He is a 17-year industry veteran and hates complexity with a passion. Axel is a continuous delivery expert and the creator and project lead of Flyway. He is a JavaOne rock star and a regular speaker at many large international conferences including JavaOne, DevNexus, Devoxx, Jfokus, JavaZone, and JAX. You can find him on Twitter as @axelfontaine.

 

The Loggly and SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates. All other trademarks are the property of their respective owners.