Remember the old days where if you had an uptime of 99.9 you could be fairly confident everyone was having a good experience with your application? That’s not really how it works anymore. Modern, distributed systems are so complex they typically fail unpredictably, making it much harder to diagnose issues. Traditional monitoring grew out of those early days, allowing you to check the health of simpler systems.
Honeycomb uses AWS Lambda as a core part of our query execution architecture; Lambda’s ability to quickly allocate lots of resources and charge us only for use is invaluable to keeping Honeycomb fast and affordable. Our total Lambda bill is easily accessible in the AWS Console, but how do we know which customers or application areas dominate this bill? How do we judge the cost of changes we make to our own software?
“It’s too expensive!” “Do we really need another tool?” “Our APM works just fine.” With strapped tech budgets and an abundance of tooling, it can be hard to justify a new expense—or something new for engineers to learn. Especially when they feel their current tool does the job adequately. But, does it?
Debugging application performance in Azure AppService is something that’s quite difficult using Azure’s built-in services (like Application Insights). Among some of the issues are visualizations, and the time it takes to be able to query data. In this post, we’ll walk through the steps to ingest HTTP Access Logs from Azure AppService into Honeycomb to provide for near real-time analysis Access Logs.
The software industry is moving toward teams that own the services they build. This concept encloses principles and possibilities from movements toward microservices, DevOps, Agile, and Project to Product. In these paradigms, a team of people delivers software that provides valued capabilities. These capabilities help customers get their work done, support business operations, or enable other software to do these.
At its core, observability is understanding the internal state of your systems based on the telemetry they output so you can effectively troubleshoot, debug, and tune performance. However, there’s a tendency to reduce observability to a collection of logs, metrics, and traces, which strips away much of the visibility you need to understand what’s going on.
I've never been on call before, and I'm not sure what to expect, or how I can best prepare for it. Will I need to upend my life just in case the pager goes off? And how should I best cope with getting paged? I've read Charity's piece on the opposite problem of wanting to stop being on call, but it didn't quite answer my question.
I’m Phillip, a product manager here at Honeycomb. After eleven-ish months of working on our product, I totally understand observability, right? ...Kinda? Sorta? Maybe? I'm not sure—but, I have been sitting in this space long enough to be a little better than clueless. Here's my guide on the topic. I hope it helps, especially if you’re passionate about exploring alternative ways you or your team can manage today’s cloud-native applications.
Honeycomb ruffled the first of many feathers nearly seven years ago when we coined the term “observability” in talking about production code. Today, we get to celebrate a major victory in our push for the term to break free from its unsuitable parent category, Application Performance Monitoring (APM).
I use .NET and I keep seeing something called `Activity` but in OpenTelemetry there is only talk about “Span” and “Trace,” why? And what should I be using? This is understandable, and has caused confusion since that decision was made by Microsoft back in 2018/19 (I believe). I’ll do my best to provide some guidance on what the distinction is, and also when each is useful.
