Too Many Logging Options

5 minute read

Introduction

I got an email the other day asking which options to go with when logging cloud applications. I decided it might be good to publicize the response for others who are in the same boat. There are a lot of logging companies out there, but each one is focused on a specific area. Think of the analytics space. There are a ton of different marketing analytics and BI companies, but each focus on specific areas. You probably wouldn’t be comparing AppsFlyer to MixPanel to Google Analytics, instead you should be asking what are your business requirements and what company fits that criteria.

This post is not meant to be a deep dive or comparison, rather an introduction to the many companies and focus areas of logging/exception tracking.

Mobile/Web Application Exception Tracking

There are a few companies focused on exception tracking. That is, when an error occurs, a report is generated for caught and uncaught exceptions in your application. Many of these also have additional functionality like assigning the error to a developer. Their SDK usually captures more details than a typical log message such as installed lib versions, environment variables, etc.

Since a lot of mobile and client JS code is obfuscated and/or minified (i.e. Proguard or Uglify), stack traces may be hard to comprehend without access to a source map. They map the obfuscated variable and method names to the originals in source code. Look for platforms that automate this process.

Crashlytics is free but only support mobile native apps on iOS/Android, not web. They have a plugin for common IDEs to auto upload a source map when a release build is built with obfuscation. Crashlytics reports both caught and uncaught exceptions and also some extra metrics like DAU and MAU and have one of the best “dashboards” out there for a daily glance at what’s going on with your app. Airbrake can also be used for these in lieu of something like Crashlytics. Airbrake also supports web apps and is especially good with Ruby environments.

On the web app side, you have a few other options, such as Sentry, Airbrake, and Rollbar. Sentry has open sourced everything, but also provides a hosted version. Sentry is good for JVM apps including both Servlet and other JVM languages. Sentry supports common logging frameworks like Logback and Winston. Sentry’s search is not the greatest though and the web app can be a little slow at times. Their pricing is based on event ingestion regardless if error is thrown or not. If you have a lot of logging messages, this can tip Sentry to being more expensive than the other options. On the other hand, Airbrake and Rollbar charge only by your error rate. So if your app is more in maintenance mode with less errors, you may wang to consider these.

At the end of the day, they are still not an end-all solution for your production debugging needs. The log search in these platforms is still rudimentary as they center around exceptions and stack traces rather than raw logging. You can’t have fancy regex or custom queries. So you will probably find yourself integrating a logging solution also.

Logging

Logging is very different than the exception tracking software discussed above. Most logging platforms are much more generalized than the exception tracking integrations. They can be treated as a traditional syslog server and can read data from a variety of open source logging frameworks such as Logback or Winston. Unlike exception tracking, these logging platforms can also log from non business application code such as reverse proxy server logs, database logs, etc.

Since many people log everything, they can be used for other business requirements such as audit trails.

Many folks have heard about Splunk one way or another. Splunk is one of the incumbents in the logging space. Originally starting with an on-premises solution, they now have a hosted SaaS offering that is reasonably priced but that is not their primary focus. While they have some nice search and aggregation features for large companies with lots of data, unless you are one of those larger companies or have cash to burn, we don’t recommend Splunk. This leaves the remaining competitors: Loggly, Sumo Logic, Paper Trail, Logentries and a few smaller ones which you can find on Stack Share, Quora, etc.

There are many other competitors in this space; however, they still all achieve the same function: pull log data from many machines and consolidate into an searchable data store such as ElasticSearch. Sumo Logic is one of the most feature rich, yet more expensive offering and can be seen as “Splunk in the cloud.” They provide nice anomaly detection and aggregations from the log data. Loggly is one of the cheaper options with less features. They do a decent job with regex parsing and each JSON field can be a filter or facet.

Custom ELK Stack

Sometimes the question asked is, “Should I just host my own ELK Stack. I don’t want to worry about vendor lock in?” Unless you are a larger company with custom needs or very high usage, I definitely don’t recommend setting up your own ELK stack before. Especially if you don’t have a big DevOps background. You probably have enough on your roadmap with product features, growth hacks, customers, etc. Logging is something that you have to put a lot of effort into to scale correctly, you may be investing thousands or millions of events per second. You don’t want to worry about optimizing the JVM parameters and memory consumption to get LogStash to play nice or ensuring elastic search is backed up correctly and fail safe so you don’t loose all your data if some ElasticSearch nodes go down. Larger companies have entire teams creating data pipelines for logging (or in our case a startup ;)) When you are ready, you can always setup your own ELK stack later, but for now it’s easier to pay $100/mo or so then paying salary for not just setup but support.

Vendor Lock in:

When choosing a database technology, it requires a lot of effort to avoid vendor lock in. Your application code becomes reliant on specific database client drivers, query patterns, etc. It may take work to export the data itself between different technologies. On the other hand, outside of audit trail requirements, log data isn’t really kept for a long duration. Logging SaaS platforms usually plug into standard frameworks such as Logback. Thus changing providers may take a few minutes and simply require a new library to be included and a few application config switches for the key/secret. Because of this, I view vendor lock-in as less of a risk.

Thanks

We’re thankful to our select beta customers who have been trying out Moesif providing us invaluable feedback to make debugging easier.

Do you spend a lot of time debugging customer issues?
Moesif makes debugging easier for RESTful APIs and integrated apps


Learn More

Leave a Comment