The search-first problem-solving approach—meaning “open up the log search tool” (Splunk, ELK, Loggly, SumoLogic, Scalyr, etc)—is a costly and time-consuming operation during which the true source of a problem is rarely pinpointed in short order. Log search tools require work by the user to transform text strings into fields that are ready for statistical analysis.
If you are running a distributed system and have reached a point of scale where you’re running 5+ services, you are more than likely experiencing difficulties when troubleshooting. Does the following sound somewhat familiar?
In just a few days, we’ll all be embarking on the new year–kicking its tires and planning our conquests for the months to come. This holiday in-between week, while the days are just barely beginning to get a little longer, seems like a good time to look back on the events of the past year and remember some of the good times we’ve shared–so join me for a little retrospective fun.
At Honeycomb, we are frequently asked how we compare to what else is out there. Do these other tools offer observability? Do I need them all? What’s important? Metrics? Logs? What’s the best way to monitor application performance?
What should one pay for observability? How much observability is enough? How much is too much, or is there such a thing? Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well? It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”. (Hey, I said almost.)
Happy December! Back in October, we cohosted a SPOOKY HALLOWEEN meetup with our pals at LaunchDarkly about testing in production. Here’s a review of the talks we saw!
