Observability   News & Announcements   Metrics  

Honeycomb vs Elastic Stack: It's About Priorities

By Rachel Perkins  |   Last modified on September 26, 2022

If you've been paying attention, you know that although collecting and reviewing metrics and logs is a core part of running a stable and successful service, access to raw events and the ability to search and pivot on any dimension of your production environment, no matter how high cardinality, is what will help your team debug and troubleshoot new problems and outages more quickly.

You've done a little research and found two options: Honeycomb and the Elastic stack aka ELK. Both offer the ability to collect and search across wide, context-laden events about your infrastructure and services. But that's where the similarities end.

Elastic Observability vs Honeycomb

Elastic is schemaless. You might get some value out of your logs initially, but as your usage expands, you will have to develop some expertise and preformat your logs to make further progress. To go beyond standard log formats, someone on your team may have to write regular expressions and Logstash Grok filters. Otherwise, each log line can end up being a large string stored in the generic message field—which makes it difficult to search/filter your data in an efficient way.

Honeycomb accepts JSON objects, and offers agents and easy-to-use SDKs that understand most common log formats, programming languages, and database transaction output. You don't need to write custom parsers, plan for, or select indexes ahead of time.

“We used the NGINX log parser because it was essentially zero-effort.” -Dan Kleiman, Tapjoy

Observability isn't just about logs

Logs from your infrastructure services are great, and you need that data, but you also need context and data from your own custom-written code. Honeycomb provides Beelines, special instrumentation blocks that automatically instrument your in-house-written apps so you can get timings and tracing support for requests and queries immediately without doing the manual labor required.

This frees up your team to instrument their code with events specific to your use case, adding the valuable context you need to improve your service and make your customers happier.

Scaling takes resources you'd rather use to drive your business

scaling resources

With ELK you might start small. Someone on your team puts up a couple of AWS EC2 instances for Logstash, the cluster nodes, and Kibana, and you might get some useful data flowing for your team to use to troubleshoot problems.

But if you're doing it *right*, more people will want to start using the system and you will need to either limit access to the interface, or scale it up. To do that, you'll have to load balance Logstash, deploy multiple parallel data nodes in Elastic, install and run something like Apache Kafka to avoid data loss if your traffic is bursty...and this will all be your responsibility.

Why not just offload all that operational overhead to Honeycomb? We're here to serve, and we know what we're doing.

  • The Honeycomb network was architected using modern best practices for tunneling, separate VPCs, encryption at rest and in transit.
  • All storage nodes are unreachable from the internet.
  • Only web services (API, UI) are reachable from the internet at all, and then only through ELB TLS ports.
  • Nothing is transmitted unencrypted.
  • Our entire infrastructure is autoscalable; we can roll our entire infra in ~60 minutes (~10 minutes for our forward-facing web nodes) when critical security patches are released.

Don't limit access to what makes your team most effective—let us handle the operational load and let your team focus on what's important to your business—happy customers.

Switching interfaces for tracing can mean losing speed and context during an investigation

tracing diagram showing many retries and a slowdown

Elastic stack doesn't include traces or the ability to view them side-by-side with events from your systems. You can ask your team to use a second tool to access them, but in doing so they have to re-orient their investigation and drill into a UI with a different approach and mindset—which can derail their investigation. This is sub-optimal when time-to-understanding (and ultimately, resolution) is critical. Honeycomb has tracing support built right in, and with our Beelines, you get automatic and immediate instrumentation that includes traces.

Observability disadvantages with Elastic Stack

When it comes to observability with Elastic stack, you'll be using Kibana to search your data, and that means learning a new query language and syntax.

You'll have to have defined the fields and indexes you want ahead of time, and you can't really discover what's in your data easily. ELK relies on storing whole rows of data plus additional indexes for speed, while Honeycomb's underlying architecture means that our column store doesn't get slower the more data you store per-row. In ELK, if your rows get wider, it gets slower to read back the full row, and you'll have to update more indexes at write time.

Unless you've maximally-provisioned your ELK systems, search performance can be slow when searching across lots of data, especially if your Grok filters are not working perfectly.

"We have an ELK stack, but the query language is cumbersome and the UI is not as easy to use as Honeycomb." - Michael Garski, Director of Software Engineering at Fender

With Honeycomb, you get the Query Builder, a simple, flexible, powerful interface that does not require your team to learn a new language. A query in Honeycomb consists of five clauses:

  • Break Down: split events into groups based on the value of some attribute.
  • Calculate: collect specific statistics across a set of events.
  • Filter: constrain events in the specified time range based on some additional criteria.
  • Order: sort the results.
  • Limit: specify a limit on the number of results to return.

These clauses are presented in a simple GUI with drop-down, tab completion-enabled type-ahead content from your data, so users don't have to worry about typos or complex syntax.

The basics shouldn't cost extra

If you want monitoring and alerting, you have to pay Elastic for this functionality.

If you want user accounts with passwords, data encryption—you have to pay Elastic for it.

If you want tracing support—you have to pay for a separate tool or service.

Find out what it's like to get real observability, all the features you need included, without the hassle of setting up an ELK stack or learning a new query language--try out Honeycomb for free or get a personal demo today!

 

Related Posts

Observability  

Frontend Debugging Is Bad and it Should Feel Bad

There’s a sentence that strikes fear into the heart of every frontend developer I've ever met: Users are reporting issues, and we don't know how...

Observability   News & Announcements  

Focused Labs & Honeycomb: Better Together

We're excited to unveil a new collaboration with Focused Labs, a leap forward in our shared commitment to advancing modern observability practices and enhancing the...

OpenTelemetry   News & Announcements  

Much Ado About OpenTelemetry

There is so much good work that OpenTelemetry has done in the software industry, specifically around the domain of observability, in the last five years....